draft-ietf-mpls-sr-over-ip-03.txt   draft-ietf-mpls-sr-over-ip-04.txt 
Network Working Group X. Xu Network Working Group X. Xu
Internet-Draft Alibaba, Inc Internet-Draft Alibaba, Inc
Intended status: Standards Track S. Bryant Intended status: Standards Track S. Bryant
Expires: September 4, 2019 Huawei Expires: October 15, 2019 Huawei
A. Farrel A. Farrel
Old Dog Consulting Old Dog Consulting
S. Hassan S. Hassan
Cisco Cisco
W. Henderickx W. Henderickx
Nokia Nokia
Z. Li Z. Li
Huawei Huawei
March 3, 2019 April 13, 2019
SR-MPLS over IP SR-MPLS over IP
draft-ietf-mpls-sr-over-ip-03 draft-ietf-mpls-sr-over-ip-04
Abstract Abstract
MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source
routing paradigm in which the sender of a packet is allowed to routing paradigm in which the sender of a packet is allowed to
partially or completely specify the route the packet takes through partially or completely specify the route the packet takes through
the network by imposing stacked MPLS labels on the packet. SR-MPLS the network by imposing stacked MPLS labels on the packet. SR-MPLS
could be leveraged to realize a source routing mechanism across MPLS, can be leveraged to realize a source routing mechanism across MPLS,
IPv4, and IPv6 data planes by using an MPLS label stack as a source IPv4, and IPv6 data planes by using an MPLS label stack as a source
routing instruction set while preserving backward compatibility with routing instruction set while making no changes to SR-MPLS
SR-MPLS. specifications and interworking with SR-MPLS implementations.
This document describes how SR-MPLS capable routers and IP-only This document describes how SR-MPLS capable routers and IP-only
routers can seamlessly co-exist and interoperate through the use of routers can seamlessly co-exist and interoperate through the use of
SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in-
UDP as defined in RFC 7510. UDP as defined in RFC 7510.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2019. This Internet-Draft will expire on October 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5 3. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5
3.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5 3.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5
3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 7 3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 7
3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8 3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8
3.2.2. Packet Forwarding without Penultimate Hop Popping . . 9 3.2.2. Packet Forwarding without Penultimate Hop Popping . . 9
3.2.3. Additional Forwarding Procedures . . . . . . . . . . 10 3.2.3. Additional Forwarding Procedures . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
MPLS Segment Routing (SR-MPLS) [I-D.ietf-spring-segment-routing-mpls] MPLS Segment Routing (SR-MPLS) [I-D.ietf-spring-segment-routing-mpls]
is an MPLS data plane-based source routing paradigm in which the is an MPLS data plane-based source routing paradigm in which the
sender of a packet is allowed to partially or completely specify the sender of a packet is allowed to partially or completely specify the
route the packet takes through the network by imposing stacked MPLS route the packet takes through the network by imposing stacked MPLS
labels on the packet. SR-MPLS uses an MPLS label stack to encode a labels on the packet. SR-MPLS uses an MPLS label stack to encode a
source routing instruction set. This can be used to realize a source source routing instruction set. This can be used to realize a source
routing mechanism that can operate across MPLS, IPv4, and IPv6 data routing mechanism that can operate across MPLS, IPv4, and IPv6 data
planes. This approach preserves backward compatibility with SR-MPLS. planes. This approach preserves makes no changes to SR-MPLS
specifications and allows interworking with SR-MPLS implementations.
More specifically, the source routing instruction set information More specifically, the source routing instruction set information
contained in a source routed packet could be uniformly encoded as an contained in a source routed packet could be uniformly encoded as an
MPLS label stack no matter whether the underlay is IPv4, IPv6, or MPLS label stack no matter whether the underlay is IPv4, IPv6, or
MPLS. MPLS.
This document describes how SR-MPLS capable routers and IP-only This document describes how SR-MPLS capable routers and IP-only
routers can seamlessly co-exist and interoperate through the use of routers can seamlessly co-exist and interoperate through the use of
SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in-
UDP [RFC7510]. UDP [RFC7510].
skipping to change at page 4, line 27 skipping to change at page 4, line 27
(_______) ( ) (_______) (_______) ( ) (_______)
(________________________) (________________________)
Figure 1: SR-MPLS in UDP to Tunnel Between SR-MPLS Sites Figure 1: SR-MPLS in UDP to Tunnel Between SR-MPLS Sites
o If encoding of entropy ([RFC6790] is desired, IP tunneling o If encoding of entropy ([RFC6790] is desired, IP tunneling
mechanisms that allow encoding of entropy, such as MPLS-in-UDP mechanisms that allow encoding of entropy, such as MPLS-in-UDP
encapsulation [RFC7510] where the source port of the UDP header is encapsulation [RFC7510] where the source port of the UDP header is
used as an entropy field, may be used to maximize the utilization used as an entropy field, may be used to maximize the utilization
of ECMP and/or LAG, especially when it is difficult to make use of of ECMP and/or LAG, especially when it is difficult to make use of
the entropy label mechanism. Refer to the entropy label mechanism. This is to be contrasted with
[I-D.ietf-mpls-spring-entropy-label]) for more discussion about [RFC4023] where MPLS-in-IP does not provide for an entropy
using entropy labels in SR-MPLS. mechanism. Refer to [I-D.ietf-mpls-spring-entropy-label]) for
more discussion about using entropy labels in SR-MPLS.
o Tunneling MPLS into IP provides a technology that enables SR in an o Tunneling MPLS into IP provides a technology that enables SR in an
IPv4 and/or IPv6 network where the routers do not support SRv6 IPv4 and/or IPv6 network where the routers do not support SRv6
capabilities [I-D.ietf-6man-segment-routing-header] and where MPLS capabilities [I-D.ietf-6man-segment-routing-header] and where MPLS
forwarding is not an option. This is shown in Figure 2. forwarding is not an option. This is shown in Figure 2.
__________________________________ __________________________________
__( IP Network )__ __( IP Network )__
__( )__ __( )__
( -- -- -- ) ( -- -- -- )
skipping to change at page 6, line 5 skipping to change at page 6, line 5
or all of the next-hops along the shortest path towards a prefix or all of the next-hops along the shortest path towards a prefix
Segment Identifier (prefix-SID) are IP-only routers. Segment Identifier (prefix-SID) are IP-only routers.
Consider router A that receives a labeled packet with top label L(E) Consider router A that receives a labeled packet with top label L(E)
that corresponds to the prefix-SID SID(E) of prefix P(E) advertised that corresponds to the prefix-SID SID(E) of prefix P(E) advertised
by router E. Suppose the i-th next-hop router (termed NHi) along the by router E. Suppose the i-th next-hop router (termed NHi) along the
shortest path from router A toward SID(E) is not SR-MPLS capable shortest path from router A toward SID(E) is not SR-MPLS capable
while both routers A and E are SR-MPLS capable. The following while both routers A and E are SR-MPLS capable. The following
processing steps apply: processing steps apply:
o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. o Router E is SR-MPLS capable, so it advertises a Segment Routing
Router E is SR-MPLS capable, so it advertises an SRGB as described Global Block (SRGB) using the mechanisms described in
in [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions]. The SRGB is defined
in [RFC8402].
o When Router E advertises the prefix-SID SID(E) of prefix P(E) it o When Router E advertises the prefix-SID SID(E) of prefix P(E) it
MUST also advertise the encapsulation endpoint and the tunnel type MUST also advertise the encapsulation endpoint and the tunnel type
of any tunnel used to reach E. It does this using the mechanisms of any tunnel used to reach E. It can do this using the
described in [I-D.ietf-isis-encapsulation-cap] or mechanisms described in [I-D.ietf-isis-encapsulation-cap] or
[I-D.ietf-ospf-encapsulation-cap]. [I-D.ietf-ospf-encapsulation-cap].
o If A and E are in different IGP areas/levels, then: o If A and E are in different IGP areas/levels, then:
* The OSPF Tunnel Encapsulation TLV * The OSPF Tunnel Encapsulation TLV
[I-D.ietf-ospf-encapsulation-cap] or the ISIS Tunnel [I-D.ietf-ospf-encapsulation-cap] or the ISIS Tunnel
Encapsulation sub-TLV [I-D.ietf-isis-encapsulation-cap] is Encapsulation sub-TLV [I-D.ietf-isis-encapsulation-cap] is
flooded domain-wide. flooded domain-wide.
* The OSPF SID/label range TLV * The OSPF SID/label range TLV
skipping to change at page 6, line 41 skipping to change at page 6, line 42
+ If router E is running ISIS it uses the extended + If router E is running ISIS it uses the extended
reachability TLV (TLVs 135, 235, 236, 237) and associates reachability TLV (TLVs 135, 235, 236, 237) and associates
the IPv4/IPv6 or IPv4/IPv6 source router ID sub-TLV(s) the IPv4/IPv6 or IPv4/IPv6 source router ID sub-TLV(s)
[RFC7794]. [RFC7794].
+ If router E is running OSPF it uses the OSPFv2 Extended + If router E is running OSPF it uses the OSPFv2 Extended
Prefix Opaque LSA [RFC7684] and sets the flooding scope to Prefix Opaque LSA [RFC7684] and sets the flooding scope to
AS-wide. AS-wide.
* If router E is running ISIS and advertises the ISIS * If router E is running ISIS and advertises the ISIS capability
capabilities TLV (TLV 242) [RFC7981], it MUST set the "router- TLV (TLV 242) [RFC7981], it MUST set the "router-ID" field to a
ID" field to a valid value or include an IPV6 TE router-ID sub- valid value or include an IPV6 TE router-ID sub-TLV (TLV 12),
TLV (TLV 12), or do both. The "S" bit (flooding scope) of the or do both. The "S" bit (flooding scope) of the ISIS
ISIS capabilities TLV (TLV 242) MUST be set to "1" . capability TLV (TLV 242) MUST be set to "1" .
o Router A programs the FIB entry for prefix P(E) corresponding to o Router A programs the FIB entry for prefix P(E) corresponding to
the SID(E) as follows: the SID(E) as follows:
* If the NP flag in OSPF or the P flag in ISIS is clear: * If the NP flag in OSPF or the P flag in ISIS is clear:
pop the top label pop the top label
* If the NP flag in OSPF or the P flag in ISIS is set: * If the NP flag in OSPF or the P flag in ISIS is set:
swap the top label to a value equal to SID(E) plus the lower swap the top label to a value equal to SID(E) plus the lower
bound of the SRGB of E bound of the SRGB of E
Once constructed, the FIB can be used to tell a router how to process Once constructed, the FIB can be used by a router to tell it how to
packets. It encapsulates the packets according to the encapsulation process packets. It encapsulates the packets according to the
advertised in [I-D.ietf-isis-encapsulation-cap] or appropriate encapsulation (for example, as advertised using the
mechanisms described in [I-D.ietf-isis-encapsulation-cap] or
[I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards
the next hop NHi. the next hop NHi.
3.2. Packet Forwarding Procedures 3.2. Packet Forwarding Procedures
[RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- [RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS-
in-UDP. This approach is applicable where IP-based encapsulation for in-UDP. This approach is applicable where IP-based encapsulation for
MPLS is required and further fine-grained load balancing of MPLS MPLS is required and further fine-grained load balancing of MPLS
packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link
Aggregation Groups (LAGs) is also required. This section provides Aggregation Groups (LAGs) is also required. This section provides
details about the forwarding procedure when when UDP encapsulation is details about the forwarding procedure when UDP encapsulation is
adopted for SR-MPLS over IP. adopted for SR-MPLS over IP. Other encapsulation and tunnelling
mechanisms can be applied using similar techniques, but for clarity
this section uses UDP encapsulation as the exemplar.
Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all
of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes
may be "legacy routers" that cannot handle SR-MPLS packets but can may be "legacy routers" that cannot handle SR-MPLS packets but can
forward IP packets. An SR-MPLS-capable node MAY advertise its forward IP packets. An SR-MPLS-capable node MAY advertise its
capabilities using the IGP as described in Section 3. There are six capabilities using the IGP as described in Section 3. There are six
types of node in an SR-MPLS domain: types of node in an SR-MPLS domain:
o Domain ingress nodes that receive packets and encapsulate them for o Domain ingress nodes that receive packets and encapsulate them for
transmission across the domain. Those packets may be any payload transmission across the domain. Those packets may be any payload
skipping to change at page 8, line 38 skipping to change at page 8, line 44
| L(H) | | L(H) | |Exp Null| | L(H) | | L(H) | |Exp Null|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Packet | ---> | Packet | ---> | Packet | | Packet | ---> | Packet | ---> | Packet |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 3: Packet Forwarding Example with PHP Figure 3: Packet Forwarding Example with PHP
In the example shown in Figure 3, assume that routers A, E, G and H In the example shown in Figure 3, assume that routers A, E, G and H
are SR-MPLS-capable while the remaining routers (B, C, D and F) are are SR-MPLS-capable while the remaining routers (B, C, D and F) are
only capable of forwarding IP packets. Routers A, E, G, and H only capable of forwarding IP packets. Routers A, E, G, and H
advertise their Segment Routing related information via IS-IS or advertise their Segment Routing related information, such as via IS-
OSPF. IS or OSPF.
Now assume that router A (the Domain ingress) wants to send a packet Now assume that router A (the Domain ingress) wants to send a packet
to router H (the Domain egress) via the explicit path {E->G->H}. to router H (the Domain egress) via the explicit path {E->G->H}.
Router A will impose an MPLS label stack on the packet that Router A will impose an MPLS label stack on the packet that
corresponds to that explicit path. Since the next hop toward router corresponds to that explicit path. Since the next hop toward router
E is only IP-capable (B is a legacy transit node), router A replaces E is only IP-capable (B is a legacy transit node), router A replaces
the top label (that indicated router E) with a UDP-based tunnel for the top label (that indicated router E) with a UDP-based tunnel for
MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E and then sends the MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E and then sends the
packet. In other words, router A pops the top label and then packet. In other words, router A pops the top label and then
encapsulates the MPLS packet in a UDP tunnel to router E. encapsulates the MPLS packet in a UDP tunnel to router E.
skipping to change at page 11, line 7 skipping to change at page 11, line 7
SID. SID.
When to use IP-based Tunnel: The description in the previous two When to use IP-based Tunnel: The description in the previous two
sections is based on the assumption that MPLS-over-UDP tunnel is sections is based on the assumption that MPLS-over-UDP tunnel is
used when the nexthop towards the next segment is not MPLS- used when the nexthop towards the next segment is not MPLS-
enabled. However, even in the case where the nexthop towards the enabled. However, even in the case where the nexthop towards the
next segment is MPLS-capable, an MPLS-over-UDP tunnel towards the next segment is MPLS-capable, an MPLS-over-UDP tunnel towards the
next segment could still be used instead due to local policies. next segment could still be used instead due to local policies.
For instance, in the example as described in Figure 4, assume F is For instance, in the example as described in Figure 4, assume F is
now an SR-MPLS-capable transit node while all the other now an SR-MPLS-capable transit node while all the other
assumptions keep unchanged, since F is not identified by a SID in assumptions remain unchanged: since F is not identified by a SID
the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS
according to local policies, router E would replace the current LSP according to local policies, router E replaces the current top
top label with an MPLS-over-UDP tunnel toward router G and send it label with an MPLS-over-UDP tunnel toward router G and send it
out. out. (Note that if an MPLS LSP was preferred, the packet would be
forwarded as native SR-MPLS.)
IP Header Fields: When encapsulating an MPLS packet in UDP, the IP Header Fields: When encapsulating an MPLS packet in UDP, the
resulting packet is further encapsulated in IP for transmission. resulting packet is further encapsulated in IP for transmission.
IPv4 or IPv6 may be used according to the capabilities of the IPv4 or IPv6 may be used according to the capabilities of the
network. The address fields are set as described in Section 2. network. The address fields are set as described in Section 2.
The other IP header fields (such as DSCP code point, or IPv6 Flow The other IP header fields (such as the ECN field [RFC6040], the
Label) on each UDP-encapsulated segment SHOULD be configurable DSCP code point [RFC2983], or IPv6 Flow Label) on each UDP-
according to the operator's policy: they may be copied from the encapsulated segment SHOULD be configurable according to the
header of the incoming packet; they may be promoted from the operator's policy: they may be copied from the header of the
header of the payload packet; they may be set according to incoming packet; they may be promoted from the header of the
instructions programmed to be associated with the SID; or they may payload packet; they may be set according to instructions
be configured dependent on the outgoing interface and payload. programmed to be associated with the SID; or they may be
configured dependent on the outgoing interface and payload.
Entropy and ECMP: When encapsulating an MPLS packet with an IP Entropy and ECMP: When encapsulating an MPLS packet with an IP
tunnel header that is capable of encoding entropy (such as tunnel header that is capable of encoding entropy (such as
[RFC7510]), the corresponding entropy field (the source port in [RFC7510]), the corresponding entropy field (the source port in
case UDP tunnel) MAY be filled with an entropy value that is the case of a UDP tunnel) MAY be filled with an entropy value that
generated by the encapsulator to uniquely identify a flow. is generated by the encapsulator to uniquely identify a flow.
However, what constitutes a flow is locally determined by the However, what constitutes a flow is locally determined by the
encapsulator. For instance, if the MPLS label stack contains at encapsulator. For instance, if the MPLS label stack contains at
least one entropy label and the encapsulator is capable of reading least one entropy label and the encapsulator is capable of reading
that entropy label, the entropy label value could be directly that entropy label, the entropy label value could be directly
copied to the source port of the UDP header. Otherwise, the copied to the source port of the UDP header. Otherwise, the
encapsulator may have to perform a hash on the whole label stack encapsulator may have to perform a hash on the whole label stack
or the five-tuple of the SR-MPLS payload if the payload is or the five-tuple of the SR-MPLS payload if the payload is
determined as an IP packet. To avoid re-performing the hash or determined as an IP packet. To avoid re-performing the hash or
hunting for the entropy label each time the packet is encapsulated hunting for the entropy label each time the packet is encapsulated
in a UDP tunnel it MAY be desirable that the entropy value in a UDP tunnel it MAY be desirable that the entropy value
contained in the incoming packet (i.e., the UDP source port value) contained in the incoming packet (i.e., the UDP source port value)
is retained when stripping the UDP header and is re-used as the is retained when stripping the UDP header and is re-used as the
entropy value of the outgoing packet. entropy value of the outgoing packet.
Congestion Considerations: Section 5 of [RFC7510] provides a
detailed analysis of the implications of congestion in MPLS-over-
UDP systems and builds on section 3.1.3 of [RFC8085] that
describes the congestion implications of UDP tunnels. All of
those considerations apply to SR-MPLS-over-UDP tunnels as
described in this document. In particular, it should be noted
that the traffic carried in SR-MPLS flows is likely to be IP
traffic.
4. IANA Considerations 4. IANA Considerations
This document makes no requests for IANA action. This document makes no requests for IANA action.
5. Security Considerations 5. Security Considerations
The security consideration of [RFC8354] and [RFC7510] apply. DTLS The security consideration of [RFC8354] (which redirects the reader
[RFC6347] SHOULD be used where security is needed on an MPLS-SR-over- to [RFC5095]) and [RFC7510] apply. DTLS [RFC6347] SHOULD be used
UDP segment. where security is needed on an MPLS-SR-over-UDP segment including
when the IP segment crosses the public Internet or some other
untrusted environment.
It is difficult for an attacker to pass a raw MPLS encoded packet It is difficult for an attacker to pass a raw MPLS encoded packet
into a network and operators have considerable experience at into a network and operators have considerable experience at
excluding such packets at the network boundaries. excluding such packets at the network boundaries, for example by
excluding all MPLS packets that are revealed as payload of IP
tunnels. Further discussion of MPLS security is found in [RFC5920].
It is easy for an ingress node to detect any attempt to smuggle an IP It is easy for a network ingress node to detect any attempt to
packet into the network since it would see that the UDP destination smuggle an IP packet into the network since it would see that the UDP
port was set to MPLS. SR packets not having a destination address destination port was set to MPLS, and such filtering SHOULD be
terminating in the network would be transparently carried and would applied. SR packets not having a destination address terminating in
pose no security risk to the network under consideration. the network would be transparently carried and would pose no
different security risk to the network under consideration than any
other traffic.
Where control plane techniques are used (as described in Section 3), Where control plane techniques are used (as described in Section 3),
it is important that these protocols are adequately secured for the it is important that these protocols are adequately secured for the
environment in which they are run. environment in which they are run as discussed in [RFC6862] and
[RFC5920].
6. Contributors 6. Contributors
Ahmed Bashandy Ahmed Bashandy
Individual Individual
Email: abashandy.ietf@gmail.com Email: abashandy.ietf@gmail.com
Clarence Filsfils Clarence Filsfils
Cisco Cisco
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
skipping to change at page 13, line 36 skipping to change at page 14, line 5
Jeff Tantsura Jeff Tantsura
Individual Individual
Email: jefftant@gmail.com Email: jefftant@gmail.com
7. Acknowledgements 7. Acknowledgements
Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica, Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica,
Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert
Sparks, and Al Morton for their insightful comments on this draft. Sparks, and Al Morton for their insightful comments on this draft.
Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer
Dawkins, Benjamin Kaduk, and Martin Vigoureux for careful reviews and
resulting comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-18 data plane", draft-ietf-spring-segment-routing-mpls-19
(work in progress), December 2018. (work in progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/info/rfc5095>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
skipping to change at page 15, line 8 skipping to change at page 15, line 34
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in (SRH)", draft-ietf-6man-segment-routing-header-18 (work in
progress), February 2019. progress), April 2019.
[I-D.ietf-isis-encapsulation-cap] [I-D.ietf-isis-encapsulation-cap]
Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras,
L., and L. Jalil, "Advertising Tunnelling Capability in L., and L. Jalil, "Advertising Tunnelling Capability in
IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in
progress), April 2017. progress), April 2017.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", draft-ietf-isis-segment-routing- Segment Routing", draft-ietf-isis-segment-routing-
extensions-22 (work in progress), December 2018. extensions-23 (work in progress), March 2019.
[I-D.ietf-mpls-spring-entropy-label] [I-D.ietf-mpls-spring-entropy-label]
Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Kini, S., Kompella, K., Sivabalan, S., Litkowski, S.,
Shakir, R., and J. Tantsura, "Entropy label for SPRING Shakir, R., and J. Tantsura, "Entropy label for SPRING
tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in
progress), July 2018. progress), July 2018.
[I-D.ietf-ospf-encapsulation-cap] [I-D.ietf-ospf-encapsulation-cap]
Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L.
Jalil, "The Tunnel Encapsulations OSPF Router Jalil, "The Tunnel Encapsulations OSPF Router
Information", draft-ietf-ospf-encapsulation-cap-09 (work Information", draft-ietf-ospf-encapsulation-cap-09 (work
in progress), October 2017. in progress), October 2017.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-27 (work in progress), December 2018. routing-extensions-27 (work in progress), December 2018.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000,
<https://www.rfc-editor.org/info/rfc2983>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
<https://www.rfc-editor.org/info/rfc4023>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
Authentication for Routing Protocols (KARP) Overview,
Threats, and Requirements", RFC 6862,
DOI 10.17487/RFC6862, March 2013,
<https://www.rfc-editor.org/info/rfc6862>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", RFC 8085, DOI 10.17487/RFC8085, March 2017,
<https://www.rfc-editor.org/info/rfc8085>.
[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,
Ed., and M. Townsley, "Use Cases for IPv6 Source Packet Ed., and M. Townsley, "Use Cases for IPv6 Source Packet
Routing in Networking (SPRING)", RFC 8354, Routing in Networking (SPRING)", RFC 8354,
DOI 10.17487/RFC8354, March 2018, DOI 10.17487/RFC8354, March 2018,
<https://www.rfc-editor.org/info/rfc8354>. <https://www.rfc-editor.org/info/rfc8354>.
Authors' Addresses Authors' Addresses
Xiaohu Xu Xiaohu Xu
Alibaba, Inc Alibaba, Inc
 End of changes. 31 change blocks. 
63 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/