idnits 2.17.1 draft-ietf-mpls-sr-over-ip-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 13, 2019) is 1812 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-19 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-18 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-23 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Alibaba, Inc 4 Intended status: Standards Track S. Bryant 5 Expires: October 15, 2019 Huawei 6 A. Farrel 7 Old Dog Consulting 8 S. Hassan 9 Cisco 10 W. Henderickx 11 Nokia 12 Z. Li 13 Huawei 14 April 13, 2019 16 SR-MPLS over IP 17 draft-ietf-mpls-sr-over-ip-04 19 Abstract 21 MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source 22 routing paradigm in which the sender of a packet is allowed to 23 partially or completely specify the route the packet takes through 24 the network by imposing stacked MPLS labels on the packet. SR-MPLS 25 can be leveraged to realize a source routing mechanism across MPLS, 26 IPv4, and IPv6 data planes by using an MPLS label stack as a source 27 routing instruction set while making no changes to SR-MPLS 28 specifications and interworking with SR-MPLS implementations. 30 This document describes how SR-MPLS capable routers and IP-only 31 routers can seamlessly co-exist and interoperate through the use of 32 SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- 33 UDP as defined in RFC 7510. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on October 15, 2019. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Procedures of SR-MPLS over IP . . . . . . . . . . . . . . . . 5 72 3.1. Forwarding Entry Construction . . . . . . . . . . . . . . 5 73 3.2. Packet Forwarding Procedures . . . . . . . . . . . . . . 7 74 3.2.1. Packet Forwarding with Penultimate Hop Popping . . . 8 75 3.2.2. Packet Forwarding without Penultimate Hop Popping . . 9 76 3.2.3. Additional Forwarding Procedures . . . . . . . . . . 10 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 8.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 MPLS Segment Routing (SR-MPLS) [I-D.ietf-spring-segment-routing-mpls] 89 is an MPLS data plane-based source routing paradigm in which the 90 sender of a packet is allowed to partially or completely specify the 91 route the packet takes through the network by imposing stacked MPLS 92 labels on the packet. SR-MPLS uses an MPLS label stack to encode a 93 source routing instruction set. This can be used to realize a source 94 routing mechanism that can operate across MPLS, IPv4, and IPv6 data 95 planes. This approach preserves makes no changes to SR-MPLS 96 specifications and allows interworking with SR-MPLS implementations. 98 More specifically, the source routing instruction set information 99 contained in a source routed packet could be uniformly encoded as an 100 MPLS label stack no matter whether the underlay is IPv4, IPv6, or 101 MPLS. 103 This document describes how SR-MPLS capable routers and IP-only 104 routers can seamlessly co-exist and interoperate through the use of 105 SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in- 106 UDP [RFC7510]. 108 Section 2 describes various use cases for the tunneling SR-MPLS over 109 IP. Section 3 describes a typical application scenario and how the 110 packet forwarding happens. 112 1.1. Terminology 114 This memo makes use of the terms defined in [RFC3031] and 115 [I-D.ietf-spring-segment-routing-mpls]. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 2. Use Cases 125 Tunneling SR-MPLS using IPv4 and/or IPv6 tunnels is useful at least 126 in the following use cases: 128 o Incremental deployment of the SR-MPLS technology may be 129 facilitated by tunneling SR-MPLS packets across parts of a network 130 that are not SR-MPLS enabled using an IP tunneling mechanism such 131 as MPLS-in-UDP [RFC7510]. The tunnel selected MUST have its 132 remote end point (destination) address equal to the address of the 133 next SR-MPLS capable node along the path (i.e., the egress of the 134 active node segment). This is shown in Figure 1. 136 ________________________ 137 _______ ( ) _______ 138 ( ) ( IP Network ) ( ) 139 ( SR-MPLS ) ( ) ( SR-MPLS ) 140 ( Network ) ( ) ( Network ) 141 ( -------- -------- ) 142 ( | Border | SR-in-UDP Tunnel | Border | ) 143 ( | Router |========================| Router | ) 144 ( | R1 | | R2 | ) 145 ( -------- -------- ) 146 ( ) ( ) ( ) 147 ( ) ( ) ( ) 148 (_______) ( ) (_______) 149 (________________________) 151 Figure 1: SR-MPLS in UDP to Tunnel Between SR-MPLS Sites 153 o If encoding of entropy ([RFC6790] is desired, IP tunneling 154 mechanisms that allow encoding of entropy, such as MPLS-in-UDP 155 encapsulation [RFC7510] where the source port of the UDP header is 156 used as an entropy field, may be used to maximize the utilization 157 of ECMP and/or LAG, especially when it is difficult to make use of 158 the entropy label mechanism. This is to be contrasted with 159 [RFC4023] where MPLS-in-IP does not provide for an entropy 160 mechanism. Refer to [I-D.ietf-mpls-spring-entropy-label]) for 161 more discussion about using entropy labels in SR-MPLS. 163 o Tunneling MPLS into IP provides a technology that enables SR in an 164 IPv4 and/or IPv6 network where the routers do not support SRv6 165 capabilities [I-D.ietf-6man-segment-routing-header] and where MPLS 166 forwarding is not an option. This is shown in Figure 2. 168 __________________________________ 169 __( IP Network )__ 170 __( )__ 171 ( -- -- -- ) 172 -------- -- -- |SR| -- |SR| -- |SR| -- -------- 173 | Ingress| |IR| |IR| | | |IR| | | |IR| | | |IR| | Egress | 174 --->| Router |===========| |======| |======| |======| Router |---> 175 | SR | | | | | | | | | | | | | | | | | | SR | 176 -------- -- -- | | -- | | -- | | -- -------- 177 (__ -- -- -- __) 178 (__ __) 179 (__________________________________) 181 Key: 182 IR : IP-only Router 183 SR : SR-MPLS-capable Router 184 == : SR-MPLS in UDP Tunnel 186 Figure 2: SR-MPLS Enabled Within an IP Network 188 3. Procedures of SR-MPLS over IP 190 This section describes the construction of forwarding information 191 base (FIB) entries and the forwarding behavior that allow the 192 deployment of SR-MPLS when some routers in the network are IP only 193 (i.e., do not support SR-MPLS). Note that the examples in 194 Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in 195 fact, other mechanisms of discovery and advertisement could be used 196 including other routing protocols (such as BGP) or a central 197 controller. 199 3.1. Forwarding Entry Construction 201 This sub-section describes the how to construct the forwarding 202 information base (FIB) entry on an SR-MPLS-capable router when some 203 or all of the next-hops along the shortest path towards a prefix 204 Segment Identifier (prefix-SID) are IP-only routers. 206 Consider router A that receives a labeled packet with top label L(E) 207 that corresponds to the prefix-SID SID(E) of prefix P(E) advertised 208 by router E. Suppose the i-th next-hop router (termed NHi) along the 209 shortest path from router A toward SID(E) is not SR-MPLS capable 210 while both routers A and E are SR-MPLS capable. The following 211 processing steps apply: 213 o Router E is SR-MPLS capable, so it advertises a Segment Routing 214 Global Block (SRGB) using the mechanisms described in 215 [I-D.ietf-ospf-segment-routing-extensions] and 216 [I-D.ietf-isis-segment-routing-extensions]. The SRGB is defined 217 in [RFC8402]. 219 o When Router E advertises the prefix-SID SID(E) of prefix P(E) it 220 MUST also advertise the encapsulation endpoint and the tunnel type 221 of any tunnel used to reach E. It can do this using the 222 mechanisms described in [I-D.ietf-isis-encapsulation-cap] or 223 [I-D.ietf-ospf-encapsulation-cap]. 225 o If A and E are in different IGP areas/levels, then: 227 * The OSPF Tunnel Encapsulation TLV 228 [I-D.ietf-ospf-encapsulation-cap] or the ISIS Tunnel 229 Encapsulation sub-TLV [I-D.ietf-isis-encapsulation-cap] is 230 flooded domain-wide. 232 * The OSPF SID/label range TLV 233 [I-D.ietf-ospf-segment-routing-extensions] or the ISIS SR- 234 Capabilities Sub-TLV [I-D.ietf-isis-segment-routing-extensions] 235 is advertised domain-wide. This way router A knows the 236 characteristics of the router that originated the advertisement 237 of SID(E) (i.e., router E). 239 * When router E advertises the prefix P(E): 241 + If router E is running ISIS it uses the extended 242 reachability TLV (TLVs 135, 235, 236, 237) and associates 243 the IPv4/IPv6 or IPv4/IPv6 source router ID sub-TLV(s) 244 [RFC7794]. 246 + If router E is running OSPF it uses the OSPFv2 Extended 247 Prefix Opaque LSA [RFC7684] and sets the flooding scope to 248 AS-wide. 250 * If router E is running ISIS and advertises the ISIS capability 251 TLV (TLV 242) [RFC7981], it MUST set the "router-ID" field to a 252 valid value or include an IPV6 TE router-ID sub-TLV (TLV 12), 253 or do both. The "S" bit (flooding scope) of the ISIS 254 capability TLV (TLV 242) MUST be set to "1" . 256 o Router A programs the FIB entry for prefix P(E) corresponding to 257 the SID(E) as follows: 259 * If the NP flag in OSPF or the P flag in ISIS is clear: 261 pop the top label 263 * If the NP flag in OSPF or the P flag in ISIS is set: 265 swap the top label to a value equal to SID(E) plus the lower 266 bound of the SRGB of E 268 Once constructed, the FIB can be used by a router to tell it how to 269 process packets. It encapsulates the packets according to the 270 appropriate encapsulation (for example, as advertised using the 271 mechanisms described in [I-D.ietf-isis-encapsulation-cap] or 272 [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards 273 the next hop NHi. 275 3.2. Packet Forwarding Procedures 277 [RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- 278 in-UDP. This approach is applicable where IP-based encapsulation for 279 MPLS is required and further fine-grained load balancing of MPLS 280 packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link 281 Aggregation Groups (LAGs) is also required. This section provides 282 details about the forwarding procedure when UDP encapsulation is 283 adopted for SR-MPLS over IP. Other encapsulation and tunnelling 284 mechanisms can be applied using similar techniques, but for clarity 285 this section uses UDP encapsulation as the exemplar. 287 Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all 288 of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes 289 may be "legacy routers" that cannot handle SR-MPLS packets but can 290 forward IP packets. An SR-MPLS-capable node MAY advertise its 291 capabilities using the IGP as described in Section 3. There are six 292 types of node in an SR-MPLS domain: 294 o Domain ingress nodes that receive packets and encapsulate them for 295 transmission across the domain. Those packets may be any payload 296 protocol including native IP packets or packets that are already 297 MPLS encapsulated. 299 o Legacy transit nodes that are IP routers but that are not SR-MPLS 300 capable (i.e., are not able to perform segment routing). 302 o Transit nodes that are SR-MPLS capable but that are not identified 303 by a SID in the SID stack. 305 o Transit nodes that are SR-MPLS capable and need to perform SR-MPLS 306 routing because they are identified by a SID in the SID stack. 308 o The penultimate SR-MPLS capable node on the path that processes 309 the last SID on the stack on behalf of the domain egress node. 311 o The domain egress node that forwards the payload packet for 312 ultimate delivery. 314 3.2.1. Packet Forwarding with Penultimate Hop Popping 316 The description in this section assumes that the label associated 317 with each prefix-SID is advertised by the owner of the prefix-SID is 318 a Penultimate Hop Popping (PHP) label. That is, the NP flag in OSPF 319 or the P flag in ISIS associated with the prefix SID is not set. 321 +-----+ +-----+ +-----+ +-----+ +-----+ 322 | A +-------+ B +-------+ C +-------+ D +-------+ H | 323 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 324 | | | 325 | | | 326 +--+--+ +--+--+ +--+--+ 327 | E +-------+ F +-------+ G | 328 +-----+ +-----+ +-----+ 330 +--------+ 331 |IP(A->E)| 332 +--------+ +--------+ +--------+ 333 | UDP | |IP(E->G)| |IP(G->H)| 334 +--------+ +--------+ +--------+ 335 | L(G) | | UDP | | UDP | 336 +--------+ +--------+ +--------+ 337 | L(H) | | L(H) | |Exp Null| 338 +--------+ +--------+ +--------+ 339 | Packet | ---> | Packet | ---> | Packet | 340 +--------+ +--------+ +--------+ 342 Figure 3: Packet Forwarding Example with PHP 344 In the example shown in Figure 3, assume that routers A, E, G and H 345 are SR-MPLS-capable while the remaining routers (B, C, D and F) are 346 only capable of forwarding IP packets. Routers A, E, G, and H 347 advertise their Segment Routing related information, such as via IS- 348 IS or OSPF. 350 Now assume that router A (the Domain ingress) wants to send a packet 351 to router H (the Domain egress) via the explicit path {E->G->H}. 352 Router A will impose an MPLS label stack on the packet that 353 corresponds to that explicit path. Since the next hop toward router 354 E is only IP-capable (B is a legacy transit node), router A replaces 355 the top label (that indicated router E) with a UDP-based tunnel for 356 MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E and then sends the 357 packet. In other words, router A pops the top label and then 358 encapsulates the MPLS packet in a UDP tunnel to router E. 360 When the IP-encapsulated MPLS packet arrives at router E (which is an 361 SR-MPLS-capable transit node), router E strips the IP-based tunnel 362 header and then processes the decapsulated MPLS packet. The top 363 label indicates that the packet must be forwarded toward router G. 364 Since the next hop toward router G is only IP-capable, router E 365 replaces the current top label with an MPLS-over-UDP tunnel toward 366 router G and sends it out. That is, router E pops the top label and 367 then encapsulates the MPLS packet in a UDP tunnel to router G. 369 When the packet arrives at router G, router G will strip the IP-based 370 tunnel header and then process the decapsulated MPLS packet. The top 371 label indicates that the packet must be forwarded toward router H. 372 Since the next hop toward router H is only IP-capable (D is a legacy 373 transit router), router G would replace the current top label with an 374 MPLS-over-UDP tunnel toward router H and send it out. However, since 375 router G reaches the bottom of the label stack (G is the penultimate 376 SR-MPLS capable node on the path) this would leave the original 377 packet that router A wanted to send to router H encapsulated in UDP 378 as if it was MPLS (i.e., with a UDP header and destination port 379 indicating MPLS) even though the original packet could have been any 380 protocol. That is, the final SR-MPLS has been popped exposing the 381 payload packet. 383 To handle this, when a router (here it is router G) pops the final 384 SR-MPLS label, it inserts an explicit null label [RFC3032] before 385 encapsulating the packet in an MPLS-over-UDP tunnel toward router H 386 and sending it out. That is, router G pops the top label, discovers 387 it has reached the bottom of stack, pushes an explicit null label, 388 and then encapsulates the MPLS packet in a UDP tunnel to router H. 390 3.2.2. Packet Forwarding without Penultimate Hop Popping 392 Figure 4 demonstrates the packet walk in the case where the label 393 associated with each prefix-SID advertised by the owner of the 394 prefix-SID is not a Penultimate Hop Popping (PHP) label (i.e., the 395 the NP flag in OSPF or the P flag in ISIS associated with the prefix 396 SID is set). Apart from the PHP function the roles of the routers is 397 unchanged from Section 3.2.1. 399 +-----+ +-----+ +-----+ +-----+ +-----+ 400 | A +-------+ B +-------+ C +--------+ D +--------+ H | 401 +-----+ +--+--+ +--+--+ +--+--+ +-----+ 402 | | | 403 | | | 404 +--+--+ +--+--+ +--+--+ 405 | E +-------+ F +--------+ G | 406 +-----+ +-----+ +-----+ 408 +--------+ 409 |IP(A->E)| 410 +--------+ +--------+ 411 | UDP | |IP(E->G)| 412 +--------+ +--------+ +--------+ 413 | L(E) | | UDP | |IP(G->H)| 414 +--------+ +--------+ +--------+ 415 | L(G) | | L(G) | | UDP | 416 +--------+ +--------+ +--------+ 417 | L(H) | | L(H) | | L(H) | 418 +--------+ +--------+ +--------+ 419 | Packet | ---> | Packet | ---> | Packet | 420 +--------+ +--------+ +--------+ 422 Figure 4: Packet Forwarding Example without PHP 424 As can be seen from the figure, the SR-MPLS label for each segment is 425 left in place until the end of the segment where it is popped and the 426 next instruction is processed. 428 3.2.3. Additional Forwarding Procedures 430 Non-MPLS Interfaces: Although the description in the previous two 431 sections is based on the use of prefix-SIDs, tunneling SR-MPLS 432 packets is useful when the top label of a received SR-MPLS packet 433 indicates an adjacency-SID and the corresponding adjacent node to 434 that adjacency-SID is not capable of MPLS forwarding but can still 435 process SR-MPLS packets. In this scenario the top label would be 436 replaced by an IP tunnel toward that adjacent node and then 437 forwarded over the corresponding link indicated by the adjacency- 438 SID. 440 When to use IP-based Tunnel: The description in the previous two 441 sections is based on the assumption that MPLS-over-UDP tunnel is 442 used when the nexthop towards the next segment is not MPLS- 443 enabled. However, even in the case where the nexthop towards the 444 next segment is MPLS-capable, an MPLS-over-UDP tunnel towards the 445 next segment could still be used instead due to local policies. 446 For instance, in the example as described in Figure 4, assume F is 447 now an SR-MPLS-capable transit node while all the other 448 assumptions remain unchanged: since F is not identified by a SID 449 in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS 450 LSP according to local policies, router E replaces the current top 451 label with an MPLS-over-UDP tunnel toward router G and send it 452 out. (Note that if an MPLS LSP was preferred, the packet would be 453 forwarded as native SR-MPLS.) 455 IP Header Fields: When encapsulating an MPLS packet in UDP, the 456 resulting packet is further encapsulated in IP for transmission. 457 IPv4 or IPv6 may be used according to the capabilities of the 458 network. The address fields are set as described in Section 2. 459 The other IP header fields (such as the ECN field [RFC6040], the 460 DSCP code point [RFC2983], or IPv6 Flow Label) on each UDP- 461 encapsulated segment SHOULD be configurable according to the 462 operator's policy: they may be copied from the header of the 463 incoming packet; they may be promoted from the header of the 464 payload packet; they may be set according to instructions 465 programmed to be associated with the SID; or they may be 466 configured dependent on the outgoing interface and payload. 468 Entropy and ECMP: When encapsulating an MPLS packet with an IP 469 tunnel header that is capable of encoding entropy (such as 470 [RFC7510]), the corresponding entropy field (the source port in 471 the case of a UDP tunnel) MAY be filled with an entropy value that 472 is generated by the encapsulator to uniquely identify a flow. 473 However, what constitutes a flow is locally determined by the 474 encapsulator. For instance, if the MPLS label stack contains at 475 least one entropy label and the encapsulator is capable of reading 476 that entropy label, the entropy label value could be directly 477 copied to the source port of the UDP header. Otherwise, the 478 encapsulator may have to perform a hash on the whole label stack 479 or the five-tuple of the SR-MPLS payload if the payload is 480 determined as an IP packet. To avoid re-performing the hash or 481 hunting for the entropy label each time the packet is encapsulated 482 in a UDP tunnel it MAY be desirable that the entropy value 483 contained in the incoming packet (i.e., the UDP source port value) 484 is retained when stripping the UDP header and is re-used as the 485 entropy value of the outgoing packet. 487 Congestion Considerations: Section 5 of [RFC7510] provides a 488 detailed analysis of the implications of congestion in MPLS-over- 489 UDP systems and builds on section 3.1.3 of [RFC8085] that 490 describes the congestion implications of UDP tunnels. All of 491 those considerations apply to SR-MPLS-over-UDP tunnels as 492 described in this document. In particular, it should be noted 493 that the traffic carried in SR-MPLS flows is likely to be IP 494 traffic. 496 4. IANA Considerations 498 This document makes no requests for IANA action. 500 5. Security Considerations 502 The security consideration of [RFC8354] (which redirects the reader 503 to [RFC5095]) and [RFC7510] apply. DTLS [RFC6347] SHOULD be used 504 where security is needed on an MPLS-SR-over-UDP segment including 505 when the IP segment crosses the public Internet or some other 506 untrusted environment. 508 It is difficult for an attacker to pass a raw MPLS encoded packet 509 into a network and operators have considerable experience at 510 excluding such packets at the network boundaries, for example by 511 excluding all MPLS packets that are revealed as payload of IP 512 tunnels. Further discussion of MPLS security is found in [RFC5920]. 514 It is easy for a network ingress node to detect any attempt to 515 smuggle an IP packet into the network since it would see that the UDP 516 destination port was set to MPLS, and such filtering SHOULD be 517 applied. SR packets not having a destination address terminating in 518 the network would be transparently carried and would pose no 519 different security risk to the network under consideration than any 520 other traffic. 522 Where control plane techniques are used (as described in Section 3), 523 it is important that these protocols are adequately secured for the 524 environment in which they are run as discussed in [RFC6862] and 525 [RFC5920]. 527 6. Contributors 529 Ahmed Bashandy 530 Individual 531 Email: abashandy.ietf@gmail.com 533 Clarence Filsfils 534 Cisco 535 Email: cfilsfil@cisco.com 537 John Drake 538 Juniper 539 Email: jdrake@juniper.net 540 Shaowen Ma 541 Juniper 542 Email: mashao@juniper.net 544 Mach Chen 545 Huawei 546 Email: mach.chen@huawei.com 548 Hamid Assarpour 549 Broadcom 550 Email:hamid.assarpour@broadcom.com 552 Robert Raszuk 553 Bloomberg LP 554 Email: robert@raszuk.net 556 Uma Chunduri 557 Huawei 558 Email: uma.chunduri@gmail.com 560 Luis M. Contreras 561 Telefonica I+D 562 Email: luismiguel.contrerasmurillo@telefonica.com 564 Luay Jalil 565 Verizon 566 Email: luay.jalil@verizon.com 568 Gunter Van De Velde 569 Nokia 570 Email: gunter.van_de_velde@nokia.com 572 Tal Mizrahi 573 Marvell 574 Email: talmi@marvell.com 576 Jeff Tantsura 577 Individual 578 Email: jefftant@gmail.com 580 7. Acknowledgements 582 Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica, 583 Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert 584 Sparks, and Al Morton for their insightful comments on this draft. 586 Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer 587 Dawkins, Benjamin Kaduk, and Martin Vigoureux for careful reviews and 588 resulting comments. 590 8. References 592 8.1. Normative References 594 [I-D.ietf-spring-segment-routing-mpls] 595 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 596 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 597 data plane", draft-ietf-spring-segment-routing-mpls-19 598 (work in progress), March 2019. 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, 602 DOI 10.17487/RFC2119, March 1997, 603 . 605 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 606 Label Switching Architecture", RFC 3031, 607 DOI 10.17487/RFC3031, January 2001, 608 . 610 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 611 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 612 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 613 . 615 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 616 of Type 0 Routing Headers in IPv6", RFC 5095, 617 DOI 10.17487/RFC5095, December 2007, 618 . 620 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 621 Notification", RFC 6040, DOI 10.17487/RFC6040, November 622 2010, . 624 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 625 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 626 January 2012, . 628 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 629 "Encapsulating MPLS in UDP", RFC 7510, 630 DOI 10.17487/RFC7510, April 2015, 631 . 633 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 634 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 635 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 636 2015, . 638 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 639 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 640 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 641 March 2016, . 643 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 644 for Advertising Router Information", RFC 7981, 645 DOI 10.17487/RFC7981, October 2016, 646 . 648 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 649 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 650 May 2017, . 652 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 653 Decraene, B., Litkowski, S., and R. Shakir, "Segment 654 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 655 July 2018, . 657 8.2. Informative References 659 [I-D.ietf-6man-segment-routing-header] 660 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 661 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 662 (SRH)", draft-ietf-6man-segment-routing-header-18 (work in 663 progress), April 2019. 665 [I-D.ietf-isis-encapsulation-cap] 666 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 667 L., and L. Jalil, "Advertising Tunnelling Capability in 668 IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in 669 progress), April 2017. 671 [I-D.ietf-isis-segment-routing-extensions] 672 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 673 Gredler, H., and B. Decraene, "IS-IS Extensions for 674 Segment Routing", draft-ietf-isis-segment-routing- 675 extensions-23 (work in progress), March 2019. 677 [I-D.ietf-mpls-spring-entropy-label] 678 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 679 Shakir, R., and J. Tantsura, "Entropy label for SPRING 680 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 681 progress), July 2018. 683 [I-D.ietf-ospf-encapsulation-cap] 684 Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. 685 Jalil, "The Tunnel Encapsulations OSPF Router 686 Information", draft-ietf-ospf-encapsulation-cap-09 (work 687 in progress), October 2017. 689 [I-D.ietf-ospf-segment-routing-extensions] 690 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 691 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 692 Extensions for Segment Routing", draft-ietf-ospf-segment- 693 routing-extensions-27 (work in progress), December 2018. 695 [RFC2983] Black, D., "Differentiated Services and Tunnels", 696 RFC 2983, DOI 10.17487/RFC2983, October 2000, 697 . 699 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 700 "Encapsulating MPLS in IP or Generic Routing Encapsulation 701 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 702 . 704 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 705 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 706 . 708 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 709 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 710 RFC 6790, DOI 10.17487/RFC6790, November 2012, 711 . 713 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 714 Authentication for Routing Protocols (KARP) Overview, 715 Threats, and Requirements", RFC 6862, 716 DOI 10.17487/RFC6862, March 2013, 717 . 719 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 720 Guidelines", RFC 8085, DOI 10.17487/RFC8085, March 2017, 721 . 723 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 724 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 725 Routing in Networking (SPRING)", RFC 8354, 726 DOI 10.17487/RFC8354, March 2018, 727 . 729 Authors' Addresses 731 Xiaohu Xu 732 Alibaba, Inc 734 Email: xiaohu.xxh@alibaba-inc.com 736 Stewart Bryant 737 Huawei 739 Email: stewart.bryant@gmail.com 741 Adrian Farrel 742 Old Dog Consulting 744 Email: adrian@olddog.co.uk 746 Syed Hassan 747 Cisco 749 Email: shassan@cisco.com 751 Wim Henderickx 752 Nokia 754 Email: wim.henderickx@nokia.com 756 Zhenbin Li 757 Huawei 759 Email: lizhenbin@huawei.com