Internet DRAFT - draft-wang-bess-secservice
draft-wang-bess-secservice
Network Working Group H. Wang
Internet-Draft Huawei
Intended status: Standards Track L. Dunbar
Expires: 29 July 2024 Futurewei
C. Sheng
H. Shi
Huawei
26 January 2024
IPSec for BGP Enabled Services over SRv6
draft-wang-bess-secservice-02
Abstract
This document describes an approach to encrypting selective user data
flows using IPsec and then orchestrating the encrypted flows based on
the SRv6 Policy path. The method is needed for some users or
applications that demand an elevated level of security, necessitating
the encryption of their data flows even within networks like SRv6,
which are built and managed by Network Service Providers (NSP) and
generally considered secure. Employing encryption for selective
flows over NSP managed networks, including technologies like SRv6,
adds an extra layer of protection, safeguarding valuable data from
potential breaches and enhancing overall network security.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 July 2024.
Wang, et al. Expires 29 July 2024 [Page 1]
Internet-Draft IPSec for BGP Enabled Services over SRv6 January 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Packet Header for Encrypted Payload via SRv6 . . . . . . . . 4
5. Gap Analysis of the Existing Soluitons . . . . . . . . . . . 5
6. BGP Extension . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Process Illustration . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7
12.2. References . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
A Network Service Provider (NSP) managed SRv6 domain, designed to be
restricted to authorized users, is often considered a trusted and
secure domain ([RFC8754], [RFC8402], [RFC8986]). However, in certain
cases, users or applications demand an elevated level of security,
necessitating the encryption of their data flows even within NSP
managed networks like SRv6. The need for such robust security
measures arises from the sensitivity and confidentiality of the
information being transmitted. By encrypting data flows within those
networks, organizations can fortify their defenses against potential
threats, ensuring that unauthorized access or tampering is thwarted.
This heightened security posture becomes particularly crucial for
entities handling sensitive data, such as financial institutions,
government agencies, or organizations dealing with proprietary and
classified information. Employing encryption over NSP managed
Wang, et al. Expires 29 July 2024 [Page 2]
Internet-Draft IPSec for BGP Enabled Services over SRv6 January 2024
networks, including technologies like SRv6, adds an extra layer of
protection, safeguarding valuable data from potential breaches and
enhancing overall network security.
This document describes an approach to encrypting selective user data
flows using IPsec and then orchestrating the encrypted flows based on
the SRv6 Policy path. This approach ensures that data is protected
from unauthorized access or interception during transit while
enabling flexible and efficient service orchestration. By leveraging
the capabilities of SRv6, it is possible to create a highly dynamic
and adaptable network environment that can meet the evolving needs of
users and applications.
2. Terminology
SRv6: Segment Routing over IPv6
ESP: Encapsulating Security Payload
IPSec: Internet Protocol Security
SA: Security Association
3. Scenarios
+--+ +--+ +--+
,|P1|---------|P3|-------|P5|
/ +/-+ +/-+ +/-+\
.` | | | `.
VPN1_ / | | | . ,VPN1
'+---+/ | | | \ +---+/
|PE1|\ | | | '|PE2|
.+---+ \ | | | / +---+-,VPN2
VPN2`. / \ | | | / / .
| | \ | | | / | |
| | \ +\-+ +\-+ +\-+ / | |
| | '|P2|---------|P4|-------|P6|/ | |
| | +--+ +--+ +--+ | |
| |<------------------------------------------>| |
| | SRv6 Policy | |
\<------------------------------------------------>\
VPN Over SRv6 Policy
As illustrated in the preceding figure, the service route from PE1 to
PE2 spans the backbone network. To attain the optimal service SLA,
the utilization of SRv6 Policy becomes essential to orchestrate the
service path. VPN1, due to its specific service requirements,
demands heightened confidentiality. Consequently, VPN1 packets must
Wang, et al. Expires 29 July 2024 [Page 3]
Internet-Draft IPSec for BGP Enabled Services over SRv6 January 2024
undergo encryption before traversing the path orchestrated by SRv6.
This precautionary measure ensures the prevention of any potential
leakage at intermediate nodes along the route. In contrast, VPN2
entails regular traffic without the necessity for additional
encryption.
4. Packet Header for Encrypted Payload via SRv6
The placement of the SRv6 header [RFC8754] outside the IPsec ESP
(Encapsulating Security Payload) [RFC4303] encrypted payload is
crucial for the seamless traversal of packets through an SRv6 domain.
Placing the SRv6 header outside the encrypted payload allows the SRv6
domain to process and manipulate routing information without
compromising the integrity and confidentiality provided by IPsec ESP.
As the SRv6 header contains routing instructions and segments that
guide the packet through the network, its visibility to the SRv6
domain is essential for proper routing decisions. By keeping the
SRv6 header unencrypted, the SRv6-enabled devices within the domain
can interpret and apply segment routing policies accurately, ensuring
efficient packet forwarding while maintaining the necessary security
measures provided by IPsec ESP for the payload. This separation of
concerns enables a harmonious integration of SRv6 and IPsec,
optimizing both routing flexibility and security within the network.
The following figure shows the encapsulated packet format:
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| Link MAC Header | | Link MAC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| Eth Type = IPv6 | | Eth Type = IPv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Header | | IPv6 Header |
| NextHeader=RH | | NextHeader=RH |
+-----------------------+ +-----------------------+
| IPv6 EH | | IPv6 EH(SRH) |
|NextHeader = IPv4/IPv6 | | NextHeader = ESP |
+-----------------------+ +-----------------------+
| User IPv4/6 Payload | | ESP Header |
+-----------------------+ +-----------------------+
Standard SRv6 Packet | User IPv4/6 Payload |
+-----------------------+
| ESP Trailer |
+-----------------------+
ESP in SRv6 Packet
Wang, et al. Expires 29 July 2024 [Page 4]
Internet-Draft IPSec for BGP Enabled Services over SRv6 January 2024
5. Gap Analysis of the Existing Soluitons
The BGP Tunnel Encapsulation Attribute defined in [RFC9012] can be
advertised with service routes to indicate the properties of the
tunnels that can carry the service routes. However, it is worth
noting that [RFC9012] does not sufficiently address the integration
of IPsec ESP with SRv6, especially regarding segment routing
policies. Further analysis is required to determine the optimal
approach to leverage the BGP Tunnel Encapsulation Attribute to
advertise IPsec ESP-related parameters and the SRv6 SIDS information
for the service routes.
The [I-D.ietf-bess-secure-evpn] defines a methodology for advertising
IPSec information for a service route to other PEs via BGP. The
[I-D.ietf-bess-secure-evpn] introduces a new Tunnel Type, ESP-
Transport, into the existing framework outlined in [RFC9012]. The
Tunnel Type ESP-Transport indicates that the service routes should be
encapsulated by VXLAN, with the associated IPsec parameters dictating
the encryption of the VXLAN encapsulated payload. While this
approach facilitates the continued use of VXLAN tunnels and ensures
that IPsec ESP encrypts the entire VXLAN encapsulated payload, it is
not be ideal for traversing the SRv6 domain. Encrypting the VXLAN
encapsulated payload exclusively with IPsec ESP poses a challenge for
service providers seeking to leverage SRv6 benefits while maintaining
robust security measures. The SRv6 header contains routing
instructions and segments that guide the packet through the SRv6
domain; its visibility to the SRv6 domain is essential for proper
routing decisions.
There is a need for a new Tunnel Type to signify that services must
be encrypted prior to the outer SRv6 encapsulation. This enhancement
ensures compatibility with SRv6, safeguarding both the advantages of
SRv6 and the security of user data.
6. BGP Extension
This document introduces a new Tunnel Type referred to as ESP-
Encrypted-Payload, within the framework of the Tunnel Encapsulation
Attribute specified by [RFC9012]. The ESP-Encrypted-Payload Tunnel
Type serves the purpose of explicitly specifying that data packets
must undergo encryption using ESP Transport. Notably, it provides
the flexibility for the Outer header to be integrated into an
underlay network, such as SRv6. Pertinent Sub-TLVs associated with
IPsec, as detailed in [I-D.ietf-idr-sdwan-edge-discovery], including
IPsec SA Nonce, IPsec Public Key, and IPsec SA Proposal, can be
appended under the ESP-Encrypted-Payload Tunnel Type. This document
seamlessly inherits the IPsec sub-TLVs, ensuring the effective
implementation of secure service encryption.
Wang, et al. Expires 29 July 2024 [Page 5]
Internet-Draft IPSec for BGP Enabled Services over SRv6 January 2024
When a service route includes extra information, such as the color
and SRv6 SID (Segment Identifier), a process of iteration is required
to direct the route towards an SRv6 Provider Edge (PE) or an SRv6
Policy. The selection of the specific route for this iteration is
determined either by the local tunnel policy or explicitly specified
by the Tunnel-Encap Extend Community
7. Process Illustration
Let's take the scenario described in section 3 as an example.:
1. PE1 obtains IPSec related parameters by configuration, from its
management system, or via negotiation, including IPSec SA encryption
algorithms, keying material, nonce, and security policies, etc..
2. PE1 detects its attached VPN routes, such as EVPN Type 5 Prefix
Routes or others.
3. PE1 adds a Tunnel-Encapsulation Attribute to the routes based on
local policies. The Tunnel-Type parameter is ESP-Encrypted-Payload.
4. PE1 obtains the VPN route and carries tunnel information, such as
the VPN SID and Color Extended Community, based on the local policy.
5. PE1 advertises the route to PE2 through RRs.
6. After receiving the route advertised by PE1, PE2 performs IPSec
key negotiation based on the ESP-Transport Tunnel-Encapsulation
Attribute carried in the route and indicates that the route needs to
be encrypted using IPSec.
7. After PE2 receives the route advertised by PE1 and carries
information such as the VPN ID and color, PE2 associates the route
with the SRv6 tunnel.
8. When PE2 receives the CE-side traffic that matches the route
advertised by PE1. PE2 performs IPSec encryption based on the
indicated IPSec sub-TLVs advertised by PE1, encapsulates the traffic
into an SRv6 tunnel based on the indicated tunnel information, and
sends the traffic to PE1 along the tunnel information.
9. After receiving the traffic from PE2, PE1 finds the corresponding
VRF based on the SRv6 tunnel information and decrypts the packets to
obtain the original user packet payload. Searches the VRF table and
forwards traffic to the CE based on the user packet header.
Wang, et al. Expires 29 July 2024 [Page 6]
Internet-Draft IPSec for BGP Enabled Services over SRv6 January 2024
8. IANA Considerations
Tunnel-Type ESP-Transport-Only-Payload needs to be allocated by IANA.
9. Security Considerations
In this solution, the specified data packet is encrypted after being
sent from the PE. This process ensures that even if an intermediate
node obtains the related data packet, it is difficult to obtain the
real content information. By implementing this encryption process,
the security of the entire solution is significantly improved,
providing better protection for high-security services such as
finance.
10. Acknowledgements
NA
11. Contributors
Yulin Shi
Huawei
Email: shiyulin@huawei.com
Xiangfeng Ding
Huawei
Email: dingxiangfeng@huawei.com
Shunwan Zhuang
Huawei
Email: zhuangshunwan@huawei.com
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
12.2. References
Wang, et al. Expires 29 July 2024 [Page 7]
Internet-Draft IPSec for BGP Enabled Services over SRv6 January 2024
[I-D.ietf-bess-secure-evpn]
Sajassi, A., Banerjee, A., Thoria, S., Carrel, D., Weis,
B., and J. Drake, "Secure EVPN", Work in Progress,
Internet-Draft, draft-ietf-bess-secure-evpn-00, 22 June
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
bess-secure-evpn-00>.
[I-D.ietf-idr-sdwan-edge-discovery]
Dunbar, L., Majumdar, K., Hares, S., Raszuk, R., and V.
Kasiviswanathan, "BGP UPDATE for SD-WAN Edge Discovery",
Work in Progress, Internet-Draft, draft-ietf-idr-sdwan-
edge-discovery-12, 14 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
sdwan-edge-discovery-12>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
Authors' Addresses
Haibo Wang
Huawei
Beijing
P.R. China
Email: rainsword.wang@huawei.com
Linda Dunbar
Futurewei
Email: ldunbar@futurewei.com
Wang, et al. Expires 29 July 2024 [Page 8]
Internet-Draft IPSec for BGP Enabled Services over SRv6 January 2024
Cheng Sheng
Huawei
Beijing
P.R. China
Email: shengcheng@huawei.com
Hang Shi
Huawei
Beijing
P.R. China
Email: shihang9@huawei.com
Wang, et al. Expires 29 July 2024 [Page 9]
