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