idnits 2.17.1 draft-mkonstan-l2tpext-keyed-ipv6-tunnel-00.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 (November 05, 2013) is 3824 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Konstantynowicz, Ed. 3 Internet-Draft G. Heron, Ed. 4 Intended status: Informational Cisco Systems 5 Expires: May 09, 2014 R. Schatzmayr 6 Deutsche Telekom AG 7 W. Henderickx 8 Alcatel-Lucent, Inc. 9 November 05, 2013 11 Keyed IPv6 Tunnel 12 draft-mkonstan-l2tpext-keyed-ipv6-tunnel-00 14 Abstract 16 This document describes a simple L2 Ethernet over IPv6 tunnel 17 encapsulation with mandatory 64-bit key for connecting L2 Ethernet 18 attachment circuits identified by IPv6 addresses. The encapsulation 19 is based on L2TPv3 over IP. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 09, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Static 1:1 Mapping Without a Control Plane . . . . . . . . . 3 63 3. 64-bit Cookie . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Fragmentation and Reassembly . . . . . . . . . . . . . . . . 6 66 6. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 8 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 11.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 L2TPv3, as defined in RFC3931 [RFC3931], provides a dynamic mechanism 79 for tunneling Layer 2 (L2) "circuits" across a packet-oriented data 80 network (e.g., over IP), with multiple attachment circuits 81 multiplexed over a single pair of IP address endpoints (i.e. a 82 tunnel) using the L2TPv3 session ID as a circuit discriminator. 84 Implementing L2TPv3 over IPv6 provides the opportunity to utilize 85 unique IPv6 addresses to identify Ethernet attachment circuits 86 directly, leveraging the key property that IPv6 offers, a vast number 87 of unique IP addresses. In this case, processing of the L2TPv3 88 Session ID may be bypassed upon receipt as each tunnel has one and 89 only one associated session. This local optimization does not hinder 90 the ability to continue supporting the multiplexing of circuits via 91 the Session ID on the same router for other L2TPv3 tunnels. 93 2. Static 1:1 Mapping Without a Control Plane 95 Static local configuration creates a one-to-one mapping between the 96 access-side L2 attachment circuit and the IP address used in the 97 network-side IPv6 encapsulation. The L2TPv3 Control Plane defined in 98 RFC3931 [RFC3931] is not used. 100 The IPv6 L2TPv3 tunnel encapsulating device uniquely identifies each 101 Ethernet L2 attachment connection by a port ID or a combination of 102 port ID and VLAN ID(s) on the access side, and by an IPv6 address on 103 the network side. 105 Any VLAN identifiers, S-VID, C-VID or tuple ( S-VID, C-VID ) are 106 treated with local significance within the Ethernet L2 port and are 107 not forwarded over the IPv6 L2TPv3 tunnel. IPv6 address is treated 108 as the IPv6 L2TPv3 tunnel endpoint. 110 Certain deployment scenarios may require using a single IPv6 address 111 to identify a tunnel endpoint for many IPv6 L2TPv3 tunnels. For such 112 cases the tunnel encapsulating device identifies each tunnel by a 113 unique combination of tunnel source and destination IPv6 addresses. 115 As mentioned above Session ID processing is not required as each 116 keyed IPv6 tunnel has one and only one associated session. However 117 for compatibility with existing RFC3931 [RFC3931] implementations, 118 the packets need to be sent with Session ID. The router implementing 119 L2TPv3 according to RFC3931 [RFC3931] can be configured with multiple 120 L2TPv3 tunnels, with one session per tunnel, to interoperate with the 121 router implementing the keyed IPv6 tunnel as specified by this 122 document. 124 Note that a previous IETF draft [I.D.ietf-pppext-l2tphc] introduces 125 the concept of an L2TP tunnel carrying a single session and hence not 126 requiring session ID processing. 128 3. 64-bit Cookie 130 In line with RFC3931 [RFC3931], the key in the cookie field is used 131 for additional tunnel endpoint context check. All packets MUST carry 132 a 64-bit key in the L2TPv3 cookie field. The cookie MUST be 64-bits 133 long in order to provide sufficient protection against spoofing and 134 brute force blind insertion attacks. 136 In the absence of the L2TPv3 Control Plane, the L2TPv3 encapsulating 137 router must be provided with local configuration of the 64-bit cookie 138 for each local and remote IPv6 endpoint - note that cookies are 139 asymmetric, so local and remote endpoints may send different cookie 140 values. The value of the cookie must be able to be changed at any 141 time in a manner that does not drop any legitimate tunneled packets - 142 i.e. the receiver must be willing to accept both "old" and "new" 143 cookie values during a change of cookie value. 145 4. Encapsulation 147 RFC4719 [RFC4719] describes encapsulation of Ethernet over L2TPv3. 148 Paraphrasing from this document, the Ethernet frame, without the 149 preamble or frame check sequence (FCS), is encapsulated in L2TPv3 and 150 is sent as a single packet by the ingress router. 152 The s-tag (or in the multi-stack access case the s-tag and c-tag) 153 SHOULD be removed before the packet is encapsulated. 155 The full encapsulation is as follows: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Ver | Traffic Class | Flow Label | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Payload Length | Next Header | Hop Limit | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Source address (0:31) | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Source address (32:63) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Source address (64:95) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Source address (96:127) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Destination address (0:31) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Destination address (32:63) | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Destination address (64:95) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Destination address (96:127) | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Session ID (32 bits) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Cookie (0:31) | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Cookie (32:63) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Payload (variable) | 187 | ? | 188 | ? | 189 | ? | 190 | ? | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 The combined IPv6 and L2TPv3 header contains the following fields: 195 o Ver. Set to 0x6 to indicate IPv6. 197 o Traffic Class. May be set by the ingress router to ensure correct 198 PHB treatment by transit routers between the ingress and egress, 199 and correct QoS disposition at the egress router. 201 o Flow Label. May be set by the ingress router to indicate a flow 202 of packets from the client which may not be reordered by the 203 network (if there is a requirement for finer grained ECMP load 204 balancing than per-circuit load balancing). 206 o Payload Length. Set to the length of the packet, excluding the 207 IPv6 header (i.e. the length from the Session ID to the end of the 208 packet). 210 o Next Header. Set to 0x73 to indicate that the next header is 211 L2TPv3. 213 o Hop Limit. Set to 0xFF, and decremented by one by each router in 214 the path to the egress router. 216 o Source Address. IPv6 source address for the tunnel. In the 217 "Static 1:1" case the IPv6 source address may correspond to a port 218 or VLAN being transported as an L2 circuit, or may be a loopback 219 address terminating inside the router (e.g. if L2 circuits are 220 being used within a multipoint VPN) or may be an anycast address 221 terminating on a data center virtual machine. 223 o Destination Address. IPv6 destination address for the tunnel. As 224 with the source address this may correspond to a port or VLAN 225 being transported as an L2 circuit or may be a loopback or anycast 226 address. 228 o Session ID. In the "Static 1:1 mapping" case described in 229 Section 2, the IPv6 address resolves to an L2TPv3 session 230 immediately, thus the Session ID may be ignored upon receipt. For 231 compatibility with other tunnel termination platforms supporting 232 only 2-stage resolution (IPv6 Address + Session ID), this 233 specification recommends supporting explicit configuration of 234 Session ID to any value other than zero. For cases where both 235 tunnel endpoints support one-stage resolution (IPv6 Address only), 236 this specification recommends setting the Session ID to all ones 237 for easy identification in case of troubleshooting. The Session 238 ID of zero MUST NOT be used, as it is reserved for use by L2TP 239 control messages RFC3931 [RFC3931]. 241 o Cookie. 64 bits, configured and described as in Section 3. All 242 packets for a destined L2 Circuit (or L2TPv3 Session) must match 243 the configured Cookie value or be discarded (see RFC3931 [RFC3931] 244 for more details). 246 o Payload. The customer data, with s-tag or s-tag/c-tag removed. 247 As noted above preamble and FCS are stripped before encapsulation. 248 A new FCS will be added at each hop when the IP packet is 249 transmitted. 251 5. Fragmentation and Reassembly 253 Using tunnel encapsulation, Ethernet L2 datagrams in IPv6 in this 254 case, will reduce the effective MTU of the Ethernet L2 datagram. 256 The recommended solution to deal with this problem is for the network 257 operator to increase the MTU size of all the links between the 258 devices acting as IPv6 L2TPv3 tunnel endpoints to accommodate both 259 the IPv6 L2TPv3 encapsulation header and the Ethernet L2 datagram 260 without fragmenting the IPv6 packet. 262 If it is impossible to increase the link MTU across the network, the 263 IPv6 L2TPv3 encapsulating device MUST perform fragmentation and 264 reassembly if the outgoing link MTU cannot accommodate the extra IPv6 265 L2TPv3 header for specific Ethernet L2 payload. Fragmentation MUST 266 happen after the encapsulation of the IPv6 L2TPv3 packet. Reassembly 267 MUST happen before the decapsulation of the IPv6 L2TPv3 packet. 269 The proposed approach is in line with the DS-Lite specification 270 RFC6333 [RFC6333]. 272 6. OAM Considerations 274 OAM is an important consideration when providing circuit-oriented 275 services such as those described in this document, and all the more 276 so in the absence of a dedicated tunnel control plane, as OAM becomes 277 the only way to detect failures in the tunnel overlay. 279 Note that in the context of keyed IP tunnels, failures in the IPv6 280 underlay network can be detected using the usual methods such as 281 through the routing protocol. 283 Since keyed IP tunnels always carry an Ethernet payload, and since 284 OAM at the tunnel layer is unable to detect failures in the Ethernet 285 service processing at the ingress or egress router, or on the 286 Ethernet attachment circuit between the router and the Ethernet 287 client, this document recommends that Ethernet OAM as defined in IEEE 288 802.1ag [IEEE802.1ag] and/or ITU Y.1731 [Y.1731] is enabled for keyed 289 IP tunnels. More specifically the following Connecitivity Fault 290 Management ( CFM ) and/or Ethernet continuity check ( ETH-CC ) 291 configurations are to be used in conjunction with keyed IPv6 tunnels: 293 o Connectivity verification between the tunnel endpoints across the 294 tunnel - use an Up MEP located at the tunnel endpoint for 295 transmitting the CFM PDUs towards, and receiving them from the 296 direction of the tunnel. 298 o Connectivity verification from the tunnel endpoint across the 299 local attachment circuit - use a Down MEP located at the tunnel 300 endpoint for transmitting the CFM PDUs towards, and receiving them 301 from the direction of the local attachment circuit. 303 o Intermediate connectivity verifcation - use a MIP located at the 304 tunnel endpoint to generate CFM PDUs in response to received CFM 305 PDUs. 307 In addition the Pseudowire Virtual Circuit Connectivity Verfiication 308 ( VCCV ) RFC5085 [RFC5085] MAY be used. 310 7. IANA Considerations 312 None. 314 8. Security Considerations 316 Packet spoofing for any type of Virtual Private Network (VPN) 317 tunneling protocol is of particular concern as insertion of carefully 318 constructed rogue packets into the VPN transit network could result 319 in a violation of VPN traffic separation, leaking data into a 320 customer VPN. This is complicated by the fact that it may be 321 particularly difficult for the operator of the VPN to even be aware 322 that it has become a point of transit into or between customer VPNs. 324 Keyed IPv6 encapsulation provides traffic separation for its VPNs via 325 use of separate 128-bit IPv6 addresses to identify the endpoints. 326 The mandatory authentication key carried in the L2TPv3 cookie field, 327 provides an additional check to ensure that an arriving packet is 328 intended for the identified tunnel. 330 In the presence of a blind packet spoofing attack, the authentication 331 key provides security against inadvertent leaking of frames into a 332 customer VPN, like in case of L2TPv3 RFC3931 [RFC3931]. To 333 illustrate the type of security that it is provided in this case, 334 consider comparing the validation of a 64-bit Cookie in the L2TPv3 335 header to the admission of packets that match a given source and 336 destination IP address pair. Both the source and destination IP 337 address pair validation and Cookie validation consist of a fast check 338 on cleartext header information on all arriving packets. However, 339 since L2TPv3 uses its own value, it removes the requirement for one 340 to maintain a list of (potentially several) permitted or denied IP 341 addresses, and moreover, to guard knowledge of the permitted IP 342 addresses from hackers who may obtain and spoof them. Further, it is 343 far easier to change a compromised L2TPv3 Cookie than a compromised 344 IP address," and a cryptographically random RFC4086 [RFC4086] value 345 is far less likely to be discovered by brute-force attacks compared 346 to an IP address. 348 For protection against brute-force, blind, insertion attacks, a 64- 349 bit Cookie MUST be used with all tunnels. 351 Note that the Cookie provides no protection against a sophisticated 352 man-in-the-middle attacker who can sniff and correlate captured data 353 between nodes for use in a coordinated attack. 355 The L2TPv3 64-bit cookie must not be regarded as a substitute for 356 security such as that provided by IPsec when operating over an open 357 or untrusted network where packets may be sniffed, decoded, and 358 correlated for use in a coordinated attack. 360 9. Contributing Authors 362 Peter Weinberger 363 Cisco Systems 365 Email: peweinbe@cisco.com 367 Michael Lipman 368 Cisco Systems 370 Email: mlipman@cisco.com 372 Mark Townsley 373 Cisco Systems 375 Email: townsley@cisco.com 377 10. Acknowledgements 379 The authors would like to thank Carlos Pignataro for his suggestions 380 and review. 382 11. References 384 11.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 390 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 392 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 393 Requirements for Security", BCP 106, RFC 4086, June 2005. 395 [RFC4719] Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport 396 of Ethernet Frames over Layer 2 Tunneling Protocol Version 397 3 (L2TPv3)", RFC 4719, November 2006. 399 [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 400 Connectivity Verification (VCCV): A Control Channel for 401 Pseudowires", RFC 5085, December 2007. 403 11.2. Informative References 405 [I.D.ietf-pppext-l2tphc] 406 Valencia, A., "L2TP Header Compression", December 1997. 408 [IEEE802.1ag] 409 IEEE, "IEEE Standard for Local and metropolitan area 410 networks - Virtual Bridged Local Area Networks, Amendment 411 5: Connectivity Fault Managements", 2007. 413 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 414 Stack Lite Broadband Deployments Following IPv4 415 Exhaustion", RFC 6333, August 2011. 417 [Y.1731] ITU, "ITU-T Recommendation G.8013/Y.1731 - OAM functions 418 and mechanisms for Ethernet based networks", 2011. 420 Authors' Addresses 422 Maciek Konstantynowicz (editor) 423 Cisco Systems 425 Email: maciek@cisco.com 427 Giles Heron (editor) 428 Cisco Systems 430 Email: giheron@cisco.com 432 Rainer Schatzmayr 433 Deutsche Telekom AG 435 Email: rainer.schatzmayr@telekom.de 437 Wim Henderickx 438 Alcatel-Lucent, Inc. 440 Email: wim.henderickx@alcatel-lucent.com