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