idnits 2.17.1 draft-ietf-mpls-in-udp-08.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 121 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 10, 2014) is 3396 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5405 (Obsoleted by RFC 8085) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track N. Sheth 5 Expires: June 13, 2015 Juniper Networks 6 L. Yong 7 Huawei USA 8 R. Callon 9 Juniper Networks 10 D. Black 11 EMC Corporation 12 December 10, 2014 14 Encapsulating MPLS in UDP 15 draft-ietf-mpls-in-udp-08 17 Abstract 19 This document specifies an IP-based encapsulation for MPLS, called 20 MPLS-in-UDP (User Datagram Protocol). The MPLS-in-UDP encapsulation 21 technology MUST only be deployed within a service provider network or 22 networks of an adjacent set of co-operating service providers where 23 congestion control is not a concern. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 13, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Existing Encapsulations . . . . . . . . . . . . . . . . . 3 61 1.2. Motivations for MPLS-in-UDP Encapsulation . . . . . . . . 3 62 1.3. Application Statements . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 4 65 3.1. UDP Checksum Usage with IPv6 . . . . . . . . . . . . . . 6 66 3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 8 67 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9 68 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 10.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 This document specifies an IP-based encapsulation for MPLS, i.e. 81 MPLS-in-UDP (User Datagram Protocol), which is applicable in some 82 circumstances where IP-based encapsulation for MPLS is required and 83 further fine-grained load balancing of MPLS packets over IP networks 84 over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Groups 85 (LAG) is required as well. There are already IP-based encapsulations 86 for MPLS that allow for fine-grained load balancing by using some 87 special field in the encapsulation header as an entropy field. 88 However, MPLS-in-UDP can be advantageous since some networks have 89 used the UDP port number fields as a basis for load-balancing 90 solutions for some time. This is similar to why LISP [RFC6830] uses 91 UDP encapsulation. 93 Like other IP-based encapsulation methods for MPLS, this 94 encapsulation allows for two Label Switching Routers (LSR) to be 95 adjacent on a Label Switched Path (LSP), while separated by an IP 96 network. In order to support this encapsulation, each LSR needs to 97 know the capability to decapsulate MPLS-in-UDP by the remote LSRs. 98 This specification defines only the data plane encapsulation and does 99 not concern itself with how the knowledge to use this encapsulation 100 is conveyed. Specifically, this capability can be either manually 101 configured on each LSR or be dynamically advertised in manners that 102 are outside the scope of this document. 104 Similarly, the MPLS-in-UDP encapsulation format defined in this 105 document by itself cannot ensure the integrity and privacy of data 106 packets being transported through the MPLS-in-UDP tunnels and cannot 107 enable the tunnel decapsulators to authenticate the tunnel 108 encapsulator. Therefore, in the case where any of the above security 109 issues is concerned, the MPLS-in-UDP SHOULD be secured with IPsec 110 [RFC4301] or DTLS [RFC6347]. For more details, please see Section 6 111 of Security Considerations. 113 1.1. Existing Encapsulations 115 Currently, there are several IP-based encapsulations for MPLS such as 116 MPLS-in-IP, MPLS-in-GRE (Generic Routing Encapsulation) [RFC4023], 117 and MPLS-in-L2TPv3 (Layer Two Tunneling Protocol - Version 3) 118 [RFC4817]. In all these methods, the IP addresses can be varied to 119 achieve load-balancing. 121 All these IP-based encapsulations for MPLS are specified for both 122 IPv4 and IPv6. In the case of IPv6-based encapsulations, the IPv6 123 Flow Label can be used for ECMP and LAGs [RFC6438]. However, there 124 is no such entropy field in the IPv4 header. 126 For MPLS-in-GRE as well as MPLS-in-L2TPv3, protocol fields (the GRE 127 Key and the L2TPv3 Session ID respectively) can be used as the load- 128 balancing key as described in [RFC5640]. For this, intermediate 129 routers need to understand these fields in the context of being used 130 as load-balancing keys. 132 1.2. Motivations for MPLS-in-UDP Encapsulation 134 Most existing routers in IP networks are already capable of 135 distributing IP traffic "microflows" [RFC2474] over ECMPs and/or LAG 136 based on the hash of the five-tuple of User Datagram Protocol (UDP) 137 [RFC0768] and Transmission Control Protocol (TCP) packets (i.e., 138 source IP address, destination IP address, source port, destination 139 port, and protocol). By encapsulating the MPLS packets into an UDP 140 tunnel and using the source port of the UDP header as an entropy 141 field, the existing load-balancing capability as mentioned above can 142 be leveraged to provide fine-grained load-balancing of MPLS traffic 143 over IP networks. 145 1.3. Application Statements 147 The MPLS-in-UDP encapsulation technology MUST only be deployed within 148 a Service Provider (SP) network or networks of an adjacent set of co- 149 operating SPs where congestion control is not a concern, rather than 150 over the Internet where congestion control is required. Furthermore, 151 packet filters SHOULD be added to prevent MPLS-in-UDP packets from 152 escaping from the service provider networks due to misconfiguation or 153 packet errors. 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 3. Encapsulation in UDP 163 MPLS-in-UDP encapsulation format is shown as follows: 165 0 1 2 3 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Source Port = Entropy | Dest Port = MPLS | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | UDP Length | UDP Checksum | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | | 173 ~ MPLS Label Stack ~ 174 | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 176 ~ Message Body ~ 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Source Port of UDP 182 This field contains a 16-bit entropy value that is generated by 183 the encapsulator to uniquely identify a flow. What constitutes 184 a flow is locally determined by the encapsulator and therefore 185 is outside the scope of this document. What algorithm is 186 actually used by the encapsulator to generate an entropy value 187 is outside the scope of this document. 189 In case the tunnel does not need entropy, this field of all 190 packets belonging to a given flow SHOULD be set to a randomly 191 selected constant value so as to avoid packet reordering. 193 To ensure that the source port number is always in the range 194 49152 to 65535 (Note that those ports less than 49152 are 195 reserved by IANA to identify specific applications/protocols) 196 which may be required in some cases, instead of calculating a 197 16-bit hash, the encapsulator SHOULD calculate a 14-bit hash 198 and use those 14 bits as the least significant bits of the 199 source port field while the most significant two bits SHOULD be 200 set to binary 11. That still conveys 14 bits of entropy 201 information which would be enough as well in practice. 203 Destination Port of UDP 205 This field is set to a value (TBD1) allocated by IANA to 206 indicate that the UDP tunnel payload is an MPLS packet. 208 UDP Length 210 The usage of this field is in accordance with the current UDP 211 specification [RFC0768]. 213 UDP Checksum 215 For IPv4 UDP encapsulation, this field is RECOMMENDED to be set 216 to zero because the IPv4 header includes a checksum and use of 217 the UDP checksum is optional with IPv4, unless checksum 218 protection of VPN labels is important (See Section 6). For 219 IPv6 UDP encapsulation, the IPv6 header does not include a 220 checksum, so this field MUST contain a UDP checksum that MUST 221 be used as specified in [RFC0768] and [RFC2460] unless one of 222 the exceptions that allows use of UDP zero-checksum mode (as 223 specified in [RFC6935]) applies. See Section 3.1 for 224 specification of these exceptions and additional requirements 225 that apply when UDP zero-checksum mode is used for MPLS-in-UDP 226 traffic over IPv6. 228 MPLS Label Stack 230 This field contains an MPLS Label Stack as defined in 231 [RFC3032]. 233 Message Body 235 This field contains one MPLS message body. 237 3.1. UDP Checksum Usage with IPv6 239 When UDP is used over IPv6, the UDP checksum is relied upon to 240 protect the IPv6 header from corruption, and MUST be used unless the 241 requirements in [RFC6935] and [RFC6936] for use of UDP zero-checksum 242 mode with a tunnel protocol are satisfied. MPLS-in-UDP is a tunnel 243 protocol, and there is significant successful deployment of MPLS-in- 244 IPv6 without UDP (i.e., without a checksum that covers the IPv6 245 header or the MPLS label stack), as described in Section 3.1 of 246 [RFC6936]: 248 "There is extensive experience with deployments using tunnel 249 protocols in well-managed networks (e.g., corporate networks and 250 service provider core networks). This has shown the robustness of 251 methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS 252 that do not employ a transport protocol checksum and that have not 253 specified mechanisms to protect from corruption of the unprotected 254 headers(such as the VPN Identifier in MPLS)". 256 This draft focuses on service provider core networks. The 257 requirements in Section 5 for use of MPLS-in-UDP to carry traffic 258 that is not necessarily congestion controlled involve significant 259 service provider traffic management and engineering - this is a 260 hallmark of the well-managed networks that the above [RFC6936] text 261 refers to. Therefore, the UDP checksum MUST be implemented and MUST 262 be used in accordance with [RFC0768] and [RFC2460] for MPLS-in-UDP 263 traffic over IPv6 unless one of the following exceptions applies and 264 the additional requirements stated below are complied with. There 265 are two exceptions that allow use of UDP zero-checksum mode for IPv6 266 with MPLS-in-UDP, subject to the additional requirements stated below 267 in this section. The two exceptions are: 269 a. Use of MPLS-in-UDP within a single service provider that utilizes 270 careful provisioning (e.g., rate limiting at the entries of the 271 network while over-provisioning network capacity) to ensure 272 against congestion and that actively monitors MPLS traffic for 273 errors; or 275 b. Use of MPLS-in-UDP within a limited number of service providers 276 who closely cooperate in order to jointly provide this same 277 careful provisioning and monitoring. 279 Even when one of the above exceptions applies, use of UDP checksums 280 may be appropriate when VPN services are provided over MPLS-in-UDP, 281 see Section 6. As such, for IPv6, the UDP checksum for MPLS-in-UDP 282 MUST be used as specified in [RFC0768] and [RFC2460] over the general 283 Internet, and over non-cooperating SPs, even if each non-cooperating 284 SP independently satisfies the first exception for UDP zero-checksum 285 mode usage with MPLS-in-UDP over IPv6 within the SP's own network. 286 Measures SHOULD be taken to prevent UDP zero checksum mode MPLS-in- 287 UDP over IPv6 traffic from "escaping" to the general Internet; see 288 Section 5 for examples of such measures. 290 The following additional requirements apply to implementation and use 291 of UDP zero-checksum mode for MPLS-in-UDP over IPv6: 293 a. Use of the UDP checksum with IPv6 MUST be the default 294 configuration of all MPLS-in-UDP implementations. 296 b. An MPLS-in-UDP implementation MUST comply with all requirements 297 specified in Section 4 of [RFC6936] and with requirement 1 298 specified in Section 5 of [RFC6936]. 300 c. An MPLS-in-UDP receiver MUST check that the source and 301 destination IPv6 addresses are valid for the MPLS-in-UDP tunnel 302 and discard any packet for which this check fails. 304 d. An MPLS-in-UDP sender SHOULD use different IPv6 addresses for 305 each MPLS-in-UDP tunnel that uses UDP zero-checksum mode in order 306 to strengthen the receiver's check of the IPv6 source address. 307 When this is not possible, it is RECOMMENDED to use each source 308 IPv6 address for as few UDP zero-checksum mode MPLS-in-UDP 309 tunnels as is feasible. 311 e. An MPLS-in-UDP receiver MUST check that the top label of the MPLS 312 label stack is valid for the tunnel. This check will often be 313 part of the MPLS LSR forwarding logic, but MUST be scoped to the 314 specific tunnel. 316 f. An MPLS-in-UDP receiver node SHOULD only enable the use of UDP 317 zero-checksum mode on a single UDP port and SHOULD NOT support 318 any other use UDP zero-checksum mode on any other UDP port. 320 g. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode 321 for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of 322 [RFC6936]. 324 The above requirements do not change the requirements specified in 325 [RFC2460] as modified by [RFC6935] and the requirements specified in 326 [RFC6936]. 328 The requirements to check the source IPv6 address and top label of 329 the MPLS stack (in addition to the destination IPv6 address), plus 330 the strong recommendation against reuse of source IPv6 addresses 331 among MPLS-in-UDP tunnels collectively provide some offset for the 332 absence of UDP checksum coverage of the IPv6 header. The expected 333 result for IPv6 UDP zero-checksum mode for MPLS-in-UDP is that 334 corruption of the destination IPv6 address will usually cause packet 335 discard, as offsetting corruptions to the source IPv6 and/or MPLS top 336 label are unlikely. Additional assurance is provided by the 337 restrictions in the above exceptions that limit usage of IPv6 UDP 338 zero-checksum mode to specific types of well-managed networks for 339 which MPLS packet corruption has not been a problem in practice. 341 Hence MPLS-in-UDP is suitable for transmission over lower layers in 342 the well-managed networks that are allowed by the two exceptions 343 stated above and is not expected to increase the rate of corruption 344 of the inner IP packet on such networks by comparison to MPLS traffic 345 that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does 346 not provide an additional integrity check when UDP zero-checksum mode 347 is used with IPv6, and this design is in accordance with requirements 348 2, 3 and 5 specified in Section 5 of [RFC6936]. 350 MPLS does not accumulate incorrect state as a consequence of label 351 stack corruption. A corrupt MPLS label results in either packet 352 discard or forwarding (and forgetting) of the packet without 353 accumulation of MPLS protocol state. Active monitoring of MPLS-in- 354 UDP traffic for errors is REQUIRED as occurrence of errors will 355 result in some accumulation of error information outside the MPLS 356 protocol for operational and management purposes. This design is in 357 accordance with requirement 4 specified in Section 5 of [RFC6936]. 359 The remaining requirements specified in Section 5 of [RFC6936] are 360 inapplicable to MPLS-in-UDP. Requirements 6 and 7 do not apply 361 because MPLS does not have an MPLS-generic control feedback 362 mechanism. Requirements 8-10 are middlebox requirements that do not 363 apply to MPLS-in-UDP tunnel endpoints, but see Section 3.2 for 364 further middlebox discussion. 366 In summary, UDP zero-checksum mode for IPv6 is allowed to be used 367 with MPLS-in-UDP when one of the two exceptions specified above 368 applies, provided that the additional requirements specified above 369 are complied with. Otherwise the UDP checksum MUST be used for IPv6 370 as specified in [RFC0768] and [RFC2460]. 372 This entire section and its requirements apply only to use of UDP 373 zero-checksum mode for IPv6; they can be avoided by using the UDP 374 checksum as specified in [RFC0768] and [RFC2460]. 376 3.2. Middlebox Considerations for IPv6 UDP Zero Checksums 378 IPv6 datagrams with a zero UDP checksum will not be passed by any 379 middlebox that validates the checksum based on [RFC2460] or that 380 updates the UDP checksum field, such as NATs or firewalls. Changing 381 this behavior would require such middleboxes to be updated to 382 correctly handle datagrams with zero UDP checksums. The MPLS-in-UDP 383 encapsulation does not provide a mechanism to safely fall back to 384 using a checksum when a path change occurs redirecting a tunnel over 385 a path that includes a middlebox that discards IPv6 datagrams with a 386 zero UDP checksum. In this case the MPLS-in-UDP tunnel will be 387 black-holed by that middlebox. Recommended changes to allow 388 firewalls, NATs and other middleboxes to support use of an IPv6 zero 389 UDP checksum are described in Section 5 of [RFC6936]. 391 4. Processing Procedures 393 This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded 394 through "UDP tunnels". When performing MPLS-in-UDP encapsulation by 395 the encapsulator, the entropy value would be generated by the 396 encapsulator and then be filled in the Source Port field of the UDP 397 header. The Destination Port field is set to a value (TBD1) 398 allocated by IANA to indicate that the UDP tunnel payload is an MPLS 399 packet. As for whether the top label in the MPLS label stack is 400 downstream-assigned or upstream-assigned, it SHOULD be determined 401 based on the tunnel destination IP address. That is to say, if the 402 destination IP address is a multicast address, the top label SHOULD 403 be upstream-assigned, otherwise if the destination IP address is a 404 unicast address, it SHOULD be downstream-assigned. Intermediate 405 routers, upon receiving these UDP encapsulated packets, could balance 406 these packets based on the hash of the five-tuple of UDP packets. 407 Upon receiving these UDP encapsulated packets, the decapsulator would 408 decapsulate them by removing the UDP headers and then process them 409 accordingly. For other common processing procedures associated with 410 tunneling encapsulation technologies including but not limited to 411 Maximum Transmission Unit (MTU) and preventing fragmentation and 412 reassembly, Time to Live (TTL) and differentiated services, the 413 corresponding "Common Procedures" defined in [RFC4023] which are 414 applicable for MPLS-in-IP and MPLS-in-GRE encapsulation formats 415 SHOULD be followed. 417 5. Congestion Considerations 419 Section 3.1.3 of [RFC5405] discussed the congestion implications of 420 UDP tunnels. As discussed in [RFC5405], because other flows can 421 share the path with one or more UDP tunnels, congestion control 422 [RFC2914] needs to be considered. 424 A major motivation for encapsulating MPLS in UDP is to improve the 425 use of multipath (such as ECMP) in cases where traffic is to traverse 426 routers which are able to hash on UDP Port and IP address. As such, 427 in many cases this may reduce the occurrence of congestion and 428 improve usage of available network capacity. However, it is also 429 necessary to ensure that the network, including applications that use 430 the network, responds appropriately in more difficult cases, such as 431 when link or equipment failures have reduced the available capacity. 433 The impact of congestion must be considered both in terms of the 434 effect on the rest of the network of a UDP tunnel that is consuming 435 excessive capacity, and in terms of the effect on the flows using the 436 UDP tunnels. The potential impact of congestion from a UDP tunnel 437 depends upon what sort of traffic is carried over the tunnel, as well 438 as the path of the tunnel. 440 MPLS is widely used to carry a wide range of traffic. In many cases 441 MPLS is used to carry IP traffic. IP traffic is generally assumed to 442 be congestion controlled, and thus a tunnel carrying general IP 443 traffic (as might be expected to be carried across the Internet) 444 generally does not need additional congestion control mechanisms. As 445 specified in [RFC5405]: 447 "IP-based traffic is generally assumed to be congestion- 448 controlled, i.e., it is assumed that the transport protocols 449 generating IP-based traffic at the sender already employ 450 mechanisms that are sufficient to address congestion on the path. 451 Consequently, a tunnel carrying IP-based traffic should already 452 interact appropriately with other traffic sharing the path, and 453 specific congestion control mechanisms for the tunnel are not 454 necessary". 456 For this reason, where MPLS-in-UDP tunneling is used to carry IP 457 traffic that is known to be congestion controlled, the UDP tunnels 458 MAY be used across any combination of a single service provider, 459 multiple cooperating service providers, or across the general 460 Internet. Internet IP traffic is generally assumed to be congestion- 461 controlled. Similarly, in general Layer 3 VPNs are carrying IP 462 traffic that is similarly assumed to be congestion controlled. 464 Whether or not Layer 2 VPN traffic is congestion controlled may 465 depend upon the specific services being offered and what use is being 466 made of the layer 2 services. 468 However, MPLS is also used in many cases to carry traffic that is not 469 necessarily congestion controlled. For example, MPLS may be used to 470 carry pseudowire or VPN traffic where specific bandwidth guarantees 471 are provided to each pseudowire, or to each VPN. 473 In such cases service providers may avoid congestion by careful 474 provisioning of their networks, by rate limiting of user data 475 traffic, and/or by using MPLS Traffic Engineering (MPLS-TE) to assign 476 specific bandwidth guarantees to each LSP. Where MPLS is carried 477 over UDP over IP, the identity of each individual MPLS flow is in 478 general lost and MPLS-TE cannot be used to guarantee bandwidth to 479 specific flows (since many LSPs may be multiplexed over a single UDP 480 tunnel, and many UDP tunnels may be mixed in an IP network). 482 For this reason, where the MPLS traffic is not congestion controlled, 483 MPLS-in-UDP tunnels MUST only be used within a single service 484 provider that utilizes careful provisioning (e.g., rate limiting at 485 the entries of the network while over-provisioning network capacity) 486 to ensure against congestion, or within a limited number of service 487 providers who closely cooperate in order to jointly provide this same 488 careful provisioning. 490 As such, MPLS-in-UDP MUST NOT be used over the general Internet, or 491 over non-cooperating SPs, to carry traffic that is not congestion- 492 controlled. 494 Measures SHOULD be taken to prevent non-congestion-controlled MPLS- 495 in-UDP traffic from "escaping" to the general Internet, e.g.: 497 a. Physical or logical isolation of the links carrying MPLS-over-UDP 498 from the general Internet. 500 b. Deployment of packet filters that block the UDP ports assigned 501 for MPLS-over-UDP. 503 c. Imposition of restrictions on MPLS-in-UDP traffic by software 504 tools used to set up MPLS-in-UDP tunnels between specific end 505 systems (as might be used within a single data center). 507 d. Use of a "Managed Circuit Breaker" for the MPLS traffic as 508 described in [I-D.fairhurst-tsvwg-circuit-breaker]. 510 6. Security Considerations 512 The security problems faced with the MPLS-in-UDP tunnel are exactly 513 the same as those faced with MPLS-in-IP and MPLS-in-GRE tunnels 514 [RFC4023]. In other words, the MPLS-in-UDP tunnel as defined in this 515 document by itself cannot ensure the integrity and privacy of data 516 packets being transported through the MPLS-in-UDP tunnel and cannot 517 enable the tunnel decapsulator to authenticate the tunnel 518 encapsulator. In the case where any of the above security issues is 519 concerned, the MPLS-in-UDP tunnel SHOULD be secured with IPsec or 520 DTLS. IPsec was designed as a network security mechanism and 521 therefore it resides at the network layer. As such, if the tunnel is 522 secured with IPsec, the UDP header would not be visible to 523 intermediate routers anymore in either IPsec tunnel or transport 524 mode. As a result, the meaning of adopting the MPLS-in-UDP tunnel as 525 an alternative to the MPLS-in-GRE or MPLS-in-IP tunnel is lost. By 526 comparison, DTLS is better suited for application security and can 527 better preserve network and transport layer protocol information. 528 Specifically, if DTLS is used, the destination port of the UDP header 529 will be filled with a value (TBD2) indicating MPLS with DTLS and the 530 source port can still be used as an entropy field for load-sharing 531 purposes. 533 If the tunnel is not secured with IPsec or DTLS, some other method 534 should be used to ensure that packets are decapsulated and forwarded 535 by the tunnel tail only if those packets were encapsulated by the 536 tunnel head. If the tunnel lies entirely within a single 537 administrative domain, address filtering at the boundaries can be 538 used to ensure that no packet with the IP source address of a tunnel 539 endpoint or with the IP destination address of a tunnel endpoint can 540 enter the domain from outside. However, when the tunnel head and the 541 tunnel tail are not in the same administrative domain, this may 542 become difficult, and filtering based on the destination address can 543 even become impossible if the packets must traverse the public 544 Internet. Sometimes only source address filtering (but not 545 destination address filtering) is done at the boundaries of an 546 administrative domain. If this is the case, the filtering does not 547 provide effective protection at all unless the decapsulator of an 548 MPLS-in-UDP validates the IP source address of the packet. 550 This document does not require that the decapsulator validate the IP 551 source address of the tunneled packets (with the exception that the 552 IPv6 source address MUST be validated when UDP zero-checksum mode is 553 used with IPv6), but it should be understood that failure to do so 554 presupposes that there is effective destination-based (or a 555 combination of source-based and destination-based) filtering at the 556 boundaries. MPLS-based VPN services rely on a VPN label in the MPLS 557 label stack to identify the VPN. Corruption of that label could leak 558 traffic across VPN boundaries. Such leakage is highly undesirable 559 when inter-VPN isolation is used for privacy or security reasons. 560 When that is the case, UDP checksums SHOULD be used for MPLS-in-UDP 561 with both IPv4 and IPv6, and in particular, UDP zero-checksum mode 562 SHOULD NOT be used with IPv6. Each UDP checksum covers the VPN 563 label, thereby providing increased assurance of isolation among VPNs. 565 7. IANA Considerations 567 One UDP destination port number indicating MPLS needs to be allocated 568 by IANA: 570 Service Name: MPLS-in-UDP 572 Transport Protocol(s): UDP 573 Assignee: IESG 575 Contact: IETF Chair . 577 Description: Encapsulate MPLS packets in UDP tunnels. 579 Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG 580 document). 582 Port Number: TBD1 -- To be assigned by IANA. 584 One UDP destination port number indicating MPLS with DTLS needs to be 585 allocated by IANA: 587 Service Name: MPLS-in-UDP-with-DTLS 589 Transport Protocol(s): UDP 591 Assignee: IESG 593 Contact: IETF Chair . 595 Description: Encapsulate MPLS packets in UDP tunnels with DTLS. 597 Reference: This document -- draft-ietf-mpls-in-udp (MPLS WG 598 document). 600 Port Number: TBD2 -- To be assigned by IANA. 602 8. Contributors 604 Note that contributors are listed in alphabetical order according to 605 their last names. 607 Yongbing Fan 609 China Telecom 611 Email: fanyb@gsta.com 613 Adrian Farrel 615 Juniper Networks 617 Email: adrian@olddog.co.uk 618 Zhenbin Li 620 Huawei Technologies 622 Email: lizhenbin@huawei.com 624 Carlos Pignataro 626 Cisco Systems 628 Email: cpignata@cisco.com 630 Curtis Villamizar 632 Outer Cape Cod Network Consulting, LLC 634 Email: curtis@occnc.com 636 9. Acknowledgements 638 Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, 639 Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, 640 George Swallow, Loa Andersson, Vivek Kumar, Stewart Bryant, Wen 641 Zhang, Joel M. Halpern, Noel Chiappa, Scott Brim, Alia Atlas, 642 Alexander Vainshtein, Joel Jaeggli, Edward Crabbe, Mark Tinka, Lars 643 Eggert, Joe Touch, Lloyd Wood, Gorry Fairhurst, Weiguo Hao, Mark 644 Szczesniak, Zhenxiao Liu and Xing Tong for their valuable comments 645 and suggestions on this document. 647 Special thanks to Alia Atlas for her insightful suggestion of adding 648 an applicability statement. 650 Thanks to Daniel King, Gregory Mirsky and Eric Osborne for their 651 valuable MPLS-RT reviews on this document. Thanks to Charlie Kaufman 652 for his SecDir review of this document. Thanks to Nevil Brownlee for 653 the OPSDir review of this document. Thanks to Roni Even for the Gen- 654 ART review of this document. Thanks to Pearl Liang for the IANA 655 review of this documents. 657 10. References 658 10.1. Normative References 660 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 661 August 1980. 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, March 1997. 666 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 667 (IPv6) Specification", RFC 2460, December 1998. 669 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 670 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 671 Encoding", RFC 3032, January 2001. 673 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 674 Internet Protocol", RFC 4301, December 2005. 676 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 677 for Application Designers", BCP 145, RFC 5405, November 678 2008. 680 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 681 Security Version 1.2", RFC 6347, January 2012. 683 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 684 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 686 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 687 for the Use of IPv6 UDP Datagrams with Zero Checksums", 688 RFC 6936, April 2013. 690 10.2. Informative References 692 [I-D.fairhurst-tsvwg-circuit-breaker] 693 Fairhurst, G., "Network Transport Circuit Breakers", 694 draft-fairhurst-tsvwg-circuit-breaker-01 (work in 695 progress), May 2014. 697 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 698 "Definition of the Differentiated Services Field (DS 699 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 700 1998. 702 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 703 2914, September 2000. 705 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating 706 MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 707 4023, March 2005. 709 [RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and 710 J. Young, "Encapsulation of MPLS over Layer 2 Tunneling 711 Protocol Version 3", RFC 4817, March 2007. 713 [RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load- 714 Balancing for Mesh Softwires", RFC 5640, August 2009. 716 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 717 for Equal Cost Multipath Routing and Link Aggregation in 718 Tunnels", RFC 6438, November 2011. 720 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 721 Locator/ID Separation Protocol (LISP)", RFC 6830, January 722 2013. 724 Authors' Addresses 726 Xiaohu Xu 727 Huawei Technologies 728 No.156 Beiqing Rd 729 Beijing 100095 730 CHINA 732 Phone: +86-10-60610041 733 Email: xuxiaohu@huawei.com 735 Nischal Sheth 736 Juniper Networks 737 1194 N. Mathilda Ave 738 Sunnyvale, CA 94089 739 USA 741 Email: nsheth@juniper.net 743 Lucy Yong 744 Huawei USA 745 5340 Legacy Dr 746 Plano, TX 75025 747 USA 749 Email: Lucy.yong@huawei.com 750 Ross Callon 751 Juniper Networks 752 10 Technology Park Drive 753 Westford, MA 01886 754 USA 756 Email: rcallon@juniper.net 758 David Black 759 EMC Corporation 760 176 South Street 761 Hopkinton, MA 01748 762 USA 764 Email: david.black@emc.com