idnits 2.17.1 draft-ietf-trill-over-ip-17.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 (May 21, 2018) is 2157 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' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** 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: November 20, 2018 May 21, 2018 9 TRILL (Transparent Interconnection of Lots of Links) 10 Over IP Transport 11 13 Abstract 14 The TRILL (Transparent Interconnection of Lots of Links) protocol 15 supports both point-to-point and multi-access links and is designed 16 so that a variety of link protocols can be used between TRILL switch 17 ports. This document specifies transmission of encapsulated TRILL 18 data and IS-IS over IP (v4 or v6) transport. so as to use an IP 19 network as a TRILL link in a unified TRILL campus. This document 20 updates RFC 7177 and updates RFC 7178. 22 Status of This Document 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the authors or the TRILL Working Group mailing list 29 . 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 43 Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Table of Contents 48 1. Introduction............................................4 49 2. Terminology.............................................6 51 3. Use Cases for TRILL over IP Transport...................8 52 3.1 Remote Office Scenario.................................8 53 3.2 IP Backbone Scenario...................................8 54 3.3 Important Properties of the Scenarios..................9 55 3.3.1 Security Requirements................................9 56 3.3.2 Multicast Handling..................................10 57 3.3.3 Neighbor Discovery..................................10 59 4. TRILL Packet Formats...................................11 60 4.1 General Packet Formats................................11 61 4.2 General TRILL Over IP Packet Formats..................12 62 4.2.1 Without Security....................................12 63 4.2.2 With Security.......................................12 64 4.3 QoS Considerations....................................13 65 4.4 Broadcast Links and Multicast Packets.................15 66 4.5 TRILL Over IP Transport IS-IS SubNetwork Point 67 of Attachment.........15 69 5. TRILL over IP Transport Encapsulation Formats..........17 70 5.1 Encapsulation Considerations..........................17 71 5.2 Encapsulation Agreement...............................18 72 5.3 Broadcast Link Encapsulation Considerations...........19 73 5.4 Native Encapsulation..................................20 74 5.4.1 IPv4 UDP Checksum Considerations....................21 75 5.4.2 IPv6 UDP Checksum Considerations....................22 76 5.5 VXLAN Encapsulation...................................24 77 5.6 TCP Encapsulation.....................................25 78 5.6.1 TCP Connection Establishment........................26 79 5.7 Other Encapsulations..................................27 81 6. Handling Multicast.....................................28 83 7. Use of IPsec and IKEv2.................................29 84 7.1 Keying................................................29 85 7.1.1 Pairwise Keying.....................................29 86 7.1.2 Group Keying........................................30 87 7.2 Mandatory-to-Implement Algorithms.....................31 89 8. Transport Considerations...............................32 90 8.1 UDP Congestion Considerations.........................32 91 8.1.1 Within a TMCE.......................................33 92 8.1.2 In Other Environments...............................33 93 8.2 Recursive Ingress.....................................34 94 8.3 Fat Flows.............................................34 95 8.4 MTU Considerations....................................35 97 Table of Contents (continued) 99 9. TRILL over IP Transport Port Configuration.............37 100 9.1 Per IP Port Configuration.............................37 101 9.2 Additional per IP Address Configuration...............37 102 9.2.1 Native Multicast Configuration......................38 103 9.2.2 Serial Unicast Configuration........................38 104 9.2.3 Encapsulation Specific Configuration................38 105 9.2.3.1 UDP Source Port...................................38 106 9.2.3.2 VXLAN Configuration...............................39 107 9.2.3.3 TCP Configuration.................................39 108 9.2.3.4 Other Encapsulation Configuration.................39 109 9.2.4 Security Configuration..............................39 111 10. Security Considerations...............................40 112 10.1 IPsec................................................40 113 10.2 IS-IS Security.......................................41 115 11. IANA Considerations...................................42 116 11.1 Port Assignments.....................................42 117 11.2 Multicast Address Assignments........................42 118 11.3 Encapsulation Method Support Indication..............43 120 Normative References......................................45 121 Informative References....................................47 123 Appendix A: IP Security Choice............................50 125 Acknowledgements..........................................51 126 Authors' Addresses........................................52 128 1. Introduction 130 TRILL switches (also know as RBridges) are devices that implement the 131 IETF TRILL protocol [RFC6325] [RFC7177] [RFC7780]. TRILL provides 132 transparent forwarding of frames within an arbitrary network 133 topology, using least cost paths for unicast traffic. It supports 134 VLANs and Fine Grained Labels [RFC7172] as well as multipathing of 135 unicast and multi-destination traffic. It uses IS-IS [IS-IS] 136 [RFC7176] link state routing and transmits data using a TRILL header 137 that has a hop count. 139 RBridge ports can communicate with each other over various protocols, 140 such as Ethernet [RFC6325], pseudowires [RFC7173], or PPP [RFC6361]. 142 This document specifies transmission of encapsulated IS-IS and TRILL 143 data over IP (v4 or v6 [RFC8200]) transport. so as to use an IP 144 network as a TRILL link in a unified TRILL campus. One mandatory to 145 implement UDP based encapsulation is specified along with two 146 optional to implement encapsulations, one using VXLAN (which is based 147 on UDP), and one using TCP. Provision is made to negotiate other 148 encapsulations. TRILL over IP transport allows RBridges with IP 149 connectivity to form a single TRILL campus, or multiple TRILL 150 networks to be connected as a single TRILL campus via a TRILL over IP 151 transport backbone. 153 The protocol specified in this document connects RBridge ports using 154 transport over IP transport in such a way that the ports with mutual 155 IP connectivity appear to TRILL to be connected by a single multi- 156 access link. If a set of more than two RBridge ports are connected 157 via a single TRILL over IP transport link, each RBridge port in the 158 set can communicate with every other RBridge port in the set. 160 To support the scenarios where RBridges are connected via IP paths 161 (including those over the public Internet) that are not under the 162 same administrative control as the TRILL campus and/or not physically 163 secure, this document specifies the use of IPsec [RFC4301] 164 Encapsulating Security Protocol (ESP) [RFC4303] as the mandatory to 165 implement protocol for security (see appendix A). 167 To dynamically select a mutually supported TRILL over IP transport 168 encapsulation, normally one with good fast path hardware support, a 169 method is provided for agreement between adjacent TRILL switch ports 170 as to what encapsulation to use. Alternatively, where a common 171 encapsulation is known to be fully supported by the TRILL switch 172 ports on a link, those ports can simply be configured to always use 173 that encapsulation. 175 This document updates [RFC7177] and [RFC7178] as described in 176 Sections 5 and 11.3 by making adjacency between TRILL over IP 177 transport ports dependent on having a fully supported method of 178 encapsulation in common and by redefining an interval of RBridge 179 Channel protocol numbers to indicate link technology specific 180 capabilities, in this case encapsulation methods supported for TRILL 181 over IP transport. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 187 "OPTIONAL" in this document are to be interpreted as described in BCP 188 14 [RFC2119] [RFC8174] when, and only when, they appear in all 189 capitals, as shown here. 191 The following terms and acronyms have the meaning indicated: 193 DEI - Drop Eligibility Indicator. Part of QoS, see Section 4.3. 195 DRB - Designated RBridge. The RBridge (TRILL switch) elected to be in 196 charge of certain aspects of a TRILL link if that link is not 197 configured as a point-to-point link [RFC6325] [RFC7177]. 199 ENCAP Hdr - See "encapsulation header". 201 encapsulation header - Protocol header or headers appearing between 202 the IP Header and the TRILL Header. See Sections 4 and 5. 204 ESP - IPsec Encapsulating Security Protocol [RFC4303]. 206 FGL - Fine Grained Label [RFC7172]. 208 Hdr - Used herein as an abbreviation for "Header". 210 link - In TRILL, a link connects TRILL ports and is transparent to 211 TRILL data and IS-IS messages. It may, for example, be a 212 bridged LAN. 214 HKDF - Hash based Key Derivation Function [RFC5869]. 216 MTU - Maximum Transmission Unit. 218 PDU - Protocol Data Unit. 220 QoS - Quality of Service. 222 RBridge - Routing Bridge. An alternative term for a TRILL switch. 223 [RFC6325] [RFC7780] 225 SNPA - Sub-Network Point of Attachment [IS-IS]. 227 Sz - The campus wide MTU [RFC6325] [RFC7780]. 229 TMCE - Traffic-Managed Controlled Environment, see Section 8.1.1. 231 TRILL - Transparent Interconnection of Lots of Links or Tunneled 232 Routing in the Link Layer. The protocol specified in [RFC6325], 234 [RFC7177], [RFC7780], and related RFCs. 236 TRILL switch - A device implementing the TRILL protocol. 238 VNI - Virtual Network Identifier. In Virtual eXtensible Local Area 239 Network (VXLAN) [RFC7348], the VXLAN Network Identifier. 241 3. Use Cases for TRILL over IP Transport 243 This section introduces two application scenarios (a remote office 244 scenario and an IP backbone scenario) which cover typical situations 245 where network administrators may choose to use TRILL over an IP 246 network to connect TRILL switches. 248 3.1 Remote Office Scenario 250 In the Remote Office Scenario, as shown in the example below, a 251 remote TRILL network is connected to a TRILL campus across a multihop 252 IP network, such as the public Internet. The TRILL network in the 253 remote office becomes a part of the TRILL campus, and nodes in the 254 remote office can be attached to the same VLANs or Fine Grained 255 Labels [RFC7172] as local campus nodes. In many cases, a remote 256 office may be attached to the TRILL campus by a single pair of 257 RBridges, one on the campus end, and the other in the remote office. 259 In this use case, the TRILL over IP transport link will often cross 260 logical and physical IP networks that do not support TRILL, are not 261 under the same administrative control as the TRILL campus, and whose 262 level of physical security is unknown. 264 /---------------\ /---------------\ 265 | Remote | | Remote | 266 | Office | | Office | 267 | | | | 268 | +-------+ | | +-------+ | 269 \---|RBridge|---/ \---|RBridge|---/ 270 +-----+-+ +-+-----+ 271 | | 272 /---------------------------------------------\ 273 | | The Internet | | 274 \---------------------------------------------/ 275 | | 276 +-+-----+ +-----+-+ 277 /----|RBridge|---------------|RBridge|----\ 278 | +-------+ +-------+ | 279 | | 280 | Main TRILL Campus | 281 \-----------------------------------------/ 283 3.2 IP Backbone Scenario 285 In the IP Backbone Scenario, as shown in the example below, TRILL 286 over IP transport is used to connect a number of TRILL networks to 287 form a single TRILL campus. For example, a TRILL over IP transport 288 backbone could be used to connect multiple TRILL networks on 289 different floors of a large building, or to connect TRILL networks in 290 separate buildings of a multi-building site. In this use case, there 291 may often be several TRILL switches on a single TRILL over IP 292 transport link, and the IP link(s) used by TRILL over IP transport 293 are typically under the same administrative control as the rest of 294 the TRILL campus and might or might not be physically secure. 296 /---------------------------------------------\ 297 | Unified TRILL Campus | 298 | | 299 | TRILL Over IP Transport Backbone | 300 | -----+------------+------------+----- | 301 | | | | | 302 | +---+---+ +---+---+ +---+---+ | 303 | |RBridge| |RBridge| |RBridge| | 304 | +---+---+ +---+---+ +---+---+ | 305 | | | | | 306 | ---+--- ---+--- ---+--- | 307 | TRILL Local Links or Networks | 308 | | 309 \---------------------------------------------/ 311 3.3 Important Properties of the Scenarios 313 There are a number of differences between the above two application 314 scenarios, some of which drive features of this specification. These 315 differences are especially pertinent to the security requirements of 316 the solution, how multicast data frames are handled, and how the 317 TRILL switch ports discover each other. 319 3.3.1 Security Requirements 321 In the IP Backbone Scenario, TRILL over IP transport is used between 322 a number of RBridge ports, on a network link that is in the same 323 administrative control as the remainder of the TRILL campus. While it 324 is desirable in this scenario to prevent the association of 325 unauthorized RBridges, this can be accomplished using existing IS-IS 326 security mechanisms. The integrity of TRILL routing and the TRILL 327 campus depend on protection of RBridges from compromise; if similar 328 security can be extended to the links between RBridges, there may be 329 no need to protect the data traffic, beyond any protections that are 330 already in place on the local network. 332 In the Remote Office Scenario, TRILL over IP transport may run over a 333 network that is not under the same administrative control as the 334 TRILL network. It may appear to nodes on the network that they are 335 sending traffic locally, while that traffic is actually being sent, 336 in an IP tunnel, over the public Internet. It is necessary in this 337 scenario to protect the integrity and confidentiality of user 338 traffic, as well as ensuring that no unauthorized RBridges can gain 339 access to the RBridge campus. The issues of protecting integrity and 340 confidentiality of user traffic can be addressed by using IPsec for 341 both IS-IS and TRILL Data packets between RBridges in this scenario. 343 3.3.2 Multicast Handling 345 In the IP Backbone scenario, native IP multicast may be supported on 346 the TRILL over IP transport link. If so, it can be used to send IS-IS 347 PDUs and multicast data packets, as discussed later in this document. 348 Alternatively, multi-destination packets can be transmitted serially 349 by IP unicast to the intended recipients. 351 In the Remote Office Scenario there will often be only one pair of 352 RBridges connecting a given site and, even when multiple RBridges are 353 used to connect a Remote Office to the TRILL campus, the intervening 354 network may not provide reliable (or any) multicast connectivity. 355 Issues such as complex key management also make it more difficult to 356 provide strong data integrity and confidentiality protections for 357 multicast traffic. For all of these reasons, the connections between 358 local and remote RBridges will commonly be treated like point-to- 359 point links, and IS-IS control messages and multicast data packets 360 that are transmitted between the Remote Office and the TRILL campus 361 will need to be serially transmitted by IP unicast, as discussed 362 later in this document. 364 3.3.3 Neighbor Discovery 366 In the IP Backbone Scenario, where IP multicast is supported, TRILL 367 switches that use TRILL over IP transport can use the normal IS-IS 368 Hello mechanisms to discover the existence of other TRILL switches on 369 the link [RFC7177] and to establish authenticated communication with 370 them. 372 In the Remote Office Scenario, an IPsec session will usually need to 373 be established before IS-IS traffic can be exchanged, as discussed 374 below. In this case, one end will need to be configured to establish 375 a IPsec session with the other. This will typically be accomplished 376 by configuring the TRILL switch or a border device at a Remote Office 377 to initiate an IPsec session and subsequent TRILL exchanges with a 378 TRILL over IP-enabled RBridge attached to the TRILL campus. 380 4. TRILL Packet Formats 382 To support TRILL two types of packets are transmitted between TRILL 383 switches: IS-IS packets and TRILL Data packets. 385 Section 4.1 describes general packet formats for TRILL data and IS-IS 386 independent of link technology. Section 4.2 specifies general TRILL 387 over IP transport packet formats including IPsec ESP encapsulation. 388 Section 4.3 provides QoS Considerations. Section 4.4 discusses 389 broadcast links and multicast packets. And Section 4.5 provides IS-IS 390 Hello SubNetwork Point of Attachment (SNPA) considerations for IP 391 transport. 393 4.1 General Packet Formats 395 The on-the-wire form of a TRILL Data packet in transit between two 396 neighboring TRILL switch ports is as shown below: 398 +----------------+----------+----------------+-----------+ 399 | Link Header | TRILL | Native Frame | Link | 400 | for TRILL Data | Header | Payload | Trailer | 401 +----------------+----------+----------------+-----------+ 403 The encapsulated Native Frame Payload is similar to an Ethernet frame 404 with a VLAN tag or Fine Grained Label [RFC7172] but with no trailing 405 Frame Check Sequence (FCS). 407 IS-IS packets are formatted on-the-wire as follows: 409 +-----------------+---------------+-----------+ 410 | Link Header | IS-IS | Link | 411 | for L2 IS-IS | Payload | Trailer | 412 +-----------------+---------------+-----------+ 414 The Link Header and Link Trailer in these formats depend on the 415 specific link technology. The Link Header contains one or more fields 416 that distinguish IS-IS from TRILL Data. For example, over Ethernet, 417 the Link Header for TRILL Data ends with the TRILL Ethertype while 418 the Link Header for IS-IS ends with the L2-IS-IS Ethertype; on the 419 other hand, over PPP, there are no Ethertypes in the Link Header but 420 different PPP protocol code points are included that distinguish IS- 421 IS from TRILL Data. 423 4.2 General TRILL Over IP Packet Formats 425 In TRILL over IP transport, we use an IP (v4 or v6) header followed 426 by an encapsulation header, such as UDP, as the link header. (On the 427 wire, the IP header will normally be preceded by the lower layer 428 header of a protocol that is carrying IP; however, this does not 429 concern us at the level of this document.) 431 There are multiple IP based encapsulations usable for TRILL over IP 432 transport that differ in exactly what appears after the IP header and 433 before the TRILL Header or the TRILL IS-IS Payload. Those 434 encapsulations specified in this document are further detailed in 435 Section 5. In the general specification below, those encapsulation 436 fields will be represented as "ENCAP Hdr". 438 4.2.1 Without Security 440 When TRILL over IP transport link security is not being used, a TRILL 441 over IP transport packet on the wire looks like one of the following: 443 TRILL Data Packet 444 +---------+-----------+---------+------------------+ 445 | IP | ENCAP Hdr | TRILL | Native frame | 446 | Header | for Data | Header | Payload | 447 +---------+-----------+---------+------------------+ 448 <--- link header ----> 450 L2 IS-IS Packet 451 +---------+-----------+-----------------+ 452 | IP | ENCAP Hdr | L2 IS-IS | 453 | Header | for IS-IS | Payload | 454 +---------+-----------+-----------------+ 455 <--- link header ----> 457 As discussed above and further specified in Section 5, the ENCAP Hdr 458 indicates whether the packet is TRILL Data or IS-IS. 460 4.2.2 With Security 462 The mandatory to implement TRILL over IP transport link security is 463 IPsec Encapsulating Security Protocol (ESP) in tunnel mode [RFC4303] 464 (see Appendix A). Since TRILL over IP transport always starts with an 465 IP Header (on the wire this appears after any lower layer header that 466 might be required), the modifications for IPsec are independent of 467 the TRILL over IP transport ENCAP Hdr that occurs after that IP 468 Header. ENCAP headers specified in this document are UDP, VXLAN, and 469 TCP. The resulting packet formats are as follows for IPv4 and IPv6: 471 With IPv4: 472 +-------------+-----+--------------+-----------+-----------+ 473 | new IP Hdr | ESP | TRILL IP Hdr | ENCAP Hdr | ESP |ESP| 474 |(any options)| Hdr | (any options)| + payload |Trailer|ICV| 475 +-------------+-----+--------------+-----------+-----------+ 476 |<---------- encryption ---------->| 477 |<-------------- integrity ------------->| 479 With IPv6: 480 +------+-------+-----+------+--------+-----------+-------+---+ 481 | new |new ext| ESP | orig |orig ext| ENCAP Hdr | ESP |ESP| 482 |IP Hdr| Hdrs | Hdr |IP Hdr| Hdrs | + payload |Trailer|ICV| 483 +------+-------+-----+------+--------+-----------+-------+---+ 484 |<----------- encryption ---------->| 485 |<--------------- integrity ------------->| 487 As shown above, IP Header options are considered part of the IPv4 488 Header but are extensions ("ext") of the IPv6 Header. For further 489 information on the IPsec ESP Hdr, Trailer, and ICV, see [RFC4303] and 490 Section 7 below. "ENCAP Hdr + payload" is the encapsulation header 491 (Section 5) and TRILL data or the encapsulation header and IS-IS 492 payload, that is, the material after the IP Header in the diagram in 493 Section 4.2.1. 495 This architecture permits the ESP tunnel end point to be separated 496 from the TRILL over IP transport RBridge port (see, for example, 497 Section 1.1.3 of [RFC7296]). 499 4.3 QoS Considerations 501 In IP, QoS handling is indicated by the Differentiated Services Code 502 Point (DSCP [RFC2474] [RFC3168]) in the IP Header. The former Type 503 of Service (TOS) octet in the IPv4 Header and the Traffic Class octet 504 in the IPv6 Header have been divided as shown in the following 505 diagram adapted from [RFC3168]. (TRILL support of ECN is beyond the 506 scope of this document. See [TRILLECN].) 508 0 1 2 3 4 5 6 7 509 +-----+-----+-----+-----+-----+-----+-----+-----+ 510 | DSCP FIELD | ECN FIELD | 511 +-----+-----+-----+-----+-----+-----+-----+-----+ 513 DSCP: Differentiated Services Codepoint 514 ECN: Explicit Congestion Notification 516 Although recommendations are provided below for mapping from TRILL 517 priority to DSCP, behavior for various DSCP values on the general 518 Internet is not predictable. The default mapping below is appropriate 519 where the TRILL campus is under the control of a network manager or 520 consists of islands connected by an Internet Service Provider where 521 that manager and/or provider support the DSCPs below to provide the 522 QoS indicated. 524 Within a TRILL switch, QoS is determined (1) by configuration for IS- 525 IS packets and (2) by a three bit (0 through 7) priority field and a 526 Drop Eligibility Indicator (DEI) bit (see Sections 8.2 and 7 of 527 [RFC7780]) for TRILL Data packets. (Typically IS-IS is configured to 528 use one of the highest two priorities depending on the particular IS- 529 IS PDU.) The QoS affects queuing behavior at TRILL switch ports and 530 may be encoded into the link header, particularly if there could be 531 priority sensitive devices within the link. For example, if the link 532 is Ethernet and thus might be a bridged LAN, QoS is commonly encoded 533 into an Outer.VLAN tag's priority and DEI fields. 535 TRILL over IP transport implementations MUST support setting the DSCP 536 value in the outer IP Header of TRILL packets they send by mapping 537 the TRILL priority and DEI to the DSCP. They MAY support, for a TRILL 538 Data packet where the native frame payload is an IP packet, mapping 539 the DSCP in this inner IP packet to the DSCP in the outer IP Header 540 with the default for that mapping being to copy the DSCP without 541 change. 543 The default TRILL priority and DEI to DSCP mapping, which may be 544 configured per TRILL over IP transport port, is an follows. Note that 545 the DEI value does not affect the default mapping and, to provide a 546 potentially lower priority service than the default priority 0, 547 priority 1 is considered lower priority than 0. So the priority 548 sequence from lower to higher priority is 1, 0, 2, 3, 4, 5, 6, 7, as 549 it is in [802.1Q]. 551 TRILL Priority DEI DSCP Field (Binary/decimal) 552 -------------- --- ----------------------------- 553 0 0/1 000000 / 0 554 1 0/1 -TBD0- / TBD0 555 2 0/1 010000 / 16 556 3 0/1 011000 / 24 557 4 0/1 100000 / 32 558 5 0/1 101000 / 40 559 6 0/1 110000 / 48 560 7 0/1 111000 / 56 562 RFC Editor: Please change the TBD0 DSCP for TRILL Priority 1 in the 563 above table and below text to the DSCP value that is recommended for 564 the Lower Effort PHB (LE PHB) by draft-ietf-tsvwg-le-phb [LEphb] 565 draft when that draft is published as an RFC and delete this note. 567 The above all follow the recommended DSCP values from [RFC2474] 568 except for the placing of priority 1 below priority 0, as specified 569 in [802.1Q], and for the DSCP value of TBD0 binary for low effort as 570 recommended in [LEphb]. 572 4.4 Broadcast Links and Multicast Packets 574 TRILL supports broadcast links. These are links to which more than 575 two TRILL switch ports can be attached and where a packet can be 576 broadcast or multicast from a port to all or a subset of the other 577 ports on the link as well as unicast to a specific other port on the 578 link. 580 As specified in [RFC6325], TRILL Data packets being forwarded between 581 TRILL switches can be unicast on a link to a specific TRILL switch 582 port or multicast on a link to all TRILL switch ports. TRILL IS-IS 583 packets are always multicast to all other TRILL switches on the link 584 except for IS-IS MTU PDUs, which may be unicast [RFC7177]. This 585 distinction is not significant if the link is inherently point-to- 586 point, such as a PPP link; however, on a broadcast link there will be 587 a packet outer link address that will be unicast or multicast as 588 appropriate. For example, over Ethernet links, the Ethernet multicast 589 addresses All-RBridges and All-IS-IS-RBridges are used for 590 multicasting TRILL Data and IS-IS respectively. For details on TRILL 591 over IP transport handling of multicast, see Section 6. 593 4.5 TRILL Over IP Transport IS-IS SubNetwork Point of Attachment 595 IS-IS routers, including TRILL switches, establish adjacency through 596 the exchange of Hello PDUs on a link [RFC7176] [RFC7177]. The Hellos 597 transmitted out of a port indicate what neighbor ports that port can 598 see on the link by listing what IS-IS refers to as the neighbor 599 port's SubNetwork Point of Attachment (SNPA). (For an Ethernet link, 600 which may be a bridged network, the SNPA is the port MAC address.) 602 In IS-IS Hello PDUs on a TRILL over IP transport link, the IP 603 addresses of the IP ports connected to that link are their actual 604 SNPA (SubNetwork Point of Attachment [IS-IS]) addresses and, for 605 IPv6, the 16-byte IPv6 address is used as the SNPA; however, for ease 606 in re-using code designed for the common case of 48-bit SNPAs, in 607 TRILL over IPv4 a 48-bit synthetic SNPA that looks like a unicast MAC 608 address is constructed for use in the SNPA field of TRILL Neighbor 609 TLVs [RFC7176] [RFC7177] in such Hellos. This synthetic SNPA is 610 derived from the port IPv4 address is as follows: 612 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 614 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 615 | 0xFE | 0x00 | 616 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 617 | IPv4 upper half | 618 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 619 | IPv4 lower half | 620 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 622 This synthetic SNPA (MAC) address has the local (0x02) bit on in the 623 first byte and so cannot conflict with any globally unique 48-bit 624 Ethernet MAC. However, when TRILL operates on an IP link as specified 625 in this document, TRILL sees only IP ports on that link, not MAC 626 stations, even if the TRILL over IP transport link is being carried 627 over Ethernet. Therefore conflicts on the link between a real MAC 628 address and a TRILL over IP transport synthetic SNPA (MAC) address 629 are impossible. 631 5. TRILL over IP Transport Encapsulation Formats 633 There are a variety of TRILL over IP transport encapsulation formats 634 possible. There are two levels of support for an encapsulation by a 635 TRILL over IP transport port as follows: 637 limited support - Limited support for an encapsulation enables the 638 exchange of TRILL IS-IS Hellos and other adjacency related 639 PDUs, inluding the information needed to determine what, if 640 any, fully supported encapsulation the port has in common 641 with other ports. 643 full support - Full support by a TRILL over IP transport port for 644 an encapsulation means the port enables use of that 645 encapsulation for data and all control messages if the 646 encapsulation is negotiated with another such port on the 647 link. 649 By default TRILL over IP transport adopts a hybrid encapsulation 650 approach. All TRILL over IP transport ports MUST implement limited 651 support for native encapsulation (see Section 5.4). Although native 652 encapsulation does not typically have good fast path support, as a 653 lowest common denominator it can be used for low bandwidth control 654 traffic to determine a preferred encapsulation with better 655 performance. In particular, by default, all TRILL IS-IS Hellos are 656 sent using native encapsulation and those Hellos are used to 657 determine the fully supported encapsulation used for all TRILL Data 658 packets and all other TRILL IS-IS PDUs (with the exception of IS-IS 659 MTU-probe and MTU-ack PDUs used to establish adjacency which also use 660 native encapsulation by default). 662 Alternatively, the network operator can pre-configure a TRILL over IP 663 transport port to always use a particular encapsulation chosen for 664 their particular network's needs and port capabilities. That 665 encapsulation is then used for all TRILL Data and IS-IS packets, 666 including Hellos, on ports so configured. This is expected to 667 frequently be the case for a managed campus of TRILL switches. 669 Section 5.1 discusses general considerations for the TRILL over IP 670 transport encapsulation format. Section 5.2 discusses encapsulation 671 agreement. Section 5.3 discusses broadcast link encapsulation 672 considerations. Section 5.4 and subsequent subsections discuss 673 particular encapsulations. 675 5.1 Encapsulation Considerations 677 An encapsulation must provide a method to distinguish TRILL Data 678 packets and TRILL IS-IS packets or it is not useful for TRILL. In 679 addition, the following criteria can be helpful is choosing between 680 different encapsulations for full support: 682 a) Fast path support - For most applications, it is highly desirable 683 to be able to encapsulate/decapsulate TRILL over IP transport at 684 line speed. Thus a format where existing or anticipated fast path 685 hardware can do that is best. This is commonly the dominant 686 consideration. 688 b) Ease of multi-pathing - The IP path between TRILL over IP 689 transport ports may include equal cost multipath routes internal 690 to the IP link so a method of encapsulation that provides variable 691 fields available for fast path hardware multi-pathing is 692 preferred. 694 c) Robust fragmentation and re-assembly - Fragmentation should 695 generally be avoided; however, the MTU of the IP link may require 696 fragmentation in which case an encapsulation with robust 697 fragmentation and re-assembly is important. There are known 698 problems with IPv4 fragmentation and re-assembly [RFC6864] which 699 generally do not apply to IPv6. Some encapsulations can fix these 700 problems but the encapsulations specified in this document do not. 701 Therefore, if fragmentation is anticipated with the encapsulations 702 specified in this document, the use of IPv6 is RECOMMENDED. 704 d) Checksum strength - Depending on the particular circumstances of 705 the TRILL over IP transport link, a checksum provided by the 706 encapsulation may be a significant factor. Use of IPsec can also 707 provide a strong integrity check. 709 5.2 Encapsulation Agreement 711 TRILL Hellos sent out of a TRILL over IP transport port indicate the 712 encapsulations for which that port is offering full support through a 713 mechanism initially specified in [RFC7178] and [RFC7176] that is 714 hereby extended. Specifically, RBridge Channel Protocol numbers 715 0xFD0 through 0xFF7 are redefined to be link technology dependent 716 flags that, for TRILL over IP transport, indicate support for 717 different encapsulations, allowing support for up to 40 718 encapsulations to be specified. Full support for an encapsulation is 719 indicated in the Hello PDU using the same mechanism by which support 720 for an RBridge Channel protocol is indicated (see also section 11.3). 721 Such full support indicates willingness to use that encapsulation for 722 TRILL Data and TRILL IS-IS packets (although TRILL IS-IS Hellos are 723 still sent in native encapsulation by default unless the port is 724 configured to always use some other encapsulation). 726 If, in a TRILL Hello on a TRILL over IP transport link, full support 727 is not indicated for any encapsulation, then the port from which it 728 was sent is assumed to fully support native encapsulation only (see 729 Section 5.4). 731 An adjacency can be formed between two TRILL over IP transport ports 732 if the intersection of the sets of encapsulation methods they fully 733 support is not null. If that intersection is null, then no adjacency 734 is formed. In particular, for a TRILL over IP transport link, the 735 adjacency state machine MUST NOT advance to the Report state unless 736 the ports share a fully supported encapsulation [RFC7177]. If no such 737 encapsulation is shared, the adjacency state machine remains in the 738 state from which it would otherwise have transitioned to the Report 739 state when an event occurs that would have transitioned it to the 740 Report state. 742 If a TRILL over IP transport port is using an encapsulation different 743 from that in which Hellos are being exchanged, it is RECOMMENDED that 744 BFD [RFC7175] or some other protocol that confirms adjacency using 745 TRILL Data packets be used. As provided in [RFC7177], adjacency is 746 not actually obtained when such a confirmatory protocol is in use 747 until that protocol succeeds. 749 If any TRILL over IP transport packet, other than an IS-IS Hello or 750 MTU PDU in native encapsulation, is received in an encapsulation for 751 which full support is not being indicated by the receiver, that 752 packet MUST be discarded (see Section 5.3). 754 If there are two or more fully supported encapsulations in common 755 between two adjacent ports for unicast or across all of the set of 756 adjacent ports for multicast, a transmitter is free to choose 757 whichever of those encapsulations it wishes to use. Thus 758 transmissions between adjacent ports P1 and P2 could use different 759 encapsulations depending on which port is transmitting and which is 760 receiving, that is to say, encapsulation usage could be asymmetric. 762 It is expected to be the normal case in a well-configured network 763 that all the TRILL over IP transport ports connected to an IP link 764 (i.e., an IP network) that are intended to communicate with each 765 other fully support the same encapsulation(s). 767 5.3 Broadcast Link Encapsulation Considerations 769 To properly handle TRILL protocol packets on a TRILL over IP 770 transport link in the general case, either native IP multicast mode 771 is used on that link or multicast must be simulated using serial IP 772 unicast, as discussed in Section 6. (Of course, if the IP link 773 happens to actually be point-to-point no special provision is needed 774 for handling IP multicast addressed packets.) 775 It is possible for the Hellos from a TRILL over IP transport port P1 776 to establish adjacency with multiple other TRILL over IP transport 777 ports (P2, P3, ...) on a broadcast link. In a well-configured network 778 one would expect all of the IP ports involved to fully support the 779 same encapsulation; but, for example, if P1 fully supports multiple 780 encapsulations, it is possible that P2 and P3, do not have an 781 encapsulation in common that is also supported by P1. [IS-IS] can 782 handle such non-transitive adjacencies that are reported as specified 783 in [RFC7177]. This is generally done, albeit with reduced efficiency, 784 by forwarding through the designated RBridge (router) on the link. 785 Thus it is RECOMENDED that all TRILL over IP transport ports on an IP 786 link be configured to fully support one encapsulation in common that 787 has good fast path support. 789 If serial IP unicast is being used by P1, it MAY use different 790 encapsulations for different transmissions. 792 If multiple IP multicast encapsulations are available for use by P1, 793 it can send one transmission per encapsulation method by which it has 794 a disjoint set of adjacencies on the link. If the transmitting port 795 has adjacencies with overlapping sets of ports that are adjacent 796 using different encapsulations, use of native multicast with 797 different encapsulations may result in packet duplication. It would 798 always be possible to use native IP multicast for one encapsulation 799 or multiple encapsulations supported by non-overlapping sets of 800 receiving ports for which the transmitting port has adjacencies, 801 perhaps the encapsulation(s) for which it has the largest number of 802 adjacencies, and serially unicast to other receivers. These 803 considerations are the reason that a TRILL over IP transport port 804 MUST discard any packet received with an encapsulation for which it 805 has not established an adjacency with the transmitter. Otherwise, 806 packets might be further duplicated. 808 5.4 Native Encapsulation 810 The mandatory to implement "native encapsulation" format of a TRILL 811 over IP transport packet, when used without security, is TRILL over 812 UDP as shown below. This provides simple and direct access by TRILL 813 to the native datagram service of IP. 815 +----------+--------+-----------------------+ 816 | IP | UDP | TRILL | 817 | Header | Header | Payload | 818 +----------+--------+-----------------------+ 820 Where the UDP Header is as follows: 822 0 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Source Port = Entropy | Destination Port | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | UDP Length | UDP Checksum | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | TRILL Payload ... 831 Source Port - see Section 8.3. 833 Destination Port - indicates TRILL Data or IS-IS, see Section 834 11.1. 836 UDP Length - as specified in [RFC0768]. 838 UDP Checksum - as specified in [RFC0768]. See discussion below. 840 The TRILL Payload starts with the TRILL Header (not including the 841 TRILL Ethertype) for TRILL Data packets and starts with the 0x83 842 Intradomain Routeing Protocol Discriminator byte (thus not including 843 the L2-IS-IS Ethertype) for TRILL IS-IS packets. 845 Note that if the mandatory to implement TRILL over IP transport 846 security is in use, then traffic is not actually over UDP but rather 847 over IPsec ESP. The authentication / integrity services provided 848 protect against the processing of traffic by the wrong receiver even 849 when the destination IP address / port is corrupted or the like and 850 the confidentiality services provided by IPsec protect against 851 compromise even if a receiver attempts to process packets not 852 originally addressed to it. 854 5.4.1 IPv4 UDP Checksum Considerations 856 For UDP in IPv4, when a non-zero UDP checksum is used, the UDP 857 checksum MUST be processed as specified in [RFC0768] and [RFC1122] 858 for both transmit and receive. The IPv4 header includes a checksum 859 that protects against misdelivery of the packet due to corruption of 860 IP addresses. The UDP checksum potentially provides protection 861 against corruption of the UDP header and TRILL payload. Disabling 862 the use of checksums is a deployment consideration that should take 863 into account the risk and effects of packet corruption. 865 When a port receives a TRILL over IP transport packet, the UDP 866 checksum field MUST be processed. If the UDP checksum is non-zero, 867 the port MUST verify the checksum before accepting the packet. By 868 default, a TRILL over IP transport port SHOULD accept UDP packets 869 with a zero checksum. A node MAY be configured to disallow zero 870 checksums per [RFC1122]; this may be done selectively, for instance, 871 disallowing zero checksums from certain adjacent ports that are known 872 to be sending over paths subject to packet corruption. If 873 verification of a non-zero checksum fails, a port lacks the 874 capability to verify a non-zero checksum, or a packet with a zero 875 checksum was received and the port is configured to disallow, the 876 packet MUST be dropped and an event MAY be logged. 878 5.4.2 IPv6 UDP Checksum Considerations 880 For UDP in IPv6, the UDP checksum MUST be processed as specified in 881 [RFC0768] and [RFC8200] for both transmit and receive. 883 When UDP is used over IPv6, the UDP checksum is relied upon to 884 protect both the IPv6 and UDP headers from corruption. As such, a 885 default TRILL over IP transport port MUST perform UDP checksum; a 886 traffic-managed controlled environment (TMCE) TRILL over IP transport 887 port MAY be configured with UDP zero-checksum mode if the TMCE or a 888 set of closely cooperating TMCEs (such as by network operators who 889 have agreed to work together in order to jointly provide specific 890 services) meet at least one of the following conditions: 892 a. It is known (perhaps through knowledge of equipment types and 893 lower-layer checks) that packet corruption is exceptionally 894 unlikely and where the operator is willing to take the risk of 895 undetected packet corruption. 897 b. It is judged through observational measurements (perhaps of 898 historic or current traffic flows that use a non-zero checksum) 899 that the level of packet corruption is tolerably low and where 900 the operator is willing to take the risk of undetected packet 901 corruption. 903 c. Carrying applications that are tolerant of misdelivered or 904 corrupted packets (perhaps through higher-layer checksum, 905 validation, and retransmission or transmission redundancy) 906 where the operator is willing to rely on the applications using 907 the tunnel to survive any corrupt packets. 909 The following requirements apply to a TMCE TRILL over IP transport 910 port that uses UDP zero-checksum mode: 912 a. Use of the UDP checksum MUST be the default configuration of 913 all IPv6 TRILL over IP transport ports. 915 b. The port implementation MUST comply with all requirements 916 specified in Section 4 of [RFC6936] and with requirement 1 917 specified in Section 5 of [RFC6936]. 919 c. A receiving TRILL over IP transport port SHOULD only allow the 920 use of UDP zero checksum mode for IPv6 that is sent to one of 921 the two TRILL over IP UDP Destination Port numbers (see Section 922 11.1). The motivation for this requirement is possible 923 corruption of the UDP Destination Port, which may cause packet 924 delivery to the wrong UDP port. If that other UDP port 925 requires the UDP checksum, the misdelivered packet will be 926 discarded. 928 d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 only 929 be enabled for TRILL over IP transport ports with a configured 930 set of possible adjacencies. Because TRILL data is discarded 931 unless it is received from a source address with which an 932 adjacency exists, the receiving TRILL over IP transport port 933 will check the source IPv6 address and MUST check that the 934 destination IPv6 address is appropriate if UDP zero-checksum is 935 being used and discard any packet for which these checks fails. 937 e. This document assumes there are no middleboxes in the path and 938 thus does not cover restrictions on such middleboxes. Middlebox 939 support is beyond the scope of this document. 941 f. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP 942 checksums from "escaping" to the general Internet. 944 g. IPv6 traffic with zero UDP checksums MUST be actively monitored 945 for errors by the network operator. For example, the operator 946 may monitor Ethernet-layer packet error rates. 948 h. If a packet with a non-zero checksum is received, the checksum 949 MUST be verified before accepting the packet regardless of port 950 configuration to use UDP zero-checksum mode. 952 The above requirements do not change either the requirements 953 specified in [RFC8200] or the requirements specified in [RFC6936]. 955 The requirements to check the source and destination IPv6 addresses 956 provide some mitigation for the absence of UDP checksum coverage of 957 the IPv6 header. A TMCE that satisfies at least one of three 958 conditions listed at the beginning of this section provides 959 additional assurance. 961 TRILL over IP/UDP is suitable for transmission over lower layers in 962 TMCEs that are allowed by the exceptions stated above. The rate of 963 corruption of the inner IP packet on such networks is not expected to 964 increase by comparison to TRILL traffic that is not encapsulated in 965 UDP. Typically lower layers do provide some integrity checking such 966 as the FCS (Frame Check Sequence) at the end of Ethernet packets. 967 This design is in accordance with requirements 2, 3, and 5 specified 968 in Section 5 of [RFC6936]. 970 TRILL over IP/UDP does not accumulate incorrect transport-layer state 971 as a consequence of IP/UDP header corruption. Such corruption may 972 result in either packet discard or packet forwarding but the IP/UDP 973 header is stripped at the end of each TRILL over IP transport hop 974 between RBridges so errors cannot accumulate. Active monitoring of 975 TRILL over IP/UDP traffic for errors is REQUIRED, as the occurrence 976 of errors will result in some accumulation of error information 977 outside the protocol for operational and management purposes. This 978 design is in accordance with requirement 4 specified in Section 5 of 979 [RFC6936]. 981 The remaining requirements specified in Section 5 of [RFC6936] are 982 not applicable to TRILL over IP/UDP. Requirements 6 and 7 do not 983 apply because TRILL over IP/UDP does not include a control feedback 984 mechanism. Requirements 8-10 are middlebox requirements that do not 985 apply to TRILL over IP/UDP ports and, in any case, middleboxes are 986 out of scope for this document. 988 It is worth mentioning that the use of a zero UDP checksum should 989 present the equivalent risk of undetected packet corruption when 990 sending a similar packet using underlying Layer 2 link protocols in 991 the cases where those protocols do not have a checksum. 993 In summary, a TMCE TRILL over IP/UDP is allowed to use UDP zero- 994 checksum mode for IPv6 when the conditions and requirements stated 995 above are met. Otherwise, the UDP checksum needs to be used for IPv6 996 as specified in [RFC0768] and [RFC8200]. 998 5.5 VXLAN Encapsulation 1000 VXLAN [RFC7348] IP encapsulation of TRILL looks, on the wire, like 1001 TRILL over Ethernet over VXLAN over UDP over IP. 1003 +--------+--------+--------+----------+-----------+ 1004 | IP | UDP | VXLAN | Ethernet | TRILL | 1005 | Header | Header | Header | Header | Payload | 1006 +--------+--------+--------+----------+-----------+ 1008 The outer UDP uses a destination port number indicating VXLAN and the 1009 outer UDP source port MAY be used for entropy as with native 1010 encapsulation (see Section 8.3). UDP checksum considerations are the 1011 same as in Section 5.4. 1013 The VXLAN header after the outer UDP header adds a 24-bit Virtual 1014 Network Identifier (VNI). The Ethernet header after the VXLAN header 1015 and before the TRILL header consists of source MAC address, 1016 destination MAC address, and Ethertype. The Ethertype distinguishes 1017 TRILL Data from TRILL IS-IS. The destination and source MAC addresses 1018 in this Ethernet header are not used. 1020 A TRILL over IP port using VXLAN encapsulation by default uses a VNI 1021 of 1 for TRILL IS-IS traffic and a VNI of 2 for TRILL data traffic 1022 but can be configured as described in Section 9.2.3.1 to use some 1023 other fixed VNIs or to map from VLAN/FGL to VNI for data traffic. 1025 5.6 TCP Encapsulation 1027 TCP [RFC0793] may be used for TRILL over IP transport as specified 1028 below. Use of TCP is convenient to provide congestion control (see 1029 Section 8.1) and reduced packet loss but is likely to cause 1030 substantial additional jitter and delay compared with a UDP based 1031 encapsulation. 1033 TCP supports only unicast communication. Thus, when TCP encapsulation 1034 is being used, multi-destination packets must be sent by serial 1035 unicast. Neighbor discovery cannot be done with TCP, so if discovery 1036 is to be supported at a TRILL over IP transport port (i.e., the set 1037 of potential adjacencies is not configured), Hellos must be sent with 1038 UDP native encapsulation. If a TRILL over IP transport port is 1039 configured to use TCP encapsulation for all traffic, a list of IP 1040 addresses that port might communicate with must be configured for the 1041 port (see Section 9). 1043 All packets in a particular TCP stream MUST use the same DSCP value 1044 as discussed in [RFC7657]. Therefore a TCP connection is needed per 1045 QoS to be provided between TRILL switches. Contiguous sets of 1046 priority levels MAY be mapped into a single TCP connection with a 1047 single DSCP value. Lower priority traffic MUST NOT be given 1048 preference over higher priority traffic. It is RECOMMEDED that at 1049 least two TCP connections be provided, for example one for priority 6 1050 and 7 traffic and one for priority 0 through 5 traffic, in order to 1051 insure that urgent control traffic, including control traffic related 1052 to establishing and maintaining adjacency, is not significantly 1053 delayed by lower priority traffic. 1055 TCP is a stream protocol, not a record oriented protocol, so a TRILL 1056 data packet with its header or a TRILL IS-IS packet might be split 1057 across multiple TCP packet payloads or a single TCP packet payload 1058 could include multiple TRILL packets or the like. Thus a framing 1059 mechanism is needed, as specified below, so that a received TRILL 1060 stream can be parsed into TRILL packets. 1062 In the TCP header, the source and destination port fields are as 1063 follows: 1065 Source Port - along with Source IP, Destination IP, and 1066 Destination Port, identifies a TCP flow. 1068 Destination Port - indicates TRILL Data or IS-IS, see Section 1069 11.1. 1071 TRILL packets are framed for transmission over TCP as shown below. 1073 +--------+-------- // ----+ 1074 | Length | TRILL packet | 1075 +--------+----- // -------+ 1077 Length - the length of the TRILL packet in bytes as a 2-byte 1078 unsigned integer in network order. 1080 TRILL packet - The TRILL packet within framing starts with the 1081 TRILL or the L2-IS-IS Ethertype (0x22F3 or 0x22F4). If the 1082 initial 2 bytes of the TRILL packet are not the correct 1083 Ethertype based on the Destination Port, then the receiver 1084 assumes that framing synchronization has been lost and MUST 1085 close that TCP connection. Note that the Hamming distance 1086 between these Ethertypes is 2 so that a single bit error cannot 1087 convert one into the other. 1089 The sequence of framed TRILL packets is sliced as necessary into TCP 1090 packet payloads. 1092 Depending on performance requirements, in many cases consideration 1093 should be given to tuning TCP. Methods for doing this are out of 1094 scope for this document. See [RFC7323]. 1096 5.6.1 TCP Connection Establishment 1098 If a TRILL over IP transport port is configured to always use TCP it 1099 will also be configured with a list of IP addresses and MUST try to 1100 establish a TCP connection to each of them. It also MUST accept TCP 1101 connections from each of that list of IP addresses. 1103 If a TRILL over IP port supports TCP but is using UDP for neighbor 1104 discovery and encapsulation negotiation, then it MUST try to 1105 establish a TCP connection to any adjacent port in the Report state 1106 (see [RFC7177] and Section 5.2) when TCP has been negotiated with 1107 that port. It also MUST accept TCP connections from each such 1108 adjacent port. 1110 Establishing a connection actually means to initiate TCP connections 1111 for each DSCP value that the TRILL over IP port is configured to use 1112 in TCP communication with the destination separately for TRILL Data 1113 and TRILL IS-IS as they have different destination ports, unless such 1114 a connection already exists. For example, port P1 could meet the 1115 requirements to establish a TCP connection to port P2 and find that 1116 such a connection already exists having been initiated by P2. A TCP 1117 connection can be used bi-directionally for TRILL traffic. However 1118 the timing and implementation details may be such that P1 and P2 each 1119 establish a TCP connection to the other, in which case it might be 1120 that each of those connections would be used uni-directionally for 1121 TRILL traffic. 1123 When a TCP connection is closed or reset, if the conditions are still 1124 met for that TCP port to establish that connection, it waits a 1125 configurable length of time that defaults to 80 milliseconds and 1126 tried to re-establish the connection. See Section 9.2.3.3. 1128 5.7 Other Encapsulations 1130 Additional TRILL over IP transport encapsulations may be specified in 1131 future documents and allocated a link technology specific flag bit as 1132 per Section 11.3. A primary consideration for whether it is worth the 1133 effort to specify use of an encapsulation by TRILL over IP transport 1134 is whether it has good existing or anticipated fast path support. 1136 6. Handling Multicast 1138 For UDP based encapsulations where IPsec is not in use, both IS-IS 1139 packets and multi-destination TRILL Data packets are, by default, 1140 sent to an All-RBridges IPv4 or IPv6 IP multicast address as 1141 appropriate (see Section 11.2); however, such a TRILL over IP 1142 transport port may be configured (see Section 9) to use a different 1143 multicast address or to use serial IP unicast with a list of one or 1144 more unicast IP addresses of other TRILL over IP transport ports to 1145 which multi-destination packets are sent. In the serial unicast case 1146 the outer IP header of each copy of the a TRILL Data packet sent 1147 shows an IP unicast destination address even through, for TRILL Data 1148 packets, the TRILL header has the M bit set to one to indicate multi- 1149 destination. 1151 Serial unicast configuration MUST be used if the TRILL over IP 1152 transport port (1) is connected to an IP network does not support IP 1153 multicast, (2) uses TCP based encapsulation, or (3) is using IPsec. 1154 In any case, unicast TRILL Data packets (those with the M bit in the 1155 TRILL Header set to zero) are sent by unicast IP. If a TRILL over IP 1156 transport port is configured to send all traffic secured and/or with 1157 TCP, adjacency and data flow will only be possible with IP addresses 1158 in a configured list at that port (see Section 9). 1160 Even if a TRILL over IP transport port is configured to send multi- 1161 destination packets with serial unicast, if it uses a UDP based 1162 encapsulation it MUST be prepared to receive IP multicast TRILL 1163 packets. TRILL over IP transport ports that are using multicast 1164 default to periodically transmitting appropriate IGMP (IPv4 1165 [RFC3376]) or MLD (IPv6 [RFC2710]) packets, so that the TRILL 1166 multicast IP traffic can be sent to them, but MAY be configured not 1167 to do so. 1169 There may be good reasons for configuring TRILL over IP transport 1170 ports to use serial unicast even where native IP multicast is 1171 available and could be used. Use of serial unicast provides the 1172 network manager with more precise control over adjacencies and how 1173 TRILL over IP transport links will be formed in an IP network. In 1174 some networks, unicast is more reliable than multicast. If multiple 1175 point-to-point TRILL over IP transport connections between two parts 1176 of a TRILL campus are configured, TRILL will in any case spread 1177 traffic across them, treating them as parallel links, and 1178 appropriately fail over traffic if a link fails or incorporate a new 1179 link that comes up. 1181 7. Use of IPsec and IKEv2 1183 All TRILL ports that support TRILL over IP transport MUST implement 1184 IPsec [RFC4301] and support the use of IPsec Encapsulating Security 1185 Protocol (ESP [RFC4303]) in tunnel mode to secure both IS-IS and 1186 TRILL Data packets. When IPsec is used to secure a TRILL over IP 1187 transport link and no IS-IS security is enabled, the IPsec session 1188 MUST be fully established before any IS-IS or TRILL data packets are 1189 exchanged. When there is IS-IS security [RFC5310] provided, 1190 implementers SHOULD use IS-IS security to protect IS-IS packets. 1191 However, in this case, the IPsec session still MUST be fully 1192 established before any TRILL Data packets transmission, since IS-IS 1193 security does not provide any protection for data packets, and the 1194 IPsec session SHOULD be fully established before any IS-IS packet 1195 transmission other than IS-IS Hello or MTU PDUs. 1197 All RBridges that support TRILL over IP transport MUST implement the 1198 Internet Key Exchange Protocol version 2 (IKEv2) for automated key 1199 management. 1201 7.1 Keying 1203 The following subsections discuss pairwise and group keying for TRILL 1204 over IP IPsec. 1206 7.1.1 Pairwise Keying 1208 When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that 1209 incorporates the IS-IS shared key. The pre-shared key that will be 1210 used for IKEv2 exchanges for TRILL over IP is determined as follows: 1212 HKDF-Expand-SHA256 ( IS-IS-key, 1213 "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port ) 1215 In the above "|" indicates concatenation, HKDF is as in [RFC5869], 1216 SHA256 is as in [RFC6234], and "TRILL IP" is the eight byte US ASCII 1217 [RFC0020] string indicated. "IS-IS-key" is an IS-IS key usable for 1218 IS-IS security of link local IS-IS PDUs such as Hello, CSNP, and 1219 PSNP. This SHOULD be a link scope IS-IS key. P1-System-ID and 1220 P2-System ID are the six byte System IDs of the two TRILL RBridges, 1221 and P1-Port and P2-Port are the TRILL Port IDs [RFC6325] of the ports 1222 in use on each end. System IDs are guaranteed to be unique within the 1223 TRILL campus. Both of the RBridges involved treat the larger 1224 magnitude System ID, comparing System IDs as unsigned integers, as P1 1225 and the smaller as P2 so both will derive the same key. Note that the 1226 value to which the HKDF function is applied starts with 0x54 (the 1227 ASCII code for "T") while the data to which [RFC5310] authentication 1228 is applied (an IS-IS PDU) starts with 0x83, the Interdomain Routeing 1229 Discriminator, thus, although they are both SHA256 based, they are 1230 never applied to the same value. 1232 With [RFC5310] there could be multiple keys identified with 16-bit 1233 key IDs. The key ID when an IS-IS key is in use is transmitted in an 1234 IKEv2 ID_KEY_ID identity field [RFC7296] with Identification Data 1235 length of 2 bytes (Payload Length 6 bytes). The Key ID of the IS-IS- 1236 key is used to identify the IKEv2 shared secret derived as above that 1237 is actually used. ID_KEY_ID identity field(s) of other lengths MAY 1238 occur but their use is beyond the scope of this document. 1240 The IS-IS-shared key from which the IKEv2 shared secret is derived 1241 might expire and be updated as described in [RFC5310]. The IKEv2 1242 pre-shared keys derived from an IS-IS shared key MUST expire within a 1243 lifetime no longer than the IS-IS-shared key from which they were 1244 derived. When the IKEv2 shared secret key expires, or earlier, the 1245 IKEv2 Security Association must be rekeyed using a new shared secret 1246 derived from a new IS-IS shared key. 1248 IKEv2 with certificate-based security MAY be used but details of 1249 certificate contents and use policy for this application of IKEv2 are 1250 beyond the scope of this document. 1252 7.1.2 Group Keying 1254 In the case of a TRILL over IP transport port configured as point-to- 1255 point (see Section 4.2.4.1 of [RFC6325]), there is no group keying 1256 and the pairwise keying determined as provided in Section 7.1.1 is 1257 used for multi-destination TRILL traffic, which is unicast across the 1258 link. 1260 In the case of a TRILL over IP transport port configured as broadcast 1261 but where the port is configured to use serial unicast (see Section 1262 8), there is no group keying and the pairwise keying determined as in 1263 Section 7.1.1 is used for multi-destination TRILL traffic, which is 1264 unicast across the link. 1266 The case of a TRILL over IP transport port configured as broadcast 1267 and using native multicast is beyond the scope of this document and 1268 is expected to be covered in a future document [SGKPuses]. For 1269 security as provided in this document, multicast is handled via 1270 serial unicast. 1272 7.2 Mandatory-to-Implement Algorithms 1274 All RBridges that support TRILL over IP transport MUST implement 1275 IPsec ESP [RFC4303] in tunnel mode. The implementation requirements 1276 for ESP cryptographic algorithms are as specified for IPsec. That 1277 specification is currently [RFC8221]. 1279 8. Transport Considerations 1281 This section discusses a variety of important transport 1282 considerations. NAT traversal is out of scope for this document. 1284 8.1 UDP Congestion Considerations 1286 This subsection discusses TRILL over UDP congestion considerations. 1287 These are applicable to the UDP based TRILL over IP transport 1288 encapsulation headers specified in detail in this document. Other 1289 encapsulations would likely have different congestion considerations 1290 and, in particular, the TCP encapsulation specified in Section 5.6 1291 does not need congestion control beyond that provided by TCP. 1292 Congestion considerations for additional TRILL encapsulations will be 1293 provided in the document specifying that encapsulation. 1295 One motivation for including UDP or TCP as the outermost part of a 1296 TRILL over IP encapsulation header is to improve the use of multipath 1297 such as Equal Cost Multi-Path (ECMP) in cases where traffic is to 1298 traverse routers that are able to hash on Port and IP address through 1299 addition of entropy in the source port (see Section 8.3). In many 1300 cases this may reduce the occurrence of congestion and improve usage 1301 of available network capacity. However, it is also necessary to 1302 ensure that the network, including applications that use the network, 1303 responds appropriately in more difficult cases, such as when link or 1304 equipment failures have reduced the available capacity. 1306 Section 3.1.11 of [RFC8085] discusses the congestion considerations 1307 for design and use of UDP tunnels; this is important because other 1308 flows could share the path with one or more UDP tunnels, 1309 necessitating congestion control [RFC2914] to avoid destructive 1310 interference. 1312 The default initial determination of the TRILL over IP transport 1313 encapsulation to be used is through the exchange of IS-IS Hellos. 1314 This is a low bandwidth process. Hellos are not permitted to be sent 1315 any more often than once per second, and so are very unlikely to 1316 cause congestion. Thus no additional controls are needed for Hellos 1317 even if they are sent, as is the default, over UDP. 1319 Congestion has potential impacts both on the rest of the network 1320 containing a UDP flow and on the traffic flows using the UDP 1321 encapsulation. These impacts depend upon what sort of traffic is 1322 carried in UDP, as well as the path it follows. The UDP based TRILL 1323 over IP transport encapsulations specified in this document do not 1324 provide any congestion control and are transmitted as regular UDP 1325 packets. 1327 The use of serial unicast, where the transmission of a multi- 1328 destination TRILL packet is executed as multiple unicast 1329 transmission, potentially increases link load and could thus increase 1330 congestion. Rate limiting of multi-destination traffic that is to be 1331 transmitted in this fashion should be considered. 1333 The subsections below discuss congestion for TRILL over IP transport 1334 traffic with UDP based encapsulation headers in traffic-managed 1335 controlled environments (TMCE, see [RFC8086]) and other environments. 1337 8.1.1 Within a TMCE 1339 Within a TMCE, that is, an IP network that is traffic-engineered 1340 and/or otherwise managed, for example via use of traffic rate 1341 limiters, to avoid congestion, UDP based TRILL over IP encapsulation 1342 headers are appropriate for carrying traffic that is not known to be 1343 congestion controlled. in such cases, operators of TMCE networks 1344 avoid congestion by careful provisioning of their networks, rate- 1345 limiting of user data traffic, and traffic engineering according to 1346 path capacity. 1348 When TRILL over IP transport using a UDP based encapsulation header 1349 carries traffic that is not known to be congestion controlled in a 1350 TMCE network, the traffic path MUST be entirely within that network, 1351 and measures SHOULD be taken to prevent the traffic from "escaping" 1352 the network to the general Internet. Examples of such measures are: 1354 o physical or logical isolation of the links carrying the traffic 1355 from the general Internet and 1357 o deployment of packet filters that block the UDP ports assigned 1358 for TRILL over IP transport. 1360 8.1.2 In Other Environments 1362 Where UDP based encapsulation headers are used in TRILL over IP 1363 transport in environments other than those discussed in Section 1364 8.1.1, specific congestion control mechanisms such as rate limiting 1365 are commonly needed. However, if the traffic being carried by the 1366 TRILL over IP transport link is already congestion controlled and the 1367 size and volatility of the IS-IS link state database is limited, then 1368 specific congestion control may not be needed. See [RFC8085] Section 1369 3.1.11 for further guidance. 1371 8.2 Recursive Ingress 1373 TRILL is specified to transport data to and from end stations over 1374 Ethernet and IP is frequently transported over Ethernet. Thus, an end 1375 station native data Ethernet frame "EF" might get TRILL ingressed to 1376 a TRILL(EF) packet that was subsequently sent to a next hop RBridge 1377 out a TRILL over IP transport over Ethernet port resulting in a 1378 packet on the wire of the form Ethernet(IP(TRILL(EF))). There is a 1379 risk of such a packet being re-ingressed by the same TRILL campus, 1380 due to physical or logical misconfiguration, looping around, being 1381 further re-ingressed, and so on. (Or this might occur through a cycle 1382 of TRILL different campuses.) The packet would get discarded if it 1383 got too large unless fragmentation is enabled, in which case it would 1384 just keep getting split into fragments that would continue to loop 1385 and grow and re-fragment until the path was saturated with junk and 1386 packets were being discarded due to queue overflow. The TRILL Header 1387 TTL would provide no protection because each TRILL ingress adds a new 1388 TRILL header with a new TTL. 1390 To protect against this scenario, a TRILL over IP transport port 1391 MUST, by default, test whether a TRILL packet it is about to transmit 1392 appears to be a TRILL ingress of a TRILL over IP transport over 1393 Ethernet packet. That is, is it of the form 1394 TRILL(Ethernet(IP(TRILL(...)))? If so, the default action of the 1395 TRILL over IP output port is to discard the packet rather than 1396 transmit it. However, there are cases where some level of nested 1397 ingress is desired so it MUST be possible to configure the port to 1398 allow such packets. 1400 8.3 Fat Flows 1402 For the purpose of load balancing, it is worthwhile to consider how 1403 to transport TRILL packets over any Equal Cost Multiple Paths (ECMPs) 1404 existing internal to the IP path between TRILL over IP transport 1405 ports. 1407 The ECMP election for the IP traffic could be based, for example with 1408 IPv4, on the quintuple of the outer IP header { Source IP, 1409 Destination IP, Source Port, Destination Port, and IP protocol }. 1410 Such tuples, however, could be exactly the same for all TRILL Data 1411 packets between two RBridge ports, even if there is a huge amount of 1412 data being sent between a variety of ingress and egress RBridges. One 1413 solution to this is to use the UDP Source Port as an entropy field. 1414 (This idea is also introduced in [RFC8086].) For example, for TRILL 1415 Data, this entropy field could be based on some hash of the 1416 Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.Label. These are 1417 fields from the TRILL data payload which looks like an Ethernet frame 1418 (see [RFC7172] Figures 1 and 2). 1420 8.4 MTU Considerations 1422 In TRILL each RBridge advertises in its LSP number zero the largest 1423 LSP frame it can accept (but not less than 1,470 bytes) on any of its 1424 interfaces (at least those interfaces with adjacencies to other TRILL 1425 switches in the campus) through the originatingLSPBufferSize TLV 1426 [RFC6325] [RFC7177]. The campus minimum MTU (Maximum Transmission 1427 Unit), denoted Sz, is then established by taking the minimum of this 1428 advertised MTU for all RBridges in the campus. Links that cannot 1429 support the Sz MTU are not included in the routing topology. This 1430 protects the operation of IS-IS from links that would be unable to 1431 accommodate the largest LSPs. 1433 A method of determining originatingLSPBufferSize for an RBridge is 1434 described in [RFC7780]. If that RBridge has a TRILL over IP transport 1435 port that either (1) can accommodate jumbo frames, (2) is a link on 1436 which IP fragmentation is enabled and acceptable, or (3) is configure 1437 to use TCP encapsulation for all packets, then it is unlikely that 1438 the port will be a constraint on the originatingLSPBufferSize of the 1439 RBridge. On the other hand, if the TRILL over port can only handle 1440 smaller frames, a UDP encapsulation is in use at least for Hellos, 1441 and fragmentation is to be avoided when possible, a TRILL over IP 1442 transport port might have an MTU that constrained the RBridge's 1443 originatingLSPBufferSize. 1445 Because TRILL sets the minimum value of Sz at 1,470 bytes, RBridges 1446 will not constrain LSPs or other IS-IS PDUs to a size smaller than 1447 that. Therefore there may be TRILL over IP transport ports that 1448 require that either fragmentation be enabled or that TCP based 1449 encapsulation for all TRILL packets be used if TRILL communication 1450 over that IP port is desired. When fragmentation is enabled or TCP is 1451 in use, the effective link MTU from the TRILL point of view is larger 1452 than the RBridge port to RBridge port path MTU from the IP point of 1453 view. 1455 TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in 1456 [RFC7177], MUST NOT be fragmented when sent over UDP and can be used 1457 to obtain added assurance of the MTU of a link. The algorithm 1458 discussed in [RFC8249] should be useful in determining the IP MTU 1459 between a pair of RBridge ports that have IP connectivity with each 1460 other. See also [RFC4821]. 1462 An appropriate time to confirm MTU, or re-discover it if it has 1463 changed, is when an RBridge notices topology changes in a path 1464 between RBridge ports that is in use for TRILL over IP transport; 1465 however, MTU can change at other times. For example, if two RBridge 1466 ports are connected by a bridged LAN, topology or configuration 1467 changes within that bridged LAN could change the MTU between those 1468 RBridge ports. 1470 For further discussion of these issues, see [IntareaTunnels]. 1472 9. TRILL over IP Transport Port Configuration 1474 This section specifies the configuration information needed at a 1475 TRILL over IP transport port beyond that needed for a general RBridge 1476 port. 1478 9.1 Per IP Port Configuration 1480 Each RBridge port used for a TRILL over IP transport link should have 1481 at least one IP (v4 or v6) address. If no IP address is associated 1482 with the port, perhaps as a transient condition during re- 1483 configuration, the port is disabled. Implementations MAY allow a 1484 single port to operate as multiple IPv4 and/or IPv6 logical ports. 1485 Each IP address constitutes a different logical port and the RBridge 1486 with those ports MUST associate a different Port ID (see Section 1487 4.4.2 of [RFC6325]) with each logical port. 1489 By default a TRILL over IP transport port discards output packets 1490 that fail the possible recursive ingress test (see Section 10.1) 1491 unless configured to disable that test. 1493 9.2 Additional per IP Address Configuration 1495 The configuration information specified below is per TRILL over IP 1496 transport port IP address. 1498 The mapping from TRILL packet priority to TRILL over IP transport 1499 Differentiated Services Code Point (DSCP [RFC2474]) can be 1500 configured. If supported, mapping from an inner DSCP code point, when 1501 the TRILL payload is IP, to the outer TRILL over IP transport DSCP 1502 can be configured. (See Section 4.3.) 1504 Each TRILL over IP transport port has a list of acceptable 1505 encapsulations it will use as the basis of adjacency. By default this 1506 list consists of one entry for native encapsulation (see Section 7). 1507 Additional encapsulations MAY be configured and native encapsulation 1508 MAY be removed from this list by configuration. Additional 1509 configuration can be required or possible for specific encapsulations 1510 as described in Section 9.2.3. 1512 Each IP address at a TRILL over IP transport port uses native IP 1513 multicast by default but may be configured whether to use serial IP 1514 unicast (Section 9.2.2) or native IP multicast (Section 9.2.1). Each 1515 IP address at a TRILL over IP transport port is configured whether or 1516 not to use IPsec (Section 9.2.4). 1518 Regardless of whether they will send IP multicast, TRILL over IP 1519 transport ports emit appropriate IGMP (IPv4 [RFC3376]) or MLD (IPv6 1520 [RFC2710]) packets unless configured not to do so. These are sent for 1521 the IP multicast group the port would use if it sent IP multicast. 1523 9.2.1 Native Multicast Configuration 1525 If a TRILL over IP transport port address is using native IP 1526 multicast for multi-destination packets (IS-IS and TRILL data), by 1527 default transmissions from that IP address use the IP multicast 1528 address (IPv4 or IPv6) specified in Section 11.2. The TRILL over IP 1529 transport port may be configured to use a different IP multicast 1530 address for multicasting packets. 1532 9.2.2 Serial Unicast Configuration 1534 If a TRILL over IP transport port address has been configured to use 1535 serial unicast for multi-destination packets (IS-IS and TRILL data), 1536 it has associated with it a non-empty list of unicast IP destination 1537 addresses with the same IP version as the version of the port's IP 1538 address (IPv4 or IPv6). Multi-destination TRILL over IP packets are 1539 serially unicast to the addresses in this list. Such a TRILL over IP 1540 transport port will only be able to form adjacencies [RFC7177] with 1541 the RBridges at the addresses in this list as those are the only 1542 RBridges to which it will send IS-IS Hellos. IP packets received from 1543 a source IP address not on the list are discarded. 1545 If this list of destination IP addresses is empty, the port is 1546 disabled. 1548 9.2.3 Encapsulation Specific Configuration 1550 Specific TRILL over IP transport encapsulation methods may provide 1551 for further configuration as specified below. 1553 9.2.3.1 UDP Source Port 1555 As discussed above, the UDP based encapsulations (Sections 5.4 and 1556 5.5) start with a header containing a source port number that can be 1557 used for entropy (Section 8.3). The range of source port values used 1558 defaults to the ephemeral port range (49152-65535) but can be 1559 configured to any other range. 1561 9.2.3.2 VXLAN Configuration 1563 A TRILL over IP transport port using VXLAN encapsulation can be 1564 configured with non-default VXLAN Network Identifiers (VNIs) that are 1565 used in that field of the VXLAN header for all IS-IS and TRILL Data 1566 packets sent using the encapsulation and required in those received 1567 using the encapsulation. The default VNI is 1 for IS-IS and 2 for 1568 TRILL Data. A TRILL packet received with the an unknown VNI is 1569 discarded. 1571 A TRILL over IP transport port using VXLAN encapsulation can also be 1572 configured to map the Inner.VLAN of a TRILL Data packet being 1573 transported to the value it places in the VNI field and/or to copy or 1574 map the Inner.FGL [RFC7172] of a TRILL Data packet to the VNI field. 1576 9.2.3.3 TCP Configuration 1578 A TRILL over IP transport port using TCP encapsulation is 1579 configurable as to the connection re-establishment delay in the range 1580 of 1 to 10,000 milliseconds that defaults to 80 milliseconds. See 1581 Section 5.6.1. 1583 9.2.3.4 Other Encapsulation Configuration 1585 Additional encapsulation methods, beyond those specified in this 1586 document, are expected to be specified in future documents and may 1587 require further configuration. 1589 9.2.4 Security Configuration 1591 A TRILL over IP transport port can be configured, for the case where 1592 IS-IS security [RFC5310] is in use, as to whether or not IPsec must 1593 be fully established and used for any IS-IS transmissions other than 1594 IS-IS Hello or MTU PDUs (see Section 7). There may also be 1595 configuration whose details are outside the scope of this document 1596 concerning certificate based IPsec or use of shared keys other than 1597 IS-IS based shared key or how to select the IS-IS based shared key to 1598 use. 1600 10. Security Considerations 1602 TRILL over IP transport is subject to all of the security 1603 considerations for the base TRILL protocol [RFC6325]. In addition, 1604 there are specific security requirements for different TRILL 1605 deployment scenarios, as discussed in the "Use Cases for TRILL over 1606 IP", Section 3 above. 1608 For communication between end stations in a TRILL campus, security 1609 may be possible at three levels: end-to-end security between those 1610 end stations, edge-to-edge security between ingress and egress 1611 RBridges, and link security to protect a TRILL hop. Any combination 1612 of these can be used, including all three. 1614 TRILL over IP transport link security protects the contents of TRILL 1615 Data and IS-IS packets over a single TRILL hop between RBridge 1616 ports, including protecting the identities of the end stations for 1617 data and the identities of the edge RBridges, from observers of 1618 the link and transit devices within the link such as bridges or IP 1619 routers, but does not encrypt the link local IP addresses used in 1620 a packet and does not protect against observation by the RBridges 1621 on the link. 1623 Edge-to-edge TRILL security would protect the contents of TRILL data 1624 packets between the ingress and egress RBridges, including the 1625 identities of the end stations for data, from transit RBridges but 1626 does not encrypt the identities of the edge RBridges involved and 1627 does not protect against observation by those edge RBridges. Edge- 1628 to-edge TRILL security may be covered in future documents. 1630 End-to-end security does not protect the identities of the end 1631 stations or edge RBridge involved but does protect the user data 1632 content of TRILL data packets from observation by all RBridges or 1633 other intervening devices between the end stations involved. End- 1634 to-end security should always be considered as an added layer of 1635 security to protect any particularly sensitive information from 1636 unintended disclosure. Such end-station to end-station security is 1637 generally outside the scope of TRILL 1639 If VXLAN encapsulation is used, the unused Ethernet source and 1640 destination MAC addresses mentioned in Section 5.5, provide a 96 bit 1641 per packet side channel. 1643 10.1 IPsec 1645 This document specifies that all RBridges that support TRILL over IP 1646 transport links MUST implement IPsec for the security of such links, 1647 and makes it clear that it is both wise and good to use IPsec in all 1648 cases where a TRILL over IP transport link will traverse a network 1649 that is not under the same administrative control as the rest of the 1650 TRILL campus or is not secure. IPsec is important, in these cases, to 1651 protect the privacy and integrity of data traffic. However, in cases 1652 where IPsec is impractical due to lack of fast path support, use of 1653 TRILL edge-to-edge security or use by the end stations of end-to-end 1654 security can provide significant security. 1656 Further Security Considerations for IPsec ESP and for the 1657 cryptographic algorithms used with IPsec can be found in the RFCs 1658 referenced by this document. 1660 10.2 IS-IS Security 1662 TRILL over IP transport is compatible with the use of IS-IS Security 1663 [RFC5310], which can be used to authenticate TRILL switches before 1664 allowing them to join a TRILL campus. This is sufficient to protect 1665 against rogue devices impersonating TRILL switches, but is not 1666 sufficient to protect data packets that may be sent in TRILL over IP 1667 transport outside of the local network or across the public Internet. 1668 To protect the privacy and integrity of that traffic, use IPsec. 1670 In cases were IPsec is used, the use of IS-IS security may not be 1671 necessary, but there is nothing about this specification that would 1672 prevent using both IPsec and IS-IS security together. 1674 11. IANA Considerations 1676 IANA considerations are given below. 1678 11.1 Port Assignments 1680 IANA is requested to assign Ports in the Service Name and Transport 1681 Protocol Port Number Registry [PortRegistry] for TRILL Data and 1682 L2-IS-IS as shown below. The L2-IS-IS port is used for the 1683 tranmission of IS-IS PDUs by TRILL and may be used other protocols. 1685 It is requested that the Hamming distance between the two port number 1686 be at least 2, that is, that at least two bits differ between the 1687 port numbers. For example, they could be an odd number and the 1688 following even number such that both of the bottom two bits would 1689 differ between them. 1691 Service Name: TRILL-data 1692 Transport Protocol: udp, tcp 1693 Assignee: iesg@ietf.org 1694 Contact: chair@ietf.org 1695 Description: Transport of TRILL Data packets. 1696 Reference: [this document] 1697 Port Number: (TBD2) 1699 Service Name: L2-IS-IS 1700 Transport Protocol: udp, tcp 1701 Assignee: iesg@ietf.org 1702 Contact: chair@ietf.org 1703 Description: Transport of IS-IS PDUs. 1704 Reference: [this document] 1705 Port Number: (TBD1) 1707 11.2 Multicast Address Assignments 1709 IANA is requested to assign one IPv4 and one IPv6 multicast address, 1710 as shown below, which correspond to both the All-RBridges and All-IS- 1711 IS-RBridges multicast MAC addresses that have been assigned for 1712 TRILL. Because the low level hardware MAC address dispatch 1713 considerations for TRILL over Ethernet do not apply to TRILL over IP 1714 transport, one IP multicast address for each version of IP is 1715 sufficient. 1717 (Value recommended to IANA in square brackets) 1718 Name IPv4 IPv6 1719 ------------ ------------------ -------------------------- 1720 All-RBridges TBD3 TBD4[FF0X:::15D] 1722 The hex digit "X" in the IPv6 variable scope address indicates the 1723 scope and defaults to 8. The IPv6 All-RBridges IP address may be used 1724 with other values of X. 1726 11.3 Encapsulation Method Support Indication 1728 The existing "RBridge Channel Protocols" registry is re-named and a 1729 new sub-registry under that registry added as follows: 1731 The TRILL Parameters registry for "RBridge Channel Protocols" is 1732 renamed the "RBridge Channel Protocols and Link Technology Specific 1733 Flags" registry. [this document] is added as a second reference for 1734 this registry. The first part of the table is changed to the 1735 following: 1737 Range Registration Note 1738 ----------- ---------------- ---------------------------- 1739 0x002-0x0FF Standards Action 1740 0x100-0xFCF RFC Required allocation of a single value 1741 0x100-0xFCF IESG Approval allocation of multiple values 1742 0xFD0 0xFF7 see Note link technology dependent, 1743 see subregistry 1745 In the existing table of RBridge Channel Protocols, the following 1746 line is changed to two lines as shown: 1748 OLD 1749 0x007-0xFF7 Unassigned 1750 NEW 1751 0x007-0xFCF Unassigned 1752 0xFD0-0xFF7 (link technology dependent, see subregistry) 1754 A new indented subregistry under the re-named "RBridge Channel 1755 Protocols and Link Technology Specific Flags" registry is added as 1756 follows: 1758 Name: TRILL over IP Transport Link Flags 1759 Registration Procedure: Expert Review 1760 Reference: [this document] 1762 Flag Meaning Reference 1763 ---------- ------------------------------ --------- 1764 0xFD0 Native encapsulation fully supported [this document] 1765 0xFD1 VXLAN encapsulation fully supported [this document] 1766 0xFD2 TCP encapsulation fully supported [this document] 1767 0xFD3-0xFF7 Unassigned 1769 Normative References 1771 [IS-IS] - "Intermediate system to Intermediate system routeing 1772 information exchange protocol for use in conjunction with the 1773 Protocol for providing the Connectionless-mode Network Service 1774 (ISO 8473)", ISO/IEC 10589:2002, 2002". 1776 [RFC0020] - Cerf, V., "ASCII format for network interchange", STD 80, 1777 RFC 20, DOI 10.17487/RFC0020, October 1969, . 1780 [RFC0768] - Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 1781 10.17487/RFC0768, August 1980, . 1784 [RFC0793] - Postel, J., "Transmission Control Protocol", STD 7, RFC 1785 793, DOI 10.17487/RFC0793, September 1981, . 1788 [RFC1122] - Braden, R., Ed., "Requirements for Internet Hosts - 1789 Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, 1790 October 1989, . 1792 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1793 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1794 March 1997, . 1796 [RFC2474] - Nichols, K., Blake, S., Baker, F., and D. Black, 1797 "Definition of the Differentiated Services Field (DS Field) in 1798 the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, 1799 December 1998, . 1801 [RFC2710] - Deering, S., Fenner, W., and B. Haberman, "Multicast 1802 Listener Discovery (MLD) for IPv6", RFC 2710, DOI 1803 10.17487/RFC2710, October 1999, . 1806 [RFC2914] - Floyd, S., "Congestion Control Principles", BCP 41, RFC 1807 2914, DOI 10.17487/RFC2914, September 2000, . 1810 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1811 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 1812 10.17487/RFC3168, September 2001, . 1815 [RFC3376] - Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1816 Thyagarajan, "Internet Group Management Protocol, Version 3", 1817 RFC 3376, DOI 10.17487/RFC3376, October 2002, . 1820 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 1821 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 1822 2005, . 1824 [RFC4303] - Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1825 4303, DOI 10.17487/RFC4303, December 2005, . 1828 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1829 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1830 5310, DOI 10.17487/RFC5310, February 2009, . 1833 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 1834 Expand Key Derivation Function (HKDF)", RFC 5869, DOI 1835 10.17487/RFC5869, May 2010, . 1838 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1839 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1840 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 1841 . 1843 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 1844 "Transparent Interconnection of Lots of Links (TRILL): 1845 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 1846 DOI 10.17487/RFC7175, May 2014, . 1849 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1850 D., and A. Banerjee, "Transparent Interconnection of Lots of 1851 Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, 1852 May 2014, . 1854 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1855 and V. Manral, "Transparent Interconnection of Lots of Links 1856 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 1857 . 1859 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1860 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1861 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 1862 2014, . 1864 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1865 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1866 eXtensible Local Area Network (VXLAN): A Framework for 1867 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 1868 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 1871 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 1872 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 1873 Lots of Links (TRILL): Clarifications, Corrections, and 1874 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 1875 . 1877 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1878 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 1879 2017, . 1881 [RFC8200] - Deering, S. and R. Hinden, "Internet Protocol, Version 6 1882 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, 1883 July 2017, . 1885 [RFC8221] - Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 1886 Kivinen, "Cryptographic Algorithm Implementation Requirements 1887 and Usage Guidance for Encapsulating Security Payload (ESP) and 1888 Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, 1889 October 2017, . 1891 [RFC8249] - Zhang, M., Zhang, X., Eastlake 3rd, D., Perlman, R., and 1892 S. Chatterjee, "Transparent Interconnection of Lots of Links 1893 (TRILL): MTU Negotiation", RFC 8249, DOI 10.17487/RFC8249, 1894 September 2017, . 1896 [LEphb] - R. Bless, "A Lower Effort Per-Hop Behavior )LE PHB)", 1897 draft-ietf-tsvwg-le-phb, work in progress. 1899 Informative References 1901 [RFC4821] - Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1902 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 1903 . 1905 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 1906 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 1907 10.17487/RFC6234, May 2011, . 1910 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1911 Interconnection of Lots of Links (TRILL) Protocol Control 1912 Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, 1913 . 1915 [RFC6864] - Touch, J., "Updated Specification of the IPv4 ID Field", 1916 RFC 6864, DOI 10.17487/RFC6864, February 2013, . 1919 [RFC6936] - Fairhurst, G. and M. Westerlund, "Applicability Statement 1920 for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 1921 6936, DOI 10.17487/RFC6936, April 2013, . 1924 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1925 and D. Dutt, "Transparent Interconnection of Lots of Links 1926 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 1927 10.17487/RFC7172, May 2014, . 1930 [RFC7173] - Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 1931 "Transparent Interconnection of Lots of Links (TRILL) Transport 1932 Using Pseudowires", RFC 7173, DOI 10.17487/RFC7173, May 2014, 1933 . 1935 [RFC7296] - Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1936 Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", 1937 STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, 1938 . 1940 [RFC7323] - Borman, D., Braden, B., Jacobson, V., and R. 1941 Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 1942 7323, DOI 10.17487/RFC7323, September 2014, . 1945 [RFC7657] - Black, D., Ed., and P. Jones, "Differentiated Services 1946 (Diffserv) and Real-Time Communication", RFC 7657, DOI 1947 10.17487/RFC7657, November 2015, . 1950 [RFC8085] - Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1951 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 1952 2017, . 1954 [RFC8086] - Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1955 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 1956 2017, . 1958 [IntareaTunnels] - J. Touch, M. Townsley, "IP Tunnels in the Internet 1959 Architecture", draft-ietf-intarea-tunnels, work in progress. 1961 [TRILLECN] - Eastlake, D., B. Briscoe, "TRILL: ECN (Explicit 1962 Congestion Notification) Support", draft-ietf-trill-ecn- 1963 support, work in progress. 1965 [SGKPuses] - D. Eastlake, D. Zhang, "Simple Group Keying Protocol 1966 TRILL Use Profiles", draft-ietf-trill-link-gk-profiles, work in 1967 progress. 1969 [PortRegistry] - https://www.iana.org/assignments/service-names-port- 1970 numbers/service-names-port-numbers.xhtml 1972 Appendix A: IP Security Choice 1974 This informational appendix discusses the choice of mandatory to 1975 implement IP security protocol for TRILL over IP transport ports. 1976 Other security protocols can be used by agreeing TRILL over IP 1977 transport ports, but one protocol was selected as mandatory to 1978 implement for interoperability. 1980 The TRILL WG considered both DTLS and IPsec as the mandatory to 1981 implement IP security protocol. Perhaps the most extensive discussion 1982 occurred at the TRILL WG meeting at IETF meeting 91. The WG decided 1983 to go with IPsec due to better hardware support which was considered 1984 an important factor for being able to operate at or near line speed. 1985 Tunnel mode was chosen as there appeared to be better support for it 1986 in offboard hardware devices. 1988 Acknowledgements 1990 The following people have provided useful feedback on the contents of 1991 this document: Sam Hartman, Adrian Farrel, Radia Perlman, Ines 1992 Robles, Mohammed Umair, Magnus Westerlund, and Lucy Yong. 1994 Some of the material in this document is derived from [RFC8085] and 1995 [RFC8086]. 1997 Authors' Addresses 1999 Margaret Cullen 2000 Painless Security 2001 14 Summer Street, Suite 202 2002 Malden, MA 02148 2003 USA 2005 Phone: +1-781-605-3459 2006 Email: margaret@painless-security.com 2007 URI: http://www.painless-security.com 2009 Donald Eastlake 2010 Huawei Technologies 2011 155 Beaver Street 2012 Milford, MA 01757 2013 USA 2015 Phone: +1 508 333-2270 2016 Email: d3e3e3@gmail.com 2018 Mingui Zhang 2019 Huawei Technologies 2020 No.156 Beiqing Rd. Haidian District, 2021 Beijing 100095 P.R. China 2023 EMail: zhangmingui@huawei.com 2025 Dacheng Zhang 2026 Huawei Technologies 2028 Email: dacheng.zhang@huawei.com 2030 Copyright, Disclaimer, and Additional IPR Provisions 2032 Copyright (c) 2018 IETF Trust and the persons identified as the 2033 document authors. All rights reserved. 2035 This document is subject to BCP 78 and the IETF Trust's Legal 2036 Provisions Relating to IETF Documents 2037 (http://trustee.ietf.org/license-info) in effect on the date of 2038 publication of this document. Please review these documents 2039 carefully, as they describe your rights and restrictions with respect 2040 to this document. Code Components extracted from this document must 2041 include Simplified BSD License text as described in Section 4.e of 2042 the Trust Legal Provisions and are provided without warranty as 2043 described in the Simplified BSD License.