IPSec for BGP Enabled Services over SRv6
draft-wang-bess-secservice-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Haibo Wang , Linda Dunbar , Cheng Sheng , Hang Shi | ||
| Last updated | 2023-07-10 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-bess-secservice-00
Network Working Group H. Wang
Internet-Draft Huawei
Intended status: Standards Track L. Dunbar
Expires: 11 January 2024 Futurewei
C. Sheng
H. Shi
Huawei
10 July 2023
IPSec for BGP Enabled Services over SRv6
draft-wang-bess-secservice-00
Abstract
For certain users, security is of paramount importance. Even when
building their own backbone networks, these users require end-to-end
service encryption to ensure the confidentiality and integrity of
their data. In such scenarios, IPsec can be used to provide flexible
and robust encryption capabilities, while SRv6 can be used to guide
the forwarding of data packets along different paths on the network.
By combining these technologies, users can create a highly secure and
efficient network environment that meets their specific needs and
requirements.
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 11 January 2024.
Wang, et al. Expires 11 January 2024 [Page 1]
Internet-Draft IPSec for BGP Enabled Services over SRv6 July 2023
Copyright Notice
Copyright (c) 2023 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. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
5. Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. References . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Data security is of paramount importance to many users, particularly
those in the financial industry. As a result, many large-scale
financial users have constructed their own backbone networks, some of
which traverse third-party backbone networks. In order to enable
flexible orchestration and control of services, emerging technologies
such as SRv6 have been introduced. Normally, SRv6 domain is
considered trusted domain and secure([RFC8754], [RFC8402],
[RFC8986]). However, despite the benefits of these technologies,
customers still require encryption of services to prevent data
leakage during orchestration and scheduling on the backbone network.
This is particularly important given the sensitive nature of
financial data and the potential consequences of data breaches. As
such, there is a need for robust and effective encryption mechanisms
to ensure the security of data in transit.
Wang, et al. Expires 11 January 2024 [Page 2]
Internet-Draft IPSec for BGP Enabled Services over SRv6 July 2023
In order to provide this type of service, it is necessary to encrypt
user data and then orchestrate it based on the SRv6 Policy path.
This approach ensures that data is protected from unauthorized access
or interception during transit, while also 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.
The BGP Tunnel Encapsulation Attribute is defined in [RFC9012]. This
attribute can be advertised with service routes to indicate the
creation of tunnels and encapsulation of tunnel information.
However, it is worth noting that this approach may not be entirely
consistent with the business requirements described above. As such,
further analysis is required to determine the optimal approach to
meet these requirements while also leveraging the benefits of the BGP
Tunnel Encapsulation Attribute. This may involve the development of
new mechanisms or the modification of existing ones to ensure that
they align with the specific needs of the business and provide a
robust and effective solution.
The [I-D.ietf-bess-secure-evpn] specification outlines a method for
conveying IPSec information in a service route to indicate how to
encrypt a service. This approach enables service routes to continue
using VXLAN tunnels and encapsulate VXLAN-encapsulated service
packets in ESP. However, it is important to note that this mode is
not applicable to SRv6. In SRv6 encapsulation, the SID list is used
to guide how data packets are forwarded along different paths on the
network, based on the SRv6-Policy. As a result, the SID list
shouldn't be encapsulated in ESP. This presents a challenge for
service providers who wish to leverage the benefits of SRv6 while
also ensuring the security and integrity of user data.
2. Terminology
SRv6: Segment Routing over IPv6
ESP: Encapsulating Security Payload
IPSec: Internet Protocol Security
SA: Security Association
3. Scenarios
Wang, et al. Expires 11 January 2024 [Page 3]
Internet-Draft IPSec for BGP Enabled Services over SRv6 July 2023
+--+ +--+ +--+
,|P1|---------|P3|-------|P5|
/ +/-+ +/-+ +/-+\
.` | | | `.
VPN1_ / | | | . ,VPN1
'+---+/ | | | \ +---+/
|PE1|\ | | | '|PE2|
.+---+ \ | | | / +---+-,VPN2
VPN2`. / \ | | | / / .
| | \ | | | / | |
| | \ +\-+ +\-+ +\-+ / | |
| | '|P2|---------|P4|-------|P6|/ | |
| | +--+ +--+ +--+ | |
| |<------------------------------------------>| |
| | SRv6 Policy | |
\<------------------------------------------------>\
VPN Over SRv6 Policy
As shown in the preceding figure, the service from PE1 to PE2
traverses the backbone network. To achieve the optimal service SLA,
SRv6 Policy needs to be used to orchestrate the service path. VPN1
requires higher confidentiality requirements because of its service
nature. Therefore, all data needs to be encrypted to prevent leakage
at intermediate nodes. Therefore, packets of VPN1 need to be
encrypted before being forwarded along the path orchestrated by the
SRv6 policy.
4. BGP Extensions
The BGP Tunnel Encapsulation Attribute is defined in [RFC9012], and
is utilized by BGP services to convey information regarding the need
for encryption of service routes. Specifically, the tunnel type is
set to ESP-Transport, as defined in the [I-D.ietf-bess-secure-evpn].
However, this encapsulation mode is not suitable for SRv6.
Therefore, a new encapsulation mode needs to be introduced to
instruct services to be encrypted before outer tunnel encapsulation.
When an EVPN Prefix Route is utilized to advertise a service route
and carries the Tunnel Encapsulation Attribute with Tunnel-type set
to ESP-Transport-Only-Payload, it indicates that data packets
accessing the address must be encrypted using ESP. To facilitate
this encryption, the [I-D.ietf-idr-sdwan-edge-discovery] document has
defined the IPsec SA Nonce, IPsec Public Key, and IPsec SA Proposal,
which are essential for ensuring the secure transmission of user
data. This document directly inherits the definitions of these
critical pieces of information, which are necessary for the proper
implementation of secure service encryption.
Wang, et al. Expires 11 January 2024 [Page 4]
Internet-Draft IPSec for BGP Enabled Services over SRv6 July 2023
The IPsec SA Nonce, IPsec Public Key, and IPsec SA Proposal required
for service encryption have been defined in
[I-D.ietf-idr-sdwan-edge-discovery]. This document directly inherits
the definitions of this information.
When a service route carries additional information, such as the
color and SRv6 SID, it is necessary to iterate the route to an SRv6
BE or SRv6 Policy. The specific route to be utilized is determined
by the local tunnel policy or specified by the Tunnel-Encap Extend
Community.
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
5. Process
Let's take the scenario described in section 3 as an example.:
1. PE1 obtains IPSec information from BGP, including IPSec SA
Nounce.
2. PE1 obtains VPN routes, such as EVPN Type 5 Prefix Routes, and
adds Tunnel-Encapsulation Attribute to the routes based on local
policies. The Tunnel-Type parameter is ESP-Transport-Only-Payload.
3. PE1 obtains the VPN route and carries tunnel information, such as
the VPN SID and Color Extended Community, based on the local policy.
4. PE1 advertises the route to PE2 through RRs.
Wang, et al. Expires 11 January 2024 [Page 5]
Internet-Draft IPSec for BGP Enabled Services over SRv6 July 2023
5. 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.
6. 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.
7. PE2 receives the CE-side traffic that matches the route
advertised by PE1. PE2 performs IPSec encryption based on the
indicated IPSec encryption information, encapsulates the traffic into
an SRv6 tunnel based on the indicated tunnel information, and sends
the traffic to PE1 along the tunnel information.
8. 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 information because the packets carry
ESP information. Searches the VRF table and forwards traffic to the
CE based on the user packet information.
6. IANA Considerations
Tunnel-Type ESP-Transport-Only-Payload needs to be allocated by IANA.
7. 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.
8. Acknowledgements
NA
9. Contributors
Wang, et al. Expires 11 January 2024 [Page 6]
Internet-Draft IPSec for BGP Enabled Services over SRv6 July 2023
Yulin Shi
Huawei
Email: shiyulin@huawei.com
Xiangfeng Ding
Huawei
Email: dingxiangfeng@huawei.com
Shunwan Zhuang
Huawei
Email: zhuangshunwan@huawei.com
10. References
10.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>.
10.2. References
[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., Hares, S., Raszuk, R., Majumdar, K., Mishra,
G. S., and V. Kasiviswanathan, "BGP UPDATE for SD-WAN Edge
Discovery", Work in Progress, Internet-Draft, draft-ietf-
idr-sdwan-edge-discovery-10, 23 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
sdwan-edge-discovery-10>.
[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>.
Wang, et al. Expires 11 January 2024 [Page 7]
Internet-Draft IPSec for BGP Enabled Services over SRv6 July 2023
[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
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 11 January 2024 [Page 8]