idnits 2.17.1 draft-ietf-trill-over-ip-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 : ---------------------------------------------------------------------------- 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 (October 31, 2016) is 2726 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 7321 (Obsoleted by RFC 8221) ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Margaret Cullen 2 Intended Status: Proposed Standard Painless Security 3 Updates: 7177, 7178 Donald Eastlake 4 Mingui Zhang 5 Dacheng Zhang 6 Huawei 7 Expires: April 30, 2017 October 31, 2016 9 TRILL (Transparent Interconnection of Lots of Links) over IP 10 12 Abstract 13 The TRILL (Transparent Interconnection of Lots of Links) protocol 14 supports both point-to-point and multi-access links and is designed 15 so that a variety of link protocols can be used between TRILL switch 16 ports. This document standardizes methods for encapsulating TRILL in 17 IP (v4 or v6) so as to use IP as a TRILL link protocol in a unified 18 TRILL campus. It updates RFC 7177 and updates RFC 7178. 20 Status of This Document 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Distribution of this document is unlimited. Comments should be sent 26 to the authors or the TRILL Working Group mailing list 27 . 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 41 Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Introduction............................................4 47 2. Terminology.............................................5 49 3. Use Cases for TRILL over IP.............................6 50 3.1 Remote Office Scenario.................................6 51 3.2 IP Backbone Scenario...................................6 52 3.3 Important Properties of the Scenarios..................6 53 3.3.1 Security Requirements................................7 54 3.3.2 Multicast Handling...................................7 55 3.3.3 Neighbor Discovery...................................8 57 4. TRILL Packet Formats....................................9 58 4.1 General Packet Formats.................................9 59 4.2 General TRILL Over IP Packet Formats..................10 60 4.2.1 Without Security....................................10 61 4.2.2 With Security.......................................10 62 4.3 QoS Considerations....................................11 63 4.4 Broadcast Links and Multicast Packets.................12 64 4.5 TRILL Over IP IS-IS SubNetwork Point of Attachment....13 66 5. TRILL over IP Encapsulation Formats....................14 67 5.1 Encapsulation Considerations..........................14 68 5.2 Encapsulation Agreement...............................15 69 5.3 Broadcast Link Encapsulation Considerations...........16 70 5.4 Native Encapsulation..................................17 71 5.5 VXLAN Encapsulation...................................17 72 5.6 Other Encapsulations..................................18 74 6. Handling Multicast.....................................19 76 7. Use of IPsec and IKEv2.................................20 77 7.1 Keying................................................20 78 7.1.1 Pairwise Keying.....................................20 79 7.1.2 Group Keying........................................21 80 7.2 Mandatory-to-Implement Algorithms.....................21 82 8. Transport Considerations...............................22 83 8.1 Congestion Considerations.............................22 84 8.2 Recursive Ingress.....................................23 85 8.3 Fat Flows.............................................24 86 8.4 MTU Considerations....................................25 87 8.5 Middlebox Considerations..............................25 89 9. TRILL over IP Port Configuration.......................27 90 9.1 Per IP Port Configuration.............................27 91 9.2 Additional per IP Address Configuration...............27 92 9.2.1 Native Multicast Configuration......................28 93 9.2.2 Serial Unicast Configuration........................28 95 Table of Contents (continued) 97 9.2.3 Encapsulation Specific Configuration................28 98 9.2.3.1 UDP Source Port...................................28 99 9.2.3.2 VXLAN Configuration...............................29 100 9.2.3.3 Other Encapsulation Configuration.................29 101 9.2.4 Security Configuration..............................29 103 10. Security Considerations...............................30 104 10.1 IPsec................................................30 105 10.2 IS-IS Security.......................................31 107 11. IANA Considerations...................................32 108 11.1 Port Assignments.....................................32 109 11.2 Multicast Address Assignments........................32 110 11.3 Encapsulation Method Support Indication..............32 112 Normative References......................................34 113 Informative References....................................36 115 Acknowledgements..........................................38 116 Authors' Addresses........................................39 118 1. Introduction 120 TRILL switches (RBridges) are devices that implement the IETF TRILL 121 protocol [RFC6325] [RFC7177] [RFC7780]. TRILL provides transparent 122 forwarding of frames within an arbitrary network topology, using 123 least cost paths for unicast traffic. It supports VLANs and Fine 124 Grained Labels [RFC7172] as well as multipathing of unicast and 125 multi-destination traffic. It uses IS-IS [IS-IS] [RFC7176] link state 126 routing and encapsulation with a hop count. 128 RBridge ports can communicate with each other over various protocols, 129 such as Ethernet [RFC6325], pseudowires [RFC7173], or PPP [RFC6361]. 131 This document defines a method for RBridge ports to communicate over 132 IP (v4 or v6). TRILL over IP allows RBridges to form a single TRILL 133 campus, or multiple TRILL networks to be connected as a single TRILL 134 campus via a TRILL over IP backbone. 136 TRILL over IP connects RBridge ports using IPv4 or IPv6 as a 137 transport in such a way that the ports with IP connectivity appear to 138 TRILL to be connected by a single multi-access link. If more than two 139 RBridge ports are connected via a single TRILL over IP link, any pair 140 of them can communicate. 142 To support the scenarios where RBridges are connected via IP paths 143 (including those over the public Internet) that are not under the 144 same administrative control as the TRILL campus and/or not physically 145 secure, this document specifies the use of IPsec [RFC4301] 146 Encapsulating Security Protocol (ESP) [RFC4303] for security. 148 To dynamically select a mutually supported TRILL over IP 149 encapsulation, normally one with good fast path hardware support, a 150 method is provided for agreement between adjacent TRILL switch ports 151 as to what encapsulation to use. Alternatively, where a common 152 encapsulation is supported by the TRILL switch ports on a link, they 153 can simply be configured to use that encapsulation. 155 This document updates [RFC7177] and [RFC7178] as described in Section 156 5 by making adjacency between TRILL over IP ports dependent on having 157 a method of encapsulation in common and by redefining an interval of 158 RBridge Channel protocol numbers to indicate encapsulation method 159 support for TRILL over IP links. 161 2. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 The following terms and acronyms have the meaning indicated: 169 DRB - Designated RBridge. The RBridge (TRILL switch) elected to be in 170 charge of certain aspects of a TRILL link that is not 171 configured as a point-to-point link [RFC6325] [RFC7177]. 173 ENCAP Hdr - Encapsulation headers in use between the IP Header and 174 the TRILL Header. See Section 5. 176 ESP - IPsec Encapsulating Security Protocol [RFC4303]. 178 FGL - Fine Grained Label [RFC7172]. 180 Hdr - Used herein as an abbreviation for "Header". 182 HKDF - Hash based Key Derivation Function [RFC5869]. 184 MTU - Maximum Transmission Unit. 186 RBridge - Routing Bridge. An alternative term for a TRILL switch. 188 SNPA - Sub-Network Point of Attachment. 190 Sz - The campus wide MTU [RFC6325] [RFC7780]. 192 TRILL - Transparent Interconnection of Lots of Links or Tunneled 193 Routing in the Link Layer. The protocol specified in [RFC6325], 194 [RFC7177], [RFC7780], and related RFCs. 196 TRILL switch - A device implementing the TRILL protocol. 198 VNI - Virtual Network Identifier. In VXLAN [RFC7348], the VXLAN 199 Network Identifier. 201 3. Use Cases for TRILL over IP 203 This section introduces two application scenarios (a remote office 204 scenario and an IP backbone scenario) which cover typical situations 205 where network administrators may choose to use TRILL over an IP 206 network to connect TRILL switches. 208 3.1 Remote Office Scenario 210 In the Remote Office Scenario, a remote TRILL network is connected to 211 a TRILL campus across a multihop IP network, such as the public 212 Internet. The TRILL network in the remote office becomes a part of 213 TRILL campus, and nodes in the remote office can be attached to the 214 same VLANs or Fine Grained Labels [RFC7172] as local campus nodes. In 215 many cases, a remote office may be attached to the TRILL campus by a 216 single pair of RBridges, one on the campus end, and the other in the 217 remote office. In this use case, the TRILL over IP link will often 218 cross logical and physical IP networks that do not support TRILL, and 219 are not under the same administrative control as the TRILL campus. 221 3.2 IP Backbone Scenario 223 In the IP Backbone Scenario, TRILL over IP is used to connect a 224 number of TRILL networks to form a single TRILL campus. For example, 225 a TRILL over IP backbone could be used to connect multiple TRILL 226 networks on different floors of a large building, or to connect TRILL 227 networks in separate buildings of a multi-building site. In this use 228 case, there may often be several TRILL switches on a single TRILL 229 over IP link, and the IP link(s) used by TRILL over IP are typically 230 under the same administrative control as the rest of the TRILL 231 campus. 233 3.3 Important Properties of the Scenarios 235 There are a number of differences between the above two application 236 scenarios, some of which drive features of this specification. These 237 differences are especially pertinent to the security requirements of 238 the solution, how multicast data frames are handled, and how the 239 TRILL switch ports discover each other. 241 3.3.1 Security Requirements 243 In the IP Backbone Scenario, TRILL over IP is used between a number 244 of RBridge ports, on a network link that is in the same 245 administrative control as the remainder of the TRILL campus. While it 246 is desirable in this scenario to prevent the association of 247 unauthorized RBridges, this can be accomplished using existing IS-IS 248 security mechanisms. There may be no need to protect the data 249 traffic, beyond any protections that are already in place on the 250 local network. 252 In the Remote Office Scenario, TRILL over IP may run over a network 253 that is not under the same administrative control as the TRILL 254 network. Nodes on the network may think that they are sending traffic 255 locally, while that traffic is actually being sent, in an IP tunnel, 256 over the public Internet. It is necessary in this scenario to protect 257 the integrity and confidentiality of user traffic, as well as 258 ensuring that no unauthorized RBridges can gain access to the RBridge 259 campus. The issues of protecting integrity and confidentiality of 260 user traffic are addressed by using IPsec for both TRILL IS-IS and 261 TRILL Data packets between RBridges in this scenario. 263 3.3.2 Multicast Handling 265 In the IP Backbone scenario, native IP multicast may be supported on 266 the TRILL over IP link. If so, it can be used to send TRILL IS-IS and 267 multicast data packets, as discussed later in this document. 268 Alternatively, multi-destination packets can be transmitted serially 269 by IP unicast to the intended recipients. 271 In the Remote Office Scenario there will often be only one pair of 272 RBridges connecting a given site and, even when multiple RBridges are 273 used to connect a Remote Office to the TRILL campus, the intervening 274 network may not provide reliable (or any) multicast connectivity. 275 Issues such as complex key management also make it difficult to 276 provide strong data integrity and confidentiality protections for 277 multicast traffic. For all of these reasons, the connections between 278 local and remote RBridges will commonly be treated like point-to- 279 point links, and all TRILL IS-IS control messages and multicast data 280 packets that are transmitted between the Remote Office and the TRILL 281 campus will be serially transmitted by IP unicast, as discussed later 282 in this document. 284 3.3.3 Neighbor Discovery 286 In the IP Backbone Scenario, TRILL switches that use TRILL over IP 287 can use the normal TRILL IS-IS Hello mechanisms to discover the 288 existence of other TRILL switches on the link [RFC7177], and to 289 establish authenticated communication with them. 291 In the Remote Office Scenario, an IPsec session will need to be 292 established before TRILL IS-IS traffic can be exchanged, as discussed 293 below. In this case, one end will need to be configured to establish 294 a IPSEC session with the other. This will typically be accomplished 295 by configuring the TRILL switch or a border device at a Remote Office 296 to initiate an IPsec session and subsequent TRILL exchanges with a 297 TRILL over IP-enabled RBridge attached to the TRILL campus. 299 4. TRILL Packet Formats 301 To support TRILL two types of TRILL packets are transmitted between 302 TRILL switches: TRILL Data packets and TRILL IS-IS packets. 304 Section 4.1 describes general TRILL packet formats for data and IS-IS 305 independent of link technology. Section 4.2 specifies general TRILL 306 over IP packet formats including IPsec ESP encapsulation. Section 4.3 307 provides QoS Considerations. Section 4.4 discusses broadcast links 308 and multicast packets. And Section 4.5 provides TRILL IS-IS Hello 309 SubNetwork Point of Attachment (SNPA) considerations for TRILL over 310 IP. 312 4.1 General Packet Formats 314 The on-the-wire form of a TRILL Data packet in transit between two 315 neighboring TRILL switch ports is as shown below: 317 +----------------+----------+----------------+-----------+ 318 | Link Header | TRILL | Native Frame | Link | 319 | for TRILL Data | Header | Payload | Trailer | 320 +----------------+----------+----------------+-----------+ 322 The encapsulated Native Frame Payload is similar to an Ethernet frame 323 with a VLAN tag or Fine Grained Label [RFC7172] but with no trailing 324 Frame Check Sequence (FCS). 326 TRILL IS-IS packets are formatted on-the-wire as follows: 328 +-----------------+---------------+-----------+ 329 | Link Header | TRILL IS-IS | Link | 330 | for TRILL IS-IS | Payload | Trailer | 331 +-----------------+---------------+-----------+ 333 The Link Header and Link Trailer in these formats depend on the 334 specific link technology. The Link Header contains one or more fields 335 that distinguish TRILL Data from TRILL IS-IS. For example, over 336 Ethernet, the Link Header for TRILL Data ends with the TRILL 337 Ethertype while the Link Header for TRILL IS-IS ends with the L2-IS- 338 IS Ethertype; on the other hand, over PPP, there are no Ethertypes in 339 the Link Header but PPP protocol code points are included that 340 distinguish TRILL Data from TRILL IS-IS. 342 4.2 General TRILL Over IP Packet Formats 344 In TRILL over IP, we use an IP (v4 or v6) header followed by an 345 encapsulation header as the link header. (On the wire, the IP header 346 will normally be preceded by the lower layer header of a protocol 347 that is carrying IP; however, this does not concern us at the level 348 of this document.) 350 There are multiple IP based encapsulations usable for TRILL over IP 351 that differ in exactly what appears after the IP header and before 352 the TRILL Header or the TRILL IS-IS Payload. These encapsulations are 353 further detailed in Section 5. In the general specification below, 354 those encapsulation fields will be represented as "ENCAP Hdr". 356 4.2.1 Without Security 358 When TRILL over IP link security is not being used, a TRILL over IP 359 packet on the wire looks like one of the following: 361 TRILL Data Packet 362 +---------+-----------+---------+------------------+ 363 | IP | ENCAP Hdr | TRILL | Native frame | 364 | Header | for Data | Header | Payload | 365 +---------+-----------+---------+------------------+ 366 <--- link header ----> 368 TRILL IS-IS Packet 369 +---------+-----------+-----------------+ 370 | IP | ENCAP Hdr | TRILL IS-IS | 371 | Header | for IS-IS | Payload | 372 +---------+-----------+-----------------+ 373 <--- link header ----> 375 As discussed above and further specified in Section 5, the ENCAP Hdr 376 indicates whether the packet is TRILL Data or IS-IS. 378 4.2.2 With Security 380 TRILL over IP link security uses IPsec Encapsulating Security 381 Protocol (ESP) in tunnel mode [RFC4303]. Since TRILL over IP always 382 starts with an IP Header (on the wire this appears after any lower 383 layer header that might be required), the modifications for IPsec are 384 independent of the TRILL over IP ENCAP Hdr that occurs after that IP 385 Header. The resulting packet formats are as follows for IPv4 and 386 IPv6: 388 With IPv4: 389 +-------------+-----+--------------+-----------+-----------+ 390 | new IP Hdr | ESP | TRILL IP Hdr | ENCAP Hdr | ESP |ESP| 391 |(any options)| Hdr | (any options)| + payload |Trailer|ICV| 392 +-------------+-----+--------------+-----------+-----------+ 393 |<---------- encryption ---------->| 394 |<-------------- integrity ------------->| 396 With IPv6: 397 +------+-------+-----+------+--------+-----------+-------+---+ 398 | new |new ext| ESP | orig |orig ext| ENCAP Hdr | ESP |ESP| 399 |IP Hdr| Hdrs | Hdr |IP Hdr| Hdrs | + payload |Trailer|ICV| 400 +------+-------+-----+------+--------+-----------+-------+---+ 401 |<----------- encryption ---------->| 402 |<--------------- integrity ------------->| 404 As shown above, IP Header options are considered part of the IPv4 405 Header but are extensions ("ext") of the IPv6 Header. For further 406 information on the IPsec ESP Hdr, Trailer, and ICV, see [RFC4303] and 407 Section 7 below. "ENCAP Hdr + payload" is the encapsulation header 408 (Section 5) and TRILL data or the encapsulation header and IS-IS 409 payload, that is, the material after the IP Header in the diagram in 410 Section 4.2.1. 412 This architecture permits the ESP tunnel end point to be separated 413 from the TRILL over IP RBridge port (see, for example, Section 1.1.3 414 of [RFC7296]). 416 4.3 QoS Considerations 418 In IP, QoS handling is indicated by the Differentiated Services Code 419 Point (DSCP [RFC2474] [RFC3168]) in the IP Header. The former Type 420 of Service (TOS) octet in the IPv4 Header and the Traffic Class octet 421 in the IPv6 Header has been divided as shown in the following diagram 422 adapted from [RFC3168]. (TRILL support of ECN is beyond the scope of 423 this document. See [TRILLECN].) 425 0 1 2 3 4 5 6 7 426 +-----+-----+-----+-----+-----+-----+-----+-----+ 427 | DSCP FIELD | ECN FIELD | 428 +-----+-----+-----+-----+-----+-----+-----+-----+ 430 DSCP: Differentiated Services Codepoint 431 ECN: Explicit Congestion Notification 433 Within a TRILL switch, priority is indicated by configuration for 434 TRILL IS-IS packets and for TRILL Data packets by a three bit (0 435 through 7) priority field and a Drop Eligibility Indicator bit (see 436 Sections 8.2 and 7 of [RFC7780]). (Typically TRILL IS-IS is 437 configured to use the highest two priorities depending on the IS-IS 438 PDU.) The priority affects queuing behavior at TRILL switch ports and 439 may be encoded into the link header, particularly if there could be 440 priority sensitive devices within the link. For example, if the link 441 is a bridged LAN, it is commonly encoded into an Outer.VLAN tag's 442 priority and DEI fields. 444 TRILL over IP implementations MUST support setting the DSCP value in 445 the outer IP Header of TRILL packets they send by mapping the TRILL 446 priority and DEI to the DSCP. They MAY support, for a TRILL Data 447 packet where the native frame payload is an IP packet, mapping the 448 DSCP in this inner IP packet to the outer IP Header with the default 449 for that mapping being to copy the DSCP without change. 451 The default TRILL priority and DEI to DSCP mapping, which may be 452 configured per TRILL over IP port, is an follows. Note that the DEI 453 value does not affect the default mapping and, to provide a 454 potentially lower priority service than the default priority 0, 455 priority 1 is considered lower priority than 0. So the priority 456 sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7. 458 TRILL Priority DEI DSCP Field (Binary/decimal) 459 -------------- --- ----------------------------- 460 0 0/1 001000 / 8 461 1 0/1 000000 / 0 462 2 0/1 010000 / 16 463 3 0/1 011000 / 24 464 4 0/1 100000 / 32 465 5 0/1 101000 / 40 466 6 0/1 110000 / 48 467 7 0/1 111000 / 56 469 4.4 Broadcast Links and Multicast Packets 471 TRILL supports broadcast links. These are links to which more than 472 two TRILL switch ports can be attached and where a packet can be 473 broadcast or multicast from a port to all or a subset of the other 474 ports on the link as well as unicast to a specific other port on the 475 link. 477 As specified in [RFC6325], TRILL Data packets being forwarded between 478 TRILL switches can be unicast on a link to a specific TRILL switch 479 port or multicast on a link to all TRILL switch ports. TRILL IS-IS 480 packets are always multicast to all other TRILL switches on the link 481 except for IS-IS MTU PDUs, which may be unicast [RFC7177]. This 482 distinction is not significant if the link is inherently point-to- 483 point, such as a PPP link; however, on a broadcast link there will be 484 a packet outer link address that will be unicast or multicast as 485 appropriate. For example, over Ethernet links, the Ethernet multicast 486 addresses All-RBridges and All-IS-IS-RBridges are used for 487 multicasting TRILL Data and TRILL IS-IS respectively. For details on 488 TRILL over IP handling of multicast, see Section 6. 490 4.5 TRILL Over IP IS-IS SubNetwork Point of Attachment 492 IS-IS routers, such as TRILL switches, establish adjacency through 493 the exchange of Hello PDUs on a link [IS-IS] [RFC7177]. The Hellos 494 transmitted out a port indicate what neighbor ports that port can see 495 on the link by listing what IS-IS refers to as the neighbor port's 496 SubNetwork Point of Attachment (SNPA). (For an Ethernet link, which 497 may be a bridged network, the SNPA is the port MAC address.) 499 In TRILL Hello PDUs on a TRILL over IP link, the IP addresses of the 500 IP ports connected to that link are their actual SNPA (SubNetwork 501 Point of Attachment [IS-IS]) addresses and, for IPv6, the 16-byte 502 IPv6 address is used as the SNPA; however, for easy in re-using code 503 designed for the common case of 48-bit SNPAs, in TRILL over IPv4 a 504 48-bit synthetic SNPA that looks like a unicast MAC address is 505 constructed for use in the SNPA field of TRILL Neighbor TLVs 506 [RFC7176] [RFC7177] in such Hellos. This synthetic SNPA is derived 507 from the port IPv4 address is as follows: 509 1 1 1 1 1 1 510 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | 0xFE | 0x00 | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | IPv4 upper half | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | IPv4 lower half | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 This synthetic SNPA (MAC) address has the local (0x02) bit on in the 520 first byte and so cannot conflict with any globally unique 48-bit 521 Ethernet MAC. However, when TRILL operates on an IP link, TRILL sees 522 only IP addresses on that link, not MAC stations, even if the TRILL 523 over IP Link is being carried over Ethernet. Therefore conflict on 524 the link between a real MAC address and a TRILL over IP synthetic 525 SNPA (MAC) address would be impossible in any case. 527 5. TRILL over IP Encapsulation Formats 529 There are a variety of TRILL over IP encapsulation formats possible. 530 By default TRILL over IP adopts a hybrid encapsulation approach. 532 There is one format, called "native encapsulation" that MUST be 533 implemented. Although native encapsulation does not typically have 534 good fast path support, as a lowest common denominator it can be used 535 by low bandwidth control traffic to determine a preferred 536 encapsulation with better performance. In particular, by default, all 537 TRILL IS-IS Hellos are sent using native encapsulation and those 538 Hellos are used to determine the encapsulation used for all TRILL 539 Data packets and all other TRILL IS-IS PDUs (with the exception of 540 IS-IS MTU-probe and MTU-ack PDUs used to establish adjacency). 542 Alternatively, the network operator can pre-configure a TRILL over IP 543 port to use a particular encapsulation chosen for their particular 544 network's needs and port capabilities. That encapsulation is then 545 used for all TRILL Data and IS-IS packets on ports so configured. 546 This is expected to frequently be the case for a managed campus of 547 TRILL switches. 549 Section 5.1 discusses general consideration for the TRILL over IP 550 encapsulation format. Section 5.2 discusses encapsulation agreement. 551 Section 5.3 discusses broadcast link encapsulation considerations. 552 The subsequent subsections discuss particular encapsulations. 554 5.1 Encapsulation Considerations 556 An encapsulation must provide a method to distinguish TRILL Data 557 packets and TRILL IS-IS packets, or it is not useful for TRILL. In 558 addition, the following criteria can be helpful is choosing between 559 different encapsulations: 561 a) Fast path support - For most applications, it is highly desirable 562 to be able to encapsulate/decapsulate TRILL over IP at line speed 563 so a format where existing or anticipated fast path hardware can 564 do that is best. This is commonly the dominant consideration. 566 b) Ease of multi-pathing - The IP path between TRILL over IP ports 567 may include equal cost multipath routes internal to the IP link so 568 a method of encapsulation that provides variable fields available 569 for existing or anticipated fast path hardware multi-pathing is 570 preferred. 572 c) Robust fragmentation and re-assembly - The MTU of the IP link may 573 require fragmentation in which case an encapsulation with robust 574 fragmentation and re-assembly is important. There are known 575 problems with IPv4 fragmentation and re-assembly [RFC6864] which 576 generally do not apply to IPv6. Some encapsulations can fix these 577 problems but the encapsulations specified in this document do not. 578 Therefore, if fragmentation is anticipated with the encapsulations 579 specified in this document, the use of IPv6 is RECOMMENDED. 581 d) Checksum strength - Depending on the particular circumstances of 582 the TRILL over IP link, a checksum provided by the encapsulation 583 may be a significant factor. Use of IPsec can also provide a 584 strong integrity check. 586 5.2 Encapsulation Agreement 588 TRILL Hellos sent out a TRILL over IP port indicate the 589 encapsulations that port is willing to support through a mechanism 590 initially specified in [RFC7178] and [RFC7176] that is hereby 591 extended. Specifically, RBridge Channel Protocol numbers 0xFD0 592 through 0xFF7 are redefined to be link technology dependent flags 593 that, for TRILL over IP, indicate support for different 594 encapsulations, allowing support for up to 40 encapsulations to be 595 specified. Support for an encapsulation is indicated in the Hello 596 PDU in the same way that support for an RBridge Channel was 597 indicated. (See also section 11.3.) "Support" indicates willingness 598 to use that encapsulation for TRILL Data and TRILL IS-IS packets 599 (although TRILL IS-IS Hellos are still sent in native encapsulation 600 by default unless the port is configured to always use some other 601 encapsulation). 603 If, in a TRILL Hello on a TRILL over IP link, support is not 604 indicated for any encapsulation, then the port from which it was sent 605 is assumed to support only native encapsulation (see Section 5.4). 607 An adjacency is formed between two TRILL over IP ports if the 608 intersection of the sets of encapsulation methods they support is not 609 null. If that intersection is null, then no adjacency is formed. In 610 particular, for a TRILL over IP link, the adjacency state machine 611 MUST NOT advance to the Report state unless the ports share an 612 encapsulation [RFC7177]. If no encapsulation is shared, the adjacency 613 state machine remains in the state from which it would otherwise have 614 transitioned to the Report state. 616 If any TRILL over IP packet, other than an IS-IS Hello or MTU PDU in 617 native encapsulation, is received in an encapsulation for which 618 support is not being indicated by the receiver, that packet MUST be 619 discarded (see Section 5.3). 621 If there are two or more encapsulations in common between two 622 adjacent ports for unicast or the set of adjacent ports for 623 multicast, a transmitter is free to choose whichever of the 624 encapsulations it wishes to use. Thus transmissions between adjacent 625 ports P1 and P2 could use different encapsulations depending on which 626 port is transmitting and which is receiving. 628 It is expected to be the normal case in a well configured network 629 that all the TRILL over IP ports connected to an IP link (i.e., an IP 630 network) that are intended to communicate with each other will 631 support the same encapsulation(s). 633 5.3 Broadcast Link Encapsulation Considerations 635 To properly handle TRILL protocol packets on a TRILL over IP link in 636 the general case, either native IP multicast mode is used on that 637 link or multicast must be simulated using serial IP unicast, as 638 discussed in Section 6. (Of course, if the IP link happens to 639 actually be point-to-point no special provision is needed for 640 handling IP multicast addressed packets.) 642 It is possible for the Hellos from a TRILL over IP port P1 to 643 establish adjacency with multiple other TRILL over IP ports (P2, P3, 644 ...) on a broadcast link. In a well configured network one would 645 expect all of the IP ports involved to support the same 646 encapsulation(s); but, for example, if P1 supports multiple 647 encapsulations, it is possible that P2 and P3, do not have an 648 encapsulation in common that is supported by P1. [IS-IS] can handle 649 such non-transitive adjacencies that are reported as specified in 650 [RFC7177]. This is generally done, albeit with reduced efficiency, by 651 forwarding through the designated RBridge (router) on the link. Thus 652 it is RECOMENDED that all TRILL over IP ports on an IP link be 653 configured to support one encapsulation in common that has good fast 654 path support. 656 If serial IP unicast is being used by P1, it can use different 657 encapsulations for different transmissions. 659 If native IP multicast is available for use by P1, it can send one 660 transmission per encapsulation method by which it has a disjoint set 661 of adjacencies on the link. If the transmitting port has adjacencies 662 with overlapping sets of ports that are adjacent using different 663 encapsulations, use of native multicast with different encapsulations 664 may result in packet duplication. It would always be possible to use 665 native IP multicast for one encapsulation for which the transmitting 666 port has adjacencies, perhaps the encapsulation for which it has the 667 largest number of adjacencies, and serially unicast to other 668 receivers. These considerations are the reason that a TRILL over IP 669 port MUST discard any packet received with an encapsulation for which 670 it has not established an adjacency with the receiver. Otherwise, 671 packets would be further duplicated. 673 5.4 Native Encapsulation 675 The mandatory to implement "native encapsulation" format of a TRILL 676 over IP packet, when used without security, is TRILL over UDP as 677 shown below. This provides simple and direct access by TRILL to the 678 native datagram service of IP. 680 +----------+--------+-----------------------+ 681 | IP | UDP | TRILL | 682 | Header | Header | Payload | 683 +----------+--------+-----------------------+ 685 Where the UDP Header is as follows: 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Source Port = Entropy | Destination Port | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | UDP Length | UDP Checksum | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | TRILL Payload ... 696 Source Port - see Section 8.3 698 Destination Port - indicates TRILL Data or IS-IS, see Section 699 11.1. 701 UDP Length - as specified in [RFC0768] 703 UDP Checksum - as specified in [RFC0768] 705 The TRILL Payload starts with the TRILL Header (not including the 706 TRILL Ethertype) for TRILL Data packets and starts with the 0x83 707 Intradomain Routeing Protocol Discriminator byte (thus not including 708 the L2-IS-IS Ethertype) for TRILL IS-IS packets. 710 5.5 VXLAN Encapsulation 712 VXLAN [RFC7348] IP encapsulation of TRILL looks, on the wire, like 713 TRILL over Ethernet over VXLAN over UDP over IP. 715 +--------+--------+--------+----------+-----------+ 716 | IP | UDP | VXLAN | Ethernet | TRILL | 717 | Header | Header | Header | Header | Payload | 718 +--------+--------+--------+----------+-----------+ 720 The outer UDP uses a destination port number indicating VXLAN and the 721 outer UDP source port MAY be used for entropy as with native 722 encapsulation (see Section 8.3). The VXLAN header after the outer UDP 723 header adds a 24 bit Virtual Network Identifier (VNI). The Ethernet 724 header after the VXLAN header and before the TRILL header consists of 725 source MAC address, destination MAC address, and Ethertype. The 726 Ethertype distinguishes TRILL Data from TRILL IS-IS. The destination 727 and source MAC addresses in this Ethernet header are not used. 729 A TRILL over IP port using VXLAN encapsulation by default uses a VNI 730 of 1 for TRILL IS-IS traffic and a VNI of 2 for TRILL data traffic 731 but can be configured as described in Section 9.2.3.1 to use some 732 other fixed VNIs or to map from VLAN/FGL to VNI. 734 5.6 Other Encapsulations 736 It is anticipated that additional TRILL over IP encapsulations will 737 be specified in future documents and allocated a link technology 738 specific flag bit as per Section 11.3. A primary consideration for 739 whether it is worth the effort to specify use of an encapsulation by 740 TRILL over IP is whether it has good existing or anticipated fast 741 path support. 743 6. Handling Multicast 745 By default, both TRILL IS-IS packets and multi-destination TRILL Data 746 packets are sent to an All-RBridges IPv4 or IPv6 IP multicast Address 747 as appropriate (see Section 11.2); however, a TRILL over IP port may 748 be configured (see Section 9) to use a different multicast address or 749 to use serial IP unicast with a list of one or more unicast IP 750 addresses of other TRILL over IP ports to which multi-destination 751 packets are sent. In the serial unicast case the outer IP header of 752 each copy of the packet sent shows an IP unicast destination address 753 even through the TRILL header has the M bit set to one to indicate 754 multi-destination. Serial unicast configuration is necessary if the 755 TRILL over IP port is connected to an IP network that does not 756 support IP multicast. In any case, unicast TRILL packets (those with 757 the M bit in the TRILL Header set to zero) are sent by unicast IP. 759 Even if a TRILL over IP port is configured to send multi-destination 760 packets with serial unicast, it MUST be prepared to receive IP 761 multicast TRILL packets. All TRILL over IP ports default to 762 periodically transmitting appropriate IGMP (IPv4 [RFC3376]) or MLD 763 (IPv6 [RFC2710]) packets, so that the TRILL multicast IP traffic can 764 be sent to them, but may be configured not to do so. 766 Although TRILL fully supports broadcast links with more than 2 767 RBridges connected to the link there may be good reasons for 768 configuring TRILL over IP ports to use serial unicast even where 769 native IP multicast is available. Use of serial unicast provides the 770 network manager with more precise control over adjacencies and how 771 TRILL over IP links will be formed in an IP network. In some 772 networks, unicast is more reliable than multicast. If multiple point- 773 to-point TRILL over IP connections between two parts of a TRILL 774 campus are configured, TRILL will in any case spread traffic across 775 them, treating them as parallel links, and appropriately fail over 776 traffic if a link fails or incorporate a new link that comes up. 778 7. Use of IPsec and IKEv2 780 All TRILL switches (RBridges) that support TRILL over IP MUST 781 implement IPsec [RFC4301] and support the use of IPsec Encapsulating 782 Security Protocol (ESP [RFC4303]) in tunnel mode to secure both TRILL 783 IS-IS and TRILL Data packets. When IPsec is used to secure a TRILL 784 over IP link and no IS-IS security is enabled, the IPsec session MUST 785 be fully established before any TRILL IS-IS or data packets are 786 exchanged. When there is IS-IS security [RFC5310] provided, 787 implementers SHOULD use IS-IS security to protect TRILL IS-IS 788 packets. However, in this case, the IPsec session still MUST be fully 789 established before any TRILL Data packets transmission, since IS-IS 790 security does not provide any protection to data packets, and SHOULD 791 be fully established before any TRILL IS-IS packet transmission other 792 than IS-IS Hello or MTU PDUs. 794 All RBridges that support TRILL over IP MUST implement the Internet 795 Key Exchange Protocol version 2 (IKEv2) for automated key management. 797 7.1 Keying 799 The following subsections discuss pairwise and group keying for TRILL 800 over IP IPsec. 802 7.1.1 Pairwise Keying 804 When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that 805 incorporates the IS-IS shared key in order to bind the TRILL data 806 session to the IS-IS session. The pre-shared key that will be used 807 for IKEv2 exchanges for TRILL over IP is determined as follows: 809 HKDF-Expand-SHA256 ( IS-IS-key, 810 "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port ) 812 In the above "|" indicates concatenation, HKDF is as in [RFC5869], 813 SHA256 is as in [RFC6234], and "TRILL IP" is the eight byte US ASCII 814 [RFC0020] string indicated. "IS-IS-key" is an IS-IS key usable for 815 IS-IS security of link local IS-IS PDUs such as Hello, CSNP, and 816 PSNP. This SHOULD be a link scope IS-IS key. P1-System-ID and 817 P2-System ID are the six byte System IDs of the two TRILL RBridges, 818 and P1-Port and P2-Port are the TRILL Port IDs [RFC6325] of the ports 819 in use on each end. System IDs are guaranteed to be unique within the 820 TRILL campus. Both of the RBridges involved treat the larger 821 magnitude System ID, comparing System IDs as unsigned integers, as P1 822 and the smaller as P2 so both will derive the same key. 824 With [RFC5310] there could be multiple keys identified with 16-bit 825 key IDs. The key ID when an IS-IS key is in use is transmitted in an 826 IKEv2 ID_KEY_ID identity field [RFC7296] with Identification Data 827 length of 2 bytes (Payload Length 6 bytes). The Key ID of the IS-IS- 828 key is used to identify the IKEv2 shared secret derived as above that 829 is actually used. ID_KEY_ID identity field(s) of other lengths MAY 830 occur but their use is beyond the scope of this document. 832 The IS-IS-shared key from which the IKEv2 shared secret is derived 833 might expire and be updated as described in [RFC5310]. The IKEv2 834 pre-shared keys derived from an IS-IS shared key MUST expire within a 835 lifetime no longer than the IS-IS-shared key from which they were 836 derived. When the IKEv2 shared secret key expires, or earlier, the 837 IKEv2 Security Association must be rekeyed using a new shared secret 838 derived from a new IS-IS shared key. 840 IKEv2 with certificate based security MAY be used but details of 841 certificate contents and use policy for this application of IKEv2 are 842 beyond the scope of this document. 844 7.1.2 Group Keying 846 In the case of a TRILL over IP port configured as point-to-point (see 847 Section 4.2.4.1 of [RFC6325]), there is no group keying and the 848 pairwise keying determined as in Section 7.1.1 is used for multi- 849 destination TRILL traffic, which is unicast. 851 In the case of a TRILL over IP port configured as broadcast but where 852 the port is configured to use serial unicast (see Section 8), there 853 is no group keying and the pairwise keying determined as in Section 854 7.1.1 is used for multi-destination TRILL traffic, which is unicast. 856 The case of a TRILL over IP port configured as broadcast and using 857 native multicast is beyond the scope of this document. For security 858 as provided in this document, multicast is handled via serial 859 unicast. 861 7.2 Mandatory-to-Implement Algorithms 863 All RBridges that support TRILL over IP MUST implement IPsec ESP 864 [RFC4303] in tunnel mode. The implementation requirements for ESP 865 cryptographic algorithms are as specified for IPsec. That 866 specification is currently [RFC7321]. 868 8. Transport Considerations 870 This section discusses a variety of important transport 871 considerations. 873 8.1 Congestion Considerations 875 Section 3.1.3 of [RFC5405] discussed the congestion implications of 876 UDP tunnels. As discussed in [RFC5405], because other flows can share 877 the path with one or more UDP tunnels, congestion control [RFC2914] 878 needs to be considered. 880 The default initial determination of the TRILL over IP encapsulation 881 to be used through the exchange of TRILL IS-IS Hellos is a low 882 bandwidth process. Hellos are not permitted to be sent any more often 883 than once per second, and so are very unlikely to cause congestion. 885 One motivation for including UDP in a TRILL encapsulation is to 886 improve the use of multipath (such as ECMP) in cases where traffic is 887 to traverse routers which are able to hash on UDP Port and IP 888 address. In many cases this may reduce the occurrence of congestion 889 and improve usage of available network capacity. However, it is also 890 necessary to ensure that the network, including applications that use 891 the network, responds appropriately in more difficult cases, such as 892 when link or equipment failures have reduced the available capacity. 894 The impact of congestion must be considered both in terms of the 895 effect on the rest of the network of a UDP tunnel that is consuming 896 excessive capacity, and in terms of the effect on the flows using the 897 UDP tunnels. The potential impact of congestion from a UDP tunnel 898 depends upon what sort of traffic is carried over the tunnel, as well 899 as the path of the tunnel. 901 TRILL is used to carry a wide range of traffic. In many cases TRILL 902 is used to carry IP traffic. IP traffic is generally assumed to be 903 congestion controlled, and thus a tunnel carrying general IP traffic 904 (as might be expected to be carried across the Internet) generally 905 does not need additional congestion control mechanisms. As specified 906 in [RFC5405]: 908 "IP-based traffic is generally assumed to be congestion- 909 controlled, i.e., it is assumed that the transport protocols 910 generating IP-based traffic at the sender already employ 911 mechanisms that are sufficient to address congestion on the path. 912 Consequently, a tunnel carrying IP-based traffic should already 913 interact appropriately with other traffic sharing the path, and 914 specific congestion control mechanisms for the tunnel are not 915 necessary". 917 For this reason, where TRILL is sent using UDP and used to carry IP 918 traffic that is known to be congestion controlled, the UDP paths MAY 919 be used across any combination of a single or cooperating service 920 providers or across the general Internet. 922 However, TRILL is also used to carry traffic that is not necessarily 923 congestion controlled. For example, TRILL may be used to carry 924 traffic where specific bandwidth guarantees are provided. 926 In such cases congestion may be avoided by careful provisioning of 927 the network and/or by rate limiting of user data traffic. Where TRILL 928 is carried, directly or indirectly, over UDP over IP, the identity of 929 each individual TRILL flow is in general lost. 931 For this reason, where the TRILL traffic is not congestion 932 controlled, TRILL over UDP/IP MUST only be used within a single 933 service provider that utilizes careful provisioning (e.g., rate 934 limiting at the entries of the network while over-provisioning 935 network capacity) to ensure against congestion, or within a limited 936 number of service providers who closely cooperate in order to jointly 937 provide this same careful provisioning. As such, TRILL over UDP/IP 938 MUST NOT be used as a general TRILL encapsulation over the general 939 Internet, or over non-cooperating service providers, to carry traffic 940 that is not congestion-controlled. 942 Measures SHOULD be taken to prevent non-congestion-controlled TRILL 943 over UDP/IP traffic from "escaping" to the general Internet, for 944 example the following: 946 a. Physical or logical isolation of the TRILL over IP links from the 947 general Internet. 949 b. Deployment of packet filters that block the UDP ports assigned for 950 TRILL-over-UDP. 952 c. Imposition of restrictions on TRILL over UDP/IP traffic by 953 software tools used to set up TRILL over UDP paths between 954 specific end systems (as might be used within a single data 955 center). 957 d. Use of a "Managed Circuit Breaker" for the TRILL traffic as 958 described in [circuit-breaker]. 960 8.2 Recursive Ingress 962 TRILL is specified to transport data to and from end stations over 963 Ethernet and IP is frequently transported over Ethernet. Thus, an end 964 station native data Ethernet frame "EF" might get TRILL ingressed to 965 TRILL(EF) that was subsequently sent to a next hop RBridge out a 966 TRILL over IP over Ethernet port resulting in a packet on the wire of 967 the form Ethernet(IP(TRILL(EF))). There is a risk of such a packet 968 being re-ingressed by the same TRILL campus, due to physical or 969 logical misconfiguration, looping round, being further re-ingressed, 970 and so on. (Or this might occur through a cycle of TRILL campuses.) 971 The packet would get discarded if it got too large but if 972 fragmentation is enabled, it would just keep getting split into 973 fragments that would continue to loop and grow and re-fragment until 974 the path was saturated with junk and packets were being discarded due 975 to queue overflow. The TRILL Header TTL would provide no protection 976 because each TRILL ingress adds a new TRILL header with a new TTL. 978 To protect against this scenario, a TRILL over IP port MUST, by 979 default, test whether a TRILL packet it is about to transmit appears 980 to be a TRILL ingress of a TRILL over IP over Ethernet packet. That 981 is, is it of the form TRILL(Ethernet(IP(TRILL(...)))? If so, the 982 default action of the TRILL over IP output port is to discard the 983 packet rather than transmit it. However, there are cases where some 984 level of nested ingress is desired so it MUST be possible to 985 configure the port to allow such packets. 987 8.3 Fat Flows 989 For the purpose of load balancing, it is worthwhile to consider how 990 to transport TRILL packets over any Equal Cost Multiple Paths (ECMPs) 991 existing internal to the IP path between TRILL over IP ports. 993 The ECMP election for the IP traffic could be based, for example with 994 IPv4, on the quintuple of the outer IP header { Source IP, 995 Destination IP, Source Port, Destination Port, and IP protocol }. 996 Such tuples, however, could be exactly the same for all TRILL Data 997 packets between two RBridge ports, even if there is a huge amount of 998 data being sent between a variety of ingress and egress RBridges. On 999 solution to this is to use the UDP Source Port as an entropy field. 1000 (This idea is also introduced in [gre-in-udp].) For example, for 1001 TRILL Data, this entropy field could be based on some hash of the 1002 Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. Unfortunately, 1003 this can conflict with middleboxes inside the TRILL over IP link (see 1004 8.5). Therefore, in order to better support ECMP, a RBridge SHOULD 1005 set the Source Port to a range of values as an entropy field for ECMP 1006 decisions; this range SHOULD be the ephemeral port range 1007 (49152-65535) except that, if there are middleboxes in the path (see 1008 Section 8.5), it MUST be possible to configure the range of different 1009 Source Port values to a sufficiently smaller range to avoid 1010 disrupting connectivity. 1012 8.4 MTU Considerations 1014 In TRILL each RBridge advertises in its LSP number zero the largest 1015 LSP frame it can accept (but not less than 1,470 bytes) on any of its 1016 interfaces (at least those interfaces with adjacencies to other TRILL 1017 switches in the campus) through the originatingLSPBufferSize TLV 1018 [RFC6325] [RFC7177]. The campus minimum MTU (Maximum Transmission 1019 Unit), denoted Sz, is then established by taking the minimum of this 1020 advertised MTU for all RBridges in the campus. Links that do not meet 1021 the Sz MTU are not included in the routing topology. This protects 1022 the operation of IS-IS from links that would be unable to accommodate 1023 the largest LSPs. 1025 A method of determining originatingLSPBufferSize for an RBridge with 1026 one or more TRILL over IP ports is described in [RFC7780]. However, 1027 if an IP link either can accommodate jumbo frames or is a link on 1028 which IP fragmentation is enabled and acceptable, then it is unlikely 1029 that the IP link will be a constraint on the originatingLSPBufferSize 1030 of an RBridge using the link. On the other hand, if the IP link can 1031 only handle smaller frames and fragmentation is to be avoided when 1032 possible, a TRILL over IP port might constrain the RBridge's 1033 originatingLSPBufferSize. 1035 Because TRILL sets the minimum values of Sz at 1,470 bytes, there may 1036 be links that meet the minimum MTU for the IP protocol (1,280 bytes 1037 for IPv6, 576 bytes for IPv4) on which it would be necessary to 1038 enable fragmentation for safe TRILL use. 1040 The use of TRILL IS-IS MTU PDUs, as specified in Section 5 of 1041 [RFC6325] and in [RFC7177], can provide added assurance of the actual 1042 MTU of a link. 1044 8.5 Middlebox Considerations 1046 This section gives some middlebox considerations for the IP 1047 encapsulations covered by this document, namely native and VXLAN 1048 encapsulation. 1050 The requirements for the usage of the zero UDP Checksum in a UDP 1051 tunnel protocol are detailed in [RFC6936]. These requirements apply 1052 to the TRILL over IP encapsulations specified herein (native and 1053 VXLAN), which are applications of UDP tunnel. 1055 Besides the Checksum, the Source Port number of the UDP header is 1056 also pertinent to the middlebox behavior. Network Address/Port 1057 Translator (NAPT) is the most commonly deployed Network Address 1058 Translation (NAT) device [RFC4787]. For a UDP tunnel protocol, the 1059 NAPT device establishes a NAT session to translate the {private IP 1060 address, private source port number} tuple to a {public IP address, 1061 public source port number} tuple, and vice versa, for the duration of 1062 the UDP session. This provides the UDP tunnel protocol application 1063 with the "NAT-pass-through" function. NAPT allows multiple internal 1064 hosts to share a single public IP address. The port number, i.e., the 1065 UDP Source Port number, is used as the demultiplexer of the multiple 1066 internal hosts. 1068 However, the above NAPT behavior conflicts with the behavior that the 1069 UDP Source Port number is used as an entropy (See Section 8.3). 1070 Hence, the network operator MUST ensure the TRILL switch ports 1071 sending through local or remote NAPT middleboxes limit the entropy 1072 usage of the UDP Source Port number, possibly to a single value. 1074 9. TRILL over IP Port Configuration 1076 This section specifies the configuration information needed at a 1077 TRILL over IP port beyond that needed for a general RBridge port. 1079 9.1 Per IP Port Configuration 1081 Each RBridge port used for a TRILL over IP link should have at least 1082 one IP (v4 or v6) address. If no IP address is associated with the 1083 port, perhaps as a transient condition during re-configuration, the 1084 port is disabled. Implementations MAY allow a single port to operate 1085 as multiple IPv4 and/or IPv6 logical ports. Each IP address 1086 constitutes a different logical port and the RBridge with those ports 1087 MUST associate a different Port ID (see Section 4.4.2 of [RFC6325]) 1088 with each logical port. 1090 By default a TRILL over IP port discards output packets that fail the 1091 possible recursive ingress test (see Section 10.1) unless configured 1092 to disable that test. 1094 9.2 Additional per IP Address Configuration 1096 The configuration information specified below is per TRILL over IP 1097 port IP address. 1099 The mapping from TRILL packet priority to TRILL over IP 1100 Differentiated Services Code Point (DSCP [RFC2474]) can be 1101 configured. If supported, mapping from an inner DSCP code point, when 1102 the TRILL payload is IP, to the outer TRILL over IP DSCP can be 1103 configured. (See Section 4.3.) 1105 Each TRILL over IP port has a list of acceptable encapsulations it 1106 will use as the basis of adjacency. By default this list consists of 1107 one entry for native encapsulation (see Section 7). Additional 1108 encapsulations MAY be configured and native encapsulation MAY be 1109 removed from this list by configuration. Additional configuration can 1110 be required or possible for specific encapsulations as described in 1111 Section 9.2.3. 1113 Each IP address at a TRILL over IP port uses native IP multicast by 1114 default but may be configured whether to use serial IP unicast 1115 (Section 9.2.2) or native IP multicast (Section 9.2.1). Each IP 1116 address at a TRILL over IP is configured whether or not to use IPsec 1117 (Section 9.2.4). 1119 Regardless of whether they will send IP multicast, TRILL over IP 1120 ports emit appropriate IGMP (IPv4 [RFC3376]) or MLD (IPv6 [RFC2710]) 1121 packets unless configured not to do so. These are sent for the IP 1122 multicast group the port would use if it sent IP multicast. 1124 9.2.1 Native Multicast Configuration 1126 If a TRILL over IP port address is using native IP multicast for 1127 multi-destination TRILL packets (IS-IS and data), by default 1128 transmissions from that IP address use the IP multicast address (IPv4 1129 or IPv6) specified in Section 11.2. The TRILL over IP port may be 1130 configured to use a different IP multicast address for multicasting 1131 packets. 1133 9.2.2 Serial Unicast Configuration 1135 If a TRILL over IP port address has been configured to use serial 1136 unicast for multi-destination packets (IS-IS and data), it should 1137 have associated with it a non-empty list of unicast IP destination 1138 addresses with the same IP version as the version of the port's IP 1139 address (IPv4 or IPv6). Multi-destination TRILL packets are serially 1140 unicast to the addresses in this list. Such a TRILL over IP port will 1141 only be able to form adjacencies [RFC7177] with the RBridges at the 1142 addresses in this list as those are the only RBridges to which it 1143 will send TRILL Hellos. IP packets received from a source IP address 1144 not on the list are discarded. 1146 If this list of destination IP addresses is empty, the port is 1147 disabled. 1149 9.2.3 Encapsulation Specific Configuration 1151 Specific TRILL over IP encapsulation methods may provide for further 1152 configuration as specified below. 1154 9.2.3.1 UDP Source Port 1156 As discussed above, the native starts with a UDP header where the 1157 source UDP port can be used for entropy (Section 8.3). The range of 1158 UDP source port values used defaults to the ephemeral port range 1159 (49152-65535) but can be configured to any other range including to a 1160 single value. 1162 9.2.3.2 VXLAN Configuration 1164 A TRILL over IP port using VXLAN encapsulation can be configured with 1165 non-default VXLAN Network Identifiers (VNIs) that are used in that 1166 field of the VXLAN header for all TRILL IS-IS and TRILL Data packets 1167 sent using the encapsulation and required in those received using the 1168 encapsulation. The default VNI is 1 for TRILL IS-IS and 2 for TRILL 1169 Data. A TRILL packet received with the an unknown VNI is discarded. 1171 A TRILL over IP port using VXLAN encapsulation can also be configured 1172 to map the Inner.VLAN of a TRILL Data packet being transported to the 1173 value it places in the VNI field and/or to copy the Inner.FGL of a 1174 TRILL Data packet to the VNI field. 1176 9.2.3.3 Other Encapsulation Configuration 1178 Additional encapsulation methods, beyond the native UDP encapsulation 1179 and VXLAN encapsulation specified in this document, are expected to 1180 be specified in future documents and may require further 1181 configuration. 1183 9.2.4 Security Configuration 1185 A TRILL over IP port can be configured, for the case where IS-IS 1186 security [RFC5310] is in use, as to whether or not IPsec must be 1187 fully established and used for any TRILL IS-IS transmissions other 1188 than IS-IS Hello or MTU PDUs (see Section 7). There may also be 1189 configuration whose details are outside the scope of this document 1190 concerning certificate based IPsec or use of shared keys other than 1191 IS-IS based shared key or how to select what IS-IS based shared key 1192 to use. 1194 10. Security Considerations 1196 TRILL over IP is subject to all of the security considerations for 1197 the base TRILL protocol [RFC6325]. In addition, there are specific 1198 security requirements for different TRILL deployment scenarios, as 1199 discussed in the "Use Cases for TRILL over IP", Section 3 above. 1201 For communication between end stations in a TRILL campus, security 1202 may be possible at three levels: end-to-end security between those 1203 end stations, edge-to-edge security between ingress and egress 1204 RBridges [LinkSec], and link security to protect a TRILL hop. Any 1205 combination of these can be used, including all three. 1207 TRILL over IP link security protects the contents of TRILL Data and 1208 IS-IS packets, including the identities of the end stations for 1209 data and the identities of the edge RBridges, from observers of 1210 the link and transit devices within the link such as bridges or IP 1211 routers, but does not encrypt the link local IP addresses used in 1212 a packet and does not protect against observation by the sending 1213 and receiving RBridges on the link. 1215 Edge-to-edge TRILL security would protect the contents of TRILL data 1216 packets including the identities of the end stations for data from 1217 transit RBridges but does not encrypt the identities of the edge 1218 RBridges involved and does not protect against observation by 1219 those edge RBridges. It is anticipated that edge-to-edge TRILL 1220 security will be covered in future documents. 1222 End-to-end security does not protect the identities of the end 1223 stations or edge RBridge involved but does protect the content of 1224 TRILL data packets from observation by all RBridges or other 1225 intervening devices between the end stations involved. End-to-end 1226 security should always be considered as an added layer of security 1227 to protect any particularly sensitive information from unintended 1228 disclosure. Such end station to end station security is generally 1229 beyond the scope of TRILL 1231 If VXLAN encapsulation is used, the unused Ethernet source and 1232 destination MAC addresses mentioned in Section 5.5, provide a 96 bit 1233 per packet side channel. 1235 10.1 IPsec 1237 This document specifies that all RBridges that support TRILL over IP 1238 links MUST implement IPsec for the security of such links, and makes 1239 it clear that it is both wise and good to use IPsec in all cases 1240 where a TRILL over IP link will traverse a network that is not under 1241 the same administrative control as the rest of the TRILL campus or is 1242 not secure. IPsec is important, in these cases, to protect the 1243 privacy and integrity of data traffic. However, in cases where IPsec 1244 is impractical due to lack of fast path support, use of TRILL edge- 1245 to-edge security or use by the end stations of end-to-end security 1246 can provide significant security. 1248 Further Security Considerations for IPsec ESP and for the 1249 cryptographic algorithms used with IPsec can be found in the RFCs 1250 referenced by this document. 1252 10.2 IS-IS Security 1254 TRILL over IP is compatible with the use of IS-IS Security [RFC5310], 1255 which can be used to authenticate TRILL switches before allowing them 1256 to join a TRILL campus. This is sufficient to protect against rogue 1257 devices impersonating TRILL switches, but is not sufficient to 1258 protect data packets that may be sent in TRILL over IP outside of the 1259 local network or across the public Internet. To protect the privacy 1260 and integrity of that traffic, use IPsec. 1262 In cases were IPsec is used, the use of IS-IS security may not be 1263 necessary, but there is nothing about this specification that would 1264 prevent using both IPsec and IS-IS security together. 1266 11. IANA Considerations 1268 IANA considerations are given below. 1270 11.1 Port Assignments 1272 IANA is requested to assign destination UDP Ports for the TRILL IS-IS 1273 and TRILL Data: 1275 UDP Port Protocol Reference 1276 ---------- --------------- ----------------- 1277 (TBD1) TRILL IS-IS [this document] 1278 (TBD2) TRILL Data [this document] 1280 11.2 Multicast Address Assignments 1282 IANA is requested to assign one IPv4 and one IPv6 multicast address, 1283 as shown below, which correspond to both the All-RBridges and All-IS- 1284 IS-RBridges multicast MAC addresses that have been assigned for 1285 TRILL. Because the low level hardware MAC address dispatch 1286 considerations for TRILL over Ethernet do not apply to TRILL over IP, 1287 one IP multicast address for each version of IP is sufficient. 1289 (Values recommended to IANA in square brackets) 1291 Name IPv4 IPv6 1292 ------------ ------------------ -------------------------- 1293 All-RBridges TBD3[233.252.14.0] TBD4[FF0X:0:0:0:0:0:0:BAC1] 1295 The hex digit "X" in the IPv6 variable scope address indicates the 1296 scope and defaults to 8. The IPv6 All-RBridges IP address may be used 1297 with other values of X. 1299 11.3 Encapsulation Method Support Indication 1301 The existing "RBridge Channel Protocols" registry is re-named and a 1302 new sub-registry under that registry added as follows: 1304 The TRILL Parameters registry for "RBridge Channel Protocols" is 1305 renamed the "RBridge Channel Protocols and Link Technology Specific 1306 Flags" registry. [this document] is added as a second reference for 1307 this registry. The first part of the table is changed to the 1308 following: 1310 Range Registration Note 1311 ----------- ---------------- ---------------------------- 1312 0x002-0x0FF Standards Action 1313 0x100-0xFCF RFC Required allocation of a single value 1314 0x100-0xFCF IESG Approval allocation of multiple values 1315 0xFD0 0xFF7 see Note link technology dependent, 1316 see subregistry 1318 In the existing table of RBridge Channel Protocols, the following 1319 line is changed to two lines as shown: 1321 OLD 1322 0x004-0xFF7 Unassigned 1323 NEW 1324 0x004-0xFCF Unassigned 1325 0xFD0-0xFF7 (link technology dependent, see subregistry) 1327 A new indented subregistry under the re-named "RBridge Channel 1328 Protocols and Link Technology Specific Flags" registry is added as 1329 follows: 1331 Name: TRILL over IP Link Flags 1332 Registration Procedure: Expert Review 1333 Reference: [this document] 1335 Flag Meaning Reference 1336 ----------- ------------------------------ --------- 1337 0xFD0 Native encapsulation supported [this document] 1338 0xFD1 VXLAN encapsulation supported [this document] 1339 0xFD2-0xFF7 Unassigned 1341 Normative References 1343 [IS-IS] - "Intermediate system to Intermediate system routeing 1344 information exchange protocol for use in conjunction with the 1345 Protocol for providing the Connectionless-mode Network Service 1346 (ISO 8473)", ISO/IEC 10589:2002, 2002". 1348 [RFC0020] - Cerf, V., "ASCII format for network interchange", STD 80, 1349 RFC 20, DOI 10.17487/RFC0020, October 1969, . 1352 [RFC0768] - Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 1353 10.17487/RFC0768, August 1980, . 1356 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1357 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1358 March 1997, . 1360 [RFC2474] - Nichols, K., Blake, S., Baker, F., and D. Black, 1361 "Definition of the Differentiated Services Field (DS Field) in 1362 the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, 1363 December 1998, . 1365 [RFC2710] - Deering, S., Fenner, W., and B. Haberman, "Multicast 1366 Listener Discovery (MLD) for IPv6", RFC 2710, DOI 1367 10.17487/RFC2710, October 1999, . 1370 [RFC2914] - Floyd, S., "Congestion Control Principles", BCP 41, RFC 1371 2914, DOI 10.17487/RFC2914, September 2000, . 1374 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1375 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 1376 10.17487/RFC3168, September 2001, . 1379 [RFC3376] - Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1380 Thyagarajan, "Internet Group Management Protocol, Version 3", 1381 RFC 3376, DOI 10.17487/RFC3376, October 2002, . 1384 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 1385 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 1386 2005, . 1388 [RFC4303] - Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1389 4303, DOI 10.17487/RFC4303, December 2005, . 1392 [RFC5405] - Li, T. and R. Atkinson, "IS-IS Cryptographic 1393 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, 1394 . 1396 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1397 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1398 5310, DOI 10.17487/RFC5310, February 2009, . 1401 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 1402 Expand Key Derivation Function (HKDF)", RFC 5869, DOI 1403 10.17487/RFC5869, May 2010, . 1406 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1407 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1408 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 1409 . 1411 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1412 D., and A. Banerjee, "Transparent Interconnection of Lots of 1413 Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, 1414 May 2014, . 1416 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1417 and V. Manral, "Transparent Interconnection of Lots of Links 1418 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 1419 . 1421 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1422 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1423 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 1424 2014, . 1426 [RFC7321] - McGrew, D. and P. Hoffman, "Cryptographic Algorithm 1427 Implementation Requirements and Usage Guidance for 1428 Encapsulating Security Payload (ESP) and Authentication Header 1429 (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, 1430 . 1432 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1433 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1434 eXtensible Local Area Network (VXLAN): A Framework for 1435 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 1436 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 1439 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 1440 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 1441 Lots of Links (TRILL): Clarifications, Corrections, and 1442 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 1443 . 1445 Informative References 1447 [RFC4787] - Audet, F., Ed., and C. Jennings, "Network Address 1448 Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 1449 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, 1450 . 1452 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 1453 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 1454 10.17487/RFC6234, May 2011, . 1457 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1458 Interconnection of Lots of Links (TRILL) Protocol Control 1459 Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, 1460 . 1462 [RFC6864] - Touch, J., "Updated Specification of the IPv4 ID Field", 1463 RFC 6864, DOI 10.17487/RFC6864, February 2013, . 1466 [RFC6936] - Fairhurst, G. and M. Westerlund, "Applicability Statement 1467 for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 1468 6936, DOI 10.17487/RFC6936, April 2013, . 1471 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1472 and D. Dutt, "Transparent Interconnection of Lots of Links 1473 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 1474 10.17487/RFC7172, May 2014, . 1477 [RFC7173] - Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 1478 "Transparent Interconnection of Lots of Links (TRILL) Transport 1479 Using Pseudowires", RFC 7173, DOI 10.17487/RFC7173, May 2014, 1480 . 1482 [RFC7296] - Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1483 Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", 1484 STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, 1485 . 1487 [circuit-breaker] - Fairhurst, G., "Network Transport Circuit 1488 Breakers", draft-ietf-tsvwg-circuit-breaker, work in progress. 1490 [gre-in-udp] - Crabbe, E., Yong, L., and X. Xu, "Generic UDP 1491 Encapsulation for IP Tunneling", draft-yong-tsvwg-gre-in-udp- 1492 encap, work in progress. 1494 [LinkSec] - Eastlake, D., D. Zhang, "TRILL: Link Security", draft- 1495 eastlake-trill-link-security, work in progress. 1497 [TRILLECN] - Eastlake, D., B. Briscoe, "TRILL: ECN (Explicit 1498 Congestion Notification) Support", draft-eastlake-trill-ecn- 1499 support, work in progress. 1501 Acknowledgements 1503 The following people have provided useful feedback on the contents of 1504 this document: Sam Hartman, Adrian Farrel, and Mohammed Umair. 1506 Some material in Section 10.2 is derived from draft-ietf-mpls-in-udp 1507 by Xiaohu Xu, Nischal Sheth, Lucy Yong, Carlos Pignataro, and 1508 Yongbing Fan. 1510 The document was prepared in raw nroff. All macros used were defined 1511 within the source file. 1513 Authors' Addresses 1515 Margaret Cullen 1516 Painless Security 1517 14 Summer Street, Suite 202 1518 Malden, MA 02148 1519 USA 1521 Phone: +1-781-605-3459 1522 Email: margaret@painless-security.com 1523 URI: http://www.painless-security.com 1525 Donald Eastlake 1526 Huawei Technologies 1527 155 Beaver Street 1528 Milford, MA 01757 1529 USA 1531 Phone: +1 508 333-2270 1532 Email: d3e3e3@gmail.com 1534 Mingui Zhang 1535 Huawei Technologies 1536 No.156 Beiqing Rd. Haidian District, 1537 Beijing 100095 P.R. China 1539 EMail: zhangmingui@huawei.com 1541 Dacheng Zhang 1542 Huawei Technologies 1544 Email: dacheng.zhang@huawei.com 1546 Copyright, Disclaimer, and Additional IPR Provisions 1548 Copyright (c) 2016 IETF Trust and the persons identified as the 1549 document authors. All rights reserved. 1551 This document is subject to BCP 78 and the IETF Trust's Legal 1552 Provisions Relating to IETF Documents 1553 (http://trustee.ietf.org/license-info) in effect on the date of 1554 publication of this document. Please review these documents 1555 carefully, as they describe your rights and restrictions with respect 1556 to this document. Code Components extracted from this document must 1557 include Simplified BSD License text as described in Section 4.e of 1558 the Trust Legal Provisions and are provided without warranty as 1559 described in the Simplified BSD License.