Considerations for SRv6 across Untrusted Domain
draft-lin-spring-srv6-across-untrusted-domain-02
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Changwang Lin , Ce Zhou , Mengxiao Chen | ||
| Last updated | 2023-12-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-lin-spring-srv6-across-untrusted-domain-02
Network Working Group C. Lin
Internet Draft New H3C Technologies
Intended status: Informational C.Zhou
Expires: June 22, 2024 China Mobile
M. Chen
New H3C Technologies
December 22, 2023
Considerations for SRv6 across Untrusted Domain
draft-lin-spring-srv6-across-untrusted-domain-02
Abstract
Segment Routing operates within a trusted domain. There are some
scenarios in which the whole SRv6 domain is separated by untrusted
domain and SRv6 packets need to traverse it. This document describes
some use cases of SRv6 across untrusted domain, and proposes a
solution using IPSec technology.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 22, 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lin, et al. Expire June 17, 2024 [Page 1]
Internet-Draft SRv6 across Untrusted Domain December 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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 Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................2
1.1. Requirements Language.....................................3
2. Use Case.......................................................3
2.1. SRv6 Enterprise Network across Internet...................3
2.2. SRv6 SDWAN to Cloud DC across Third-party Provider........4
3. Solution.......................................................4
4. Security Considerations........................................5
5. IANA Considerations............................................6
6. References.....................................................6
6.1. Normative References......................................6
Authors' Addresses................................................7
1. Introduction
Segment Routing (SR) [RFC8402] leverages the source routing
paradigm. A node steers a packet through an SR Policy instantiated
as an ordered list of instructions called "segments". Segment
Routing (SR) can be applied to the IPv6 data plane using Segment
Routing Header (SRH) [RFC8754], which is called SRv6.
Due to security concerns, [RFC8402] specifies that SR operates
within a trusted domain and Traffic MUST be filtered at the domain
boundaries. [RFC8754] describes the deployment model for securing
the SRv6 domain:
o External Interface of each edge node: Any packet entering the SR
domain and destined to a SID within the SR domain is dropped.
o Internal Interface of each node: Packets to SIDs from source
addresses outside the SR domain are dropped.
There are some scenarios in which the whole SRv6 domain is separated
by untrusted domain and SRv6 packets need to traverse it. As shown
in Figure 1, Domain 1 and Domain 2 are operated by the same
administrative entity, but they are connected by a network of
Lin, et al. Expires June 22, 2024 [Page 2]
Internet-Draft SRv6 across Untrusted Domain December 2023
another operator. The two domains can trust each other and may be
regarded as one large SRv6 domain. When traffics are forwarded from
one of the SRv6 domain to another, SRH is carried in the packets and
guides the forwarding path in both the two SRv6 domains. In the
meantime, those SRv6 packets need to traverse the intermediate
untrusted domain. The mechanism of SRv6 across untrusted domain
should comply with the security deployment of SRv6 domain and reduce
the risks introduced by the intermediate untrusted domain.
*************** ****************** ***************
*SRv6 Domain 1*---*Untrusted Domain*---*SRv6 Domain 2*
*************** ****************** ***************
R1 ->...-> R2 -> . . . . . . . . . -> R3 ->...-> R4
+----+ +----+
|IPv6| |IPv6|
+----+ +----+
|SRH | |SRH |
+----+ +----+
|... | |... |
+----+ +----+
Figure 1: SRv6 across Untrusted Domain
This document describes some use cases of SRv6 across untrusted
domain, and proposes a solution using IPSec technology.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Use Case
2.1. SRv6 Enterprise Network across Internet
In the enterprise network shown in Figure 2, the branch and center
networks are SRv6 capable, but the intermediate network is Internet
which is not trusted.
When the host H1 in enterprise branch needs to visit the server S4
in enterprise center, it sends IPv6 packet with SRH carrying SRv6
SIDS, including the SIDs for the forwarding path in the branch and
the SIDs for the forwarding path in the center. After the packet is
Lin, et al. Expires June 22, 2024 [Page 3]
Internet-Draft SRv6 across Untrusted Domain December 2023
forwarded to R2, it needs to traverse the Internet and reaches R3.
Then it is forwarded from R3 to S4 by the instructions of remaining
SRv6 SIDs in SRH.
------------ ------------
/ / / /
/ H1 ... R2 / --- Internet --- / R3 ... S4 /
/ / / /
------------ ------------
Branch Center
Figure 2: Enterprise Network across Internet
2.2. SRv6 SDWAN to Cloud DC across Third-party Provider
As shown in Figure 3, SRv6 SDWAN provides the connectivity to Cloud
Data Center (DC). CPE1 is directly connected to PE1, but CPE2 is
connected to PE1 through a third-party ISP.
When a client needs to access the cloud service, CPE encapsulates
the client packet with an outer IPv6 Header and SRH. The SRv6 SIDs
in SRH may include the Binding SID of PE1, the SID of GW, and the
Service SID of cloud service. Both CPE1 and CPE2 are trusted by the
service provider, but the packet from CPE2 needs to traverse a
third-party ISP which is not untrusted.
---------------------
/ Service Provider /
+------+ /+-----+ +-----+ / +-----+
| CPE1 |---/-| PE1 |----| PE2 |-/---| GW |
+------+ / +-----+ +-----+/ +-----+
/ | / Cloud DC
---------------------
|
---------
+------+ / Third- /
| CPE2 |---/ party /
+------+ / ISP /
---------
Figure 3: SDWAN to Cloud DC across Third-party Provider
3. Solution
This document proposes a solution for SRv6 across untrusted domain
using IPSec technology [RFC4301]. The edge nodes of two separated
SRv6 domains are interconnected by an IPSec tunnel. When an SRv6
packets traverse the untrusted domain, it is encapsulated in an
Lin, et al. Expires June 22, 2024 [Page 4]
Internet-Draft SRv6 across Untrusted Domain December 2023
outer IPv6 Header along with AH and ESP, which is the tunnel mode of
IPSec. The whole SRv6 packet is encrypted by the ESP. After the
packet reaches the other SRv6 domain, the outer IPv6 Header is
decapsulated and the inner SRv6 packet continues to be forwarded
along the path instructed by the remaining SIDs in SRH.
*************** ================ ***************
*SRv6 Domain 1*---| IPSec Tunnel |---*SRv6 Domain 2*
*************** ================ ***************
Untrusted Domain
+------------------------------------------------+
|IPv6 Header|AH|ESP|IPv6 Header|SRH|Payload|ESP-T|
+------------------------------------------------+
Figure 4: SRv6 over IPSec
The edge node of one SRv6 domain should steer the SRv6 packet
towards the other SRv6 domain onto the IPSec tunnel. The steering
methods may include, but not limited to, the following ones:
o Config static routes for the SIDs or the locator of the opposite
edge node, with the next-hop heading to the IPSec tunnel.
o Allocate an End.X SID for the IPSec tunnel and include it into
the SR Policy.
From the perspective of SRv6 domain, the interface facing the
untrusted domain on the edge node is external interface. According
to [RFC8754], any packet entering the SRv6 domain from the external
interface and destined to a SID within the SRv6 domain will be
dropped. When the edge node receives a packet from the IPSec tunnel,
the destination of the outer IPv6 Header is its tunnel address, not
a SID. So, the proposed solution complies with the security
deployment of SRv6 domain. In addition, the SRH of inner packet is
encrypted by the ESP, hence the source-routing information is not
exposed when the packet traverses the untrusted domain, which can
reduce the risks introduced by the intermediate untrusted domain.
Note that the security of the proposed solution relies on the IPSec
mechanism. If the IPSec tunnel is hacked, the SRv6 domain may be
exposed to attacks.
4. Security Considerations
TBD.
Lin, et al. Expires June 22, 2024 [Page 5]
Internet-Draft SRv6 across Untrusted Domain December 2023
5. IANA Considerations
This document has no IANA actions.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017
[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>.
Lin, et al. Expires June 22, 2024 [Page 6]
Internet-Draft SRv6 across Untrusted Domain December 2023
Authors' Addresses
Changwang Lin
New H3C Technologies
China
Email: linchangwang.04414@h3c.com
Ce Zhou
China Mobile
China
zhouce@gd.chinamobile.com
Mengxiao Chen
New H3C Technologies
China
Email: chen.mengxiao@h3c.com
Lin, et al. Expires June 22, 2024 [Page 7]