idnits 2.17.1 draft-ietf-trill-over-ip-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3112 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 7321 (Obsoleted by RFC 8221) ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Margaret Cullen 2 Intended Status: Proposed Standard Painless Security 3 Updates: 7177, 7178 Donald Eastlake 4 Mingui Zhang 5 Huawei 6 Dacheng Zhang 7 Alibaba 8 Expires: April 18, 2016 October 19, 2015 10 Transparent Interconnection of Lots of Links (TRILL) over IP 11 13 Abstract 14 The Transparent Interconnection of Lots of Links (TRILL) 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 standardizes methods for encapsulating TRILL in 18 IP (v4 or v6) so as to use IP as a TRILL link protocol in a unified 19 TRILL campus. It updates RFC 7177 and updates RFC 7178. 21 Status of This Document 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the author or the DNSEXT mailing list . 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 41 Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Introduction............................................4 48 2. Terminology.............................................5 50 3. Use Cases for TRILL over IP.............................6 51 3.1 Remote Office Scenario.................................6 52 3.2 IP Backbone Scenario...................................6 53 3.3 Important Properties of the Scenarios..................6 54 3.3.1 Security Requirements................................7 55 3.3.2 Multicast Handling...................................7 56 3.3.3 Neighbor Discovery...................................8 58 4. TRILL Packet Formats....................................9 59 4.1 General Packet Formats.................................9 60 4.2 General TRILL Over IP Packet Formats..................10 61 4.2.1 Without Security....................................10 62 4.2.2 With Security.......................................10 63 4.3 QoS Considerations....................................11 64 4.4 Broadcast Links and Multicast Packets.................12 65 4.5 TRILL Over IP IS-IS SubNetwork Point of Attachment....13 67 5. TRILL over IP Encapsulation Formats....................14 68 5.1 Encapsulation Considerations..........................14 69 5.2 Encapsulation Agreement...............................15 70 5.3 Broadcast Link Encapsulation Considerations...........16 71 5.4 Native Encapsulation..................................16 72 5.5 VXLAN Encapsulation...................................17 73 5.6 Other Encapulsations..................................18 75 6. Handling Multicast.....................................19 77 7. Use of IPsec and IKEv2.................................20 78 7.1 Keying................................................20 79 7.1.1 Pairwise Keying.....................................20 80 7.1.2 Group Keying........................................21 81 7.2 Mandatory-to-Implement Algorithms.....................21 83 8. Transport Considerations...............................22 84 8.1 Congestion Considerations.............................22 85 8.2 Recursive Ingress.....................................23 86 8.3 Fat Flows.............................................24 87 8.4 MTU Considerations....................................25 88 8.5 Middlebox Considerations..............................25 90 9. TRILL over IP Port Configuration.......................27 91 9.1 Per IP Port Configuration.............................27 92 9.2 Additional per IP Address Configuration...............27 93 9.2.1 Native Multicast Configuration......................27 95 Table of Contents (continued) 97 9.2.2 Serial Unicast Configuration........................28 98 9.2.3 Encapsulation Specific Configuration................28 99 9.2.3.1 VXLAN Configuration...............................28 100 9.2.3.2 Other Encapsulation Configuration.................29 101 9.2.4 Security Configuration..............................29 103 10. Security Considerations...............................30 104 10.1 IPsec................................................30 105 10.2 IS-IS Security.......................................31 107 11. IANA Considerations...................................32 108 11.1 Port Assignments.....................................32 109 11.2 Multicast Address Assignments........................32 110 11.3 Encapsulation Method Support Indication..............32 112 Normative References......................................34 113 Informative References....................................36 115 Acknowledgements..........................................38 117 1. Introduction 119 TRILL switches (RBridges) are devices that implement the IETF TRILL 120 protocol [RFC6325] [RFC7177] [rfc7180bis]. TRILL provides 121 transparent forwarding of frames within an arbitrary network 122 topology, using least cost paths for unicast traffic. It supports 123 VLANs and Fine Grained Labels [RFC7172] as well as multipathing of 124 unicast and multi-destination traffic. It uses IS-IS [RFC7176] link 125 state routing and encapsulation with a hop count. 127 RBridges ports can communicate with each other over various 128 protocols, such as Ethernet [RFC6325], pseudowires [RFC7173], or PPP 129 [RFC6361]. 131 This document defines a method for RBridge ports to communicate over 132 IP (v4 or v6). TRILL over IP allows Internet-connected RBridges to 133 form a single TRILL campus, or multiple TRILL over IP networks within 134 a campus to be connected as a single TRILL campus via a TRILL over IP 135 backbone. 137 TRILL over IP connects RBridge ports using IPv4 or IPv6 as a 138 transport in such a way that the ports appear to TRILL to be 139 connected by a single multi-access link. If more than two RBridge 140 ports are connected via a single TRILL over IP link, any pair of them 141 can communicate. 143 To support the scenarios where RBridges are connected via IP paths 144 (such as over the public Internet) that are not under the same 145 administrative control as the TRILL campus and/or not physically 146 secure, this document specifies the use of IPsec [RFC4301] 147 Encapsulating Security Protocol (ESP) [RFC4303] to secure such paths. 149 To dynamically select a mutually supported TRILL over IP 150 encapsulation, normally one with good fast path hardware support, a 151 method is provided for agreement between adjacent TRILL switch ports 152 as to what encapsulation to use. This document updates [RFC7177] and 153 [RFC7178] as described in Section 5 by making adjacency between TRILL 154 over IP ports dependent on having a method of encapsulation in common 155 and by redefining an interval of RBridge Channel protocol numbers to 156 indicate encapsulation method support for TRILL over IP. 158 2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 The following terms and acronyms have the meaning indicated: 166 DRB - Designated RBridge. The RBridge (TRILL switch) elected to be in 167 charge of certain aspects of a TRILL link that is not 168 configured as a point-to-point link [RFC6325] [RFC7177]. 170 ENCAP Hdr - Encapsulation headers in use between the IP Header and 171 the TRILL Header. See Section 5. 173 ESP - IPsec Encapsulating Security Protocol [RFC4303]. 175 FGL - Fine Grained Label [RFC7172]. 177 Hdr - Used herein as an abbreviation for "Header". 179 HKDF - Hash based Key Derivation Function [RFC5869]. 181 MTU - Maximum Transmission Unit. 183 RBridge - Routing Bridge. An alternative term for a TRILL switch. 185 TRILL - Transparent Internconnection of Lots of Links or Tunneled 186 Routing in the Link Layer. The protocol specified in [RFC6325], 187 [RFC7177], [rfc7180bis], and related RFCs. 189 TRILL switch - A device implementing the TRILL protocol. 191 VNI - Virtual Network Identifier. In VXLAN [RFC7348], the VXLAN 192 Network Identifier. 194 3. Use Cases for TRILL over IP 196 This section introduces two application scenarios (a remote office 197 scenario and an IP backbone scenario) which cover typical situations 198 where network administrators may choose to use TRILL over an IP 199 network to connect TRILL switches. 201 3.1 Remote Office Scenario 203 In the Remote Office Scenario, a remote TRILL network is connected to 204 a TRILL campus across a multihop IP network, such as the public 205 Internet. The TRILL network in the remote office becomes a part of 206 TRILL campus, and nodes in the remote office can be attached to the 207 same VLANs or Fine Grained Labels [RFC7172] as local campus nodes. In 208 many cases, a remote office may be attached to the TRILL campus by a 209 single pair of RBridges, one on the campus end, and the other in the 210 remote office. In this use case, the TRILL over IP link will often 211 cross logical and physical IP networks that do not support TRILL, and 212 are not under the same administrative control as the TRILL campus. 214 3.2 IP Backbone Scenario 216 In the IP Backbone Scenario, TRILL over IP is used to connect a 217 number of TRILL networks to form a single TRILL campus. For example, 218 a TRILL over IP backbone could be used to connect multiple TRILL 219 networks on different floors of a large building, or to connect TRILL 220 networks in separate buildings of a multi-building site. In this use 221 case, there may often be several TRILL switches on a single TRILL 222 over IP link, and the IP link(s) used by TRILL over IP are typically 223 under the same administrative control as the rest of the TRILL 224 campus. 226 3.3 Important Properties of the Scenarios 228 There are a number of differences between the above two application 229 scenarios, some of which drive features of this specification. These 230 differences are especially pertinent to the security requirements of 231 the solution, how multicast data frames are handled, and how the 232 TRILL switch ports discover each other. 234 3.3.1 Security Requirements 236 In the IP Backbone Scenario, TRILL over IP is used between a number 237 of RBridge ports, on a network link that is in the same 238 administrative control as the remainder of the TRILL campus. While it 239 is desirable in this scenario to prevent the association of 240 unauthorized RBridges, this can be accomplished using existing IS-IS 241 security mechanisms. There may be no need to protect the data 242 traffic, beyond any protections that are already in place on the 243 local network. 245 In the Remote Office Scenario, TRILL over IP may run over a network 246 that is not under the same administrative control as the TRILL 247 network. Nodes on the network may think that they are sending traffic 248 locally, while that traffic is actually being sent, in an IP tunnel, 249 over the public Internet. It is necessary in this scenario to protect 250 the integrity and confidentiality of user traffic, as well as 251 ensuring that no unauthorized RBridges can gain access to the RBridge 252 campus. The issues of protecting integrity and confidentiality of 253 user traffic are addressed by using IPsec for both TRILL IS-IS and 254 TRILL Data packets between RBridges in this scenario. 256 3.3.2 Multicast Handling 258 In the IP Backbone scenario, native IP multicast may be supported on 259 the TRILL over IP link. If so, it can be used to send TRILL IS-IS and 260 multicast data packets, as discussed later in this document. 261 Alternatively, multi-destination packets can be transmitted serially 262 by IP unicast to the intended recipients. 264 In the Remote Office Scenario there will often be only one pair of 265 RBridges connecting a given site and, even when multiple RBridges are 266 used to connect a Remote Office to the TRILL campus, the intervening 267 network may not provide reliable (or any) multicast connectivity. 268 Issues such as complex key management also make it difficult to 269 provide strong data integrity and confidentiality protections for 270 multicast traffic. For all of these reasons, the connections between 271 local and remote RBridges will commonly be treated like point-to- 272 point links, and all TRILL IS-IS control messages and multicast data 273 packets that are transmitted between the Remote Office and the TRILL 274 campus will be serially transmitted by IP unicast, as discussed later 275 in this document. 277 3.3.3 Neighbor Discovery 279 In the IP Backbone Scenario, TRILL switches that use TRILL over IP 280 can use the normal TRILL IS-IS Hello mechanisms to discover the 281 existence of other TRILL switches on the link [RFC7177], and to 282 establish authenticated communication with them. 284 In the Remote Office Scenario, an IPsec session will need to be 285 established before TRILL IS-IS traffic can be exchanged, as discussed 286 below. In this case, one end will need to be configured to establish 287 a IPSEC session with the other. This will typically be accomplished 288 by configuring the TRILL switch or a border device at a Remote Office 289 to initiate an IPsec session and subsequent TRILL exchanges with a 290 TRILL over IP-enabled RBridge attached to the TRILL campus. 292 4. TRILL Packet Formats 294 To support the TRILL protocol [RFC6325], two types of TRILL packets 295 are transmitted between TRILL switches: TRILL Data packets and TRILL 296 IS-IS packets. 298 Section 4.1 describes general TRILL packet formats for data and IS-IS 299 independent of link technology. Section 4.2 specifies general TRILL 300 over IP packet formats including IPsec ESP encapsulation. Section 4.3 301 provides QoS Considerations. Section 4.4 discusses broadcast links 302 and multicast packets. And Section 4.5 provides TRILL IS-IS Hello 303 SubNetwork Point of Attachment (SNPA) considerations for TRILL over 304 IP. 306 4.1 General Packet Formats 308 The on-the-wire form of a TRILL Data packet in transit between two 309 neighboring TRILL switch ports is as shown below: 311 +----------------+----------+----------------+-----------+ 312 | Link Header | TRILL | Native Frame | Link | 313 | for TRILL Data | Header | Payload | Trailer | 314 +----------------+----------+----------------+-----------+ 316 The encapsulated Native Frame Payload is similar to an Ethernet frame 317 with a VLAN tag or Fine Grained Label [RFC7172] but with no trailing 318 Frame Check Sequence (FCS). 320 TRILL IS-IS packets are formatted on-the-wire as follows: 322 +-----------------+---------------+-----------+ 323 | Link Header | TRILL IS-IS | Link | 324 | for TRILL IS-IS | Payload | Trailer | 325 +-----------------+---------------+-----------+ 327 The Link Header and Link Trailer in these formats depend on the 328 specific link technology. The Link Header contains one or more fields 329 that distinguish TRILL Data from TRILL IS-IS. For example, over 330 Ethernet, the Link Header for TRILL Data ends with the TRILL 331 Ethertype while the Link Header for TRILL IS-IS ends with the L2-IS- 332 IS Ethertype; on the other hand, over PPP, there are no Ethertypes in 333 the Link Header but PPP protocol code points are included that 334 distinguish TRILL Data from TRILL IS-IS. 336 4.2 General TRILL Over IP Packet Formats 338 In TRILL over IP, we will use an IP (v4 or v6) header as the link 339 header. (On the wire, the IP header will normally be preceded by the 340 lower layer header of a protocol that is carrying IP; however, this 341 does not concern us at the level of this document.) 343 There are multiple IP based encapsulations usable for TRILL over IP 344 that differ in exactly what appears after the IP header and before 345 the TRILL Header or the TRILL IS-IS Payload. These encapsulations are 346 further detailed in Section 5. In the general specification below, 347 those encapsulation fields will be represented as "ENCAP Hdr". See 348 Section 5 for details. 350 4.2.1 Without Security 352 When TRILL over IP link security is not being used, a TRILL over IP 353 packet on the wire looks like the following: 355 TRILL Data Packet 356 +---------+------------+---------+---------------+ 357 | IP | ENCAP Hdr | TRILL | Native frame | 358 | Header | for Data | Header | Payload | 359 +---------+------------+---------+---------------+ 361 TRILL IS-IS 362 +---------+------------+--------------+ 363 | IP | ENCAP Hdr | TRILL IS-IS | 364 | Header | for IS-IS | Payload | 365 +---------+------------+--------------+ 367 As discussed above and further specified in Section 5, the ENCAP Hdr 368 indicates whether the packet is TRILL Data or IS-IS. 370 4.2.2 With Security 372 TRILL over IP link security uses IPsec Encapsulating Security 373 Protocol (ESP) in tunnel mode [RFC4303]. Since TRILL over IP always 374 starts with an IP Header (on the wire this appears right after any 375 lower layer header that might be required), the modifications for 376 IPsec are independent of the TRILL over IP ENCAP Hdr that occurs 377 after that IP Header. The resulting packet formats are as follows for 378 IPv4 and IPv6: 380 IPv4 381 +-------------+-----+--------------+-----------+-----------+ 382 | new IP Hdr | ESP | TRILL IP Hdr | ENCAP Hdr | ESP |ESP| 383 |(any options)| Hdr | (any options)| + payload |Trailer|ICV| 384 +-------------+-----+--------------+-----------+-----------+ 385 |<---------- encryption ---------->| 386 |<-------------- integrity ------------->| 388 IPv6 389 +------+-------+-----+------+--------+-----------+-------+---+ 390 | new |new ext| ESP | orig |orig ext| ENCAP Hdr | ESP |ESP| 391 |IP Hdr| Hdrs | Hdr |IP Hdr| Hdrs | + payload |Trailer|ICV| 392 +------+-------+-----+------+--------+-----------+-------+---+ 393 |<----------- encryption ---------->| 394 |<--------------- integrity ------------->| 396 As shown above, IP Header options are considered part of the IPv4 397 Header but are extensions ("ext") of the IPv6 Header. For further 398 information on the IPsec ESP Hdr, Trailer, and ICV, see [RFC4303] and 399 Section 7. "ENCAP Hdr + payload" is the encapsulation header (Section 400 5) and TRILL data or IS-is payload, that is, the material after the 401 IP Header in the diagram in Section 4.2.1. 403 This architecture permits the ESP tunnel end point to be separated 404 from the TRILL over IP RBridge port (see, for example, Section 1.1.3 405 of [RFC7296]). 407 4.3 QoS Considerations 409 In IP, QoS handling is indicated by the Differential Services Code 410 Point (DSCP [RFC2474] [RFC3168]) in the TRILL Header. The former 411 Type of Service (TOS) octet in the IPv4 Header and the Traffic Class 412 octet in the IPv6 Header has been divided as shown in the following 413 diagram adapted from [RFC3168]. (TRILL support of ECN is beyond the 414 scope of this document.) 416 0 1 2 3 4 5 6 7 417 +-----+-----+-----+-----+-----+-----+-----+-----+ 418 | DSCP FIELD | ECN FIELD | 419 +-----+-----+-----+-----+-----+-----+-----+-----+ 421 DSCP: Differentiated Services Codepoint 422 ECN: Explicit Congestion Notification 424 Within a TRILL switch, priority is indicated by configuration for 425 TRILL IS-IS packets and for TRILL Data packets by a three bit (0 426 through 7) priority field and a Drop Eligibility Indicator bit (see 427 Sections 8.2 and 7 of [rfc7180bis]). (Typically TRILL IS-IS is 428 configured to use the highest priority or, alternatively, the highest 429 two priorities depending on the IS-IS PDU.) The priority affects 430 queuing behavior at TRILL switch ports and may be encoded into the 431 link header, particularly if there could be priority sensitive 432 devices within the link. For example, if the link is a bridged LAN, 433 it is commonly encoded into an Outer.VLAN tag's priority and DEI 434 fields. 436 TRILL over IP implementations MUST support setting the DSCP value in 437 the outer IP Header of TRILL packets they send by mapping the TRILL 438 priority and DEI to the DSCP. They MAY support, for a TRILL Data 439 packet where the native frame payload is an IP packet, copying the 440 DSCP in this inner IP packet to the outer IP Header. 442 The default TRILL priority and DEI to DSCP mapping, which may be 443 configured per TRILL over IP port, is an follows. Note that the DEI 444 value does not affect the default mapping and, to provide a 445 potentially lower priority service than the default 0, priority 1 is 446 considered lower priority than 0. So the priority sequence from lower 447 to higher priority is 1, 0, 2, 3, 4, 5, 6, 7. 449 TRILL Priority DEI DSCP Field (Binary/decimal) 450 -------------- --- ----------------------------- 451 0 0/1 001000 / 8 452 1 0/1 000000 / 0 453 2 0/1 010000 / 16 454 3 0/1 011000 / 24 455 4 0/1 100000 / 32 456 5 0/1 101000 / 40 457 6 0/1 110000 / 48 458 7 0/1 111000 / 56 460 4.4 Broadcast Links and Multicast Packets 462 TRILL supports broadcast links. These are links to which more than 463 two TRILL switch ports can be attached and where a packet can be 464 broadcast or multicast from a port to all or a subset of the other 465 ports on the link as well as unicast to a specific single other port 466 on the link. 468 As specified in [RFC6325], TRILL Data packets being forwarded between 469 TRILL switches can be unicast on a link to a specific TRILL switch 470 port or multicast on a link to all TRILL switch ports. TRILL IS-IS 471 packets are always multicast to all other TRILL switches on the link 472 except for IS-IS MTU PDUs, which may be unicast [RFC7177]. This 473 distinction is not significant if the link is inherently point-to- 474 point, such as a PPP link; however, on a broadcast link there will be 475 a packet outer link address that is unicast or multicast as 476 appropriate. For example, over Ethernet links, the Ethernet multicast 477 addresses All-RBridges and All-IS-IS-RBridges are used for 478 multicasting TRILL Data and TRILL IS-IS respectively. For details on 479 TRILL over IP handling of multicast, see Section 6. 481 4.5 TRILL Over IP IS-IS SubNetwork Point of Attachment 483 IS-IS routers, such as TRILL switches, establish adjacency through 484 the exchange of Hello PDUs on a link [IS-IS] [RFC7177]. The Hellos 485 transmitted out a port indicate what neighbor ports that port can see 486 on the link by listing what IS-IS refers to as the neighbor port's 487 SubNetwork Point of Attachment (SNPA). (For an Ethernet link, which 488 may be a bridged LAN, the SNPA is the port MAC address.) 490 In TRILL Hello PDUs on a TRILL over IP link, the IP addresses of the 491 IP ports connected to that link are their actual SNPA (SubNetwork 492 Point of Attachment [IS-IS]) addresses and, for IPv6, the 16-byte 493 IPv6 address is used as the SNPA; however, for easy in re-using code 494 designed for the common case of 48-bit SNPAs, in TRILL over IPv4 a 495 48-bit synthetic SNPA that looks like a unicast MAC address is 496 constructed for use in the SNPA field of TRILL Neighbor TLVs 497 [RFC7176] [RFC7177] in such Hellos. This synthetic SNPA is derived 498 from the port IPv4 address is as follows: 500 1 1 1 1 1 1 501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | 0xFE | 0x00 | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | IPv4 upper half | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | IPv4 lower half | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 This synthetic SNPA (MAC) address has the local (0x02) bit on in the 511 first byte and so cannot conflict with any globally unique 48-bit 512 Ethernet MAC. However, when TRILL operates on an IP link, TRILL sees 513 only IP stations, not MAC stations, even if the TRILL over IP Link is 514 being carried over Ethernet. Therefore conflict on the link in TRILL 515 IS-IS between a real MAC address and the synthetic SNPA (MAC) address 516 as above would be impossible in any case. 518 5. TRILL over IP Encapsulation Formats 520 There are a variety of TRILL over IP encapsulation formats possible. 521 By default TRILL over IP adopts a hybrid encapsulation approach. 523 There is one format, called "native encapsulation" that MUST be 524 implemented. Although native encapsulation does not typically have 525 good fast path support, as a lowest common denominator it can be used 526 by low bandwidth control traffic to determine a preferred 527 encapsulation with better performance. In particular, by default, all 528 TRILL IS-IS Hellos are sent using native encapsulation and those 529 Hellos are used to determine the encapsulation used for all TRILL 530 Data packets and all other TRILL IS-IS PDUs (with the possible 531 exception of IS-IS MTU-probe and MTU-ack PDUs). 533 Alternatively, the network operator can pre-configure a TRILL over IP 534 port to use a particular encapsulation chosen for their particular 535 network needs and port capabilities. That encapsulation is then used 536 for all TRILL Data and IS-IS packets on ports so configured. 538 Section 5.1 discusses general consideration for the TRILL over IP 539 encapsulation format. Section 5.2 discusses encapsulation agreement. 540 Section 5.3 discusses broadcast link encapsulation considerations. 541 The subsequent subsections discuss particular encapsulations. 543 5.1 Encapsulation Considerations 545 In all cases, there must be a method specified to distinguish TRILL 546 Data packets and TRILL IS-IS packets, or that encapsulation is not 547 useful for TRILL. In addition, the following criteria can be helpful 548 is choosing between different encapsulations: 550 a) Fast path support - For many applications, it is highly desirable 551 to be able to encapsulate/decpasulate TRILL over IP at line speed 552 so a format where existing or anticipated fast path hardware can 553 do that is best. This is commonly a dominant consideration. 555 b) Ease of multi-pathing - The IP path between TRILL over IP ports 556 may include equal cost multipath routes internal to the IP link so 557 a method of encapsulation that provides variable fields available 558 for existing or anticipated fast path hardware multi-pathing is 559 better. 561 c) Robust fragmentation and re-assembly - MTU of the IP link may 562 require fragmentation in which case an encapsulation with robust 563 fragmentation and re-assembly is important. There are known 564 problems with IPv4 fragmentation and re-assembly [RFC6864] which 565 generally do not apply to IPv6. Some encapsulations can fix these 566 problems but the two encapsulations specified in this document do 567 not. Therefore, if fragmentation is anticipated with the 568 encapsulations specified in this document, the use of IPv6 is 569 RECOMMENDED. 571 d) Checksum strength - Depending on the particular circumstances of 572 the TRILL over IP link, a checksum provided by the encapsulation 573 may be an important factor. Use of IPsec can also provide a strong 574 integrity check. 576 5.2 Encapsulation Agreement 578 TRILL Hellos sent out a TRILL over IP port indicate the 579 encapsulations that port is willing to support through a mechanism 580 initially specified in [RFC7178] and [RFC7176] that is hereby 581 extended. Specifically, RBridge Channel Protocol numbers 0xFD0 582 through 0xFF7 are redefined to be link technology dependent flags 583 that, for TRILL over IP, indicate support for different 584 encapsulations, allowing for up to 40 encapsulations to be specified. 585 Support for an encapsulation is indicated in the Hello PDU in the 586 same way that support for an RBridge Channel was indicated. (See also 587 section 11.3.) "Support" indicates willingness to use that 588 encapsulation for TRILL Data and TRILL IS-IS packets (although TRILL 589 IS-IS Hellos are still sent in native encapsulation by default). 591 If, in a TRILL Hello on a TRILL over IP link, support is not 592 indicated for any encapsulation, then the port from which it was sent 593 is assumed to support only native encapsulation (see Section 5.4). 595 An adjacency is formed between two TRILL over IP ports if the 596 intersection of the sets of encapsulation methods they support is not 597 null. If that intersection is null, then no adjacency is formed. In 598 particular, for a TRILL over IP link, the adjacency state machine 599 MUST NOT advance to the Report state unless the ports share an 600 encapsulation [RFC7177]. If no encapsulation is shared, the adjacency 601 state machine remains in the state from which it would otherwise have 602 transitioned to the Report state. 604 If any TRILL over IP packet, other than an IS-IS Hello or MTU PDU in 605 native encapsulation, is received in an encapsulation for which 606 support is not being indicated, it MUST be discarded (see Section 607 5.3). 609 If there are two or more encapsulations in common between two 610 adjacent ports for unicast or the set of adjacent ports for 611 multicast, a transmitter is free to choose whichever of the 612 encapsulations it wishes to use. Thus transmissions between adjacent 613 ports P1 and P2 could use different encapsulations depending on which 614 port is transmitting and which is receiving. 616 It is expected to be the normal case in a well configured network 617 that all the TRILL over IP ports connected to an IP link (i.e., an IP 618 network) that are intended to communicate with each other will 619 support the same encapsulation(s). 621 5.3 Broadcast Link Encapsulation Considerations 623 To properly handle TRILL protocol packets on a TRILL over IP link in 624 the general case, either native IP multicast mode is used on that 625 link or multicast must be simulated using serial IP unicast, as 626 discussed in Section 6. (Of course, if the IP link happens to 627 actually be point-to-point no special provision is needed for 628 handling multicast addressed packets.) 630 It is possible for the Hellos from a TRILL over IP port P1 to 631 establish adjacency with multiple other TRILL over IP ports (P2, P3, 632 ...) on broadcast link. In a well configured network one would expect 633 all of the IP ports involved to support the same encapsulation(s); 634 but, if P1 supports multiple encapsulations, it is possible that P2 635 and P3, for example, do not have an encapsulation in common that is 636 supported by P1. IS-IS can handle such non-transitive adjacencies 637 which are reported as specified in [RFC7177]. If serial IP unicast is 638 being used by P1, it can use different encapsulations for different 639 transmissions. If native IP multicast is being used by P1, it will 640 have to send one transmission per encapsulation method by which it 641 has an adjacency on the link. (It is for this reason that a TRILL 642 over IP port MUST discard any packet received with the wrong 643 encapsulation. Otherwise, packets would be duplicated.) 645 5.4 Native Encapsulation 647 The mandatory to implement "native encapsulation" format of a TRILL 648 over IP packet, when used without security, is TRILL over UDP as 649 shown below. 651 +----------+--------+-----------------------+ 652 | IP | UDP | TRILL | 653 | Header | Header | Payload | 654 +----------+--------+-----------------------+ 656 Where the UDP Header is as follows: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Source Port = Entropy | Destination Port | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | UDP Length | UDP Checksum | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | TRILL Payload ... 667 Source Port - see Section 8.3 669 Destination Port - indicates TRILL Data or IS-IS, see Section 11 671 UDP Length - as specified in [RFC0768] 673 UDP Checksum - as specified in [RFC0768] 675 The TRILL Payload starts with the TRILL Header (not including the 676 TRILL Ethertype) for TRILL Data packets and starts with the 0x83 677 Intradomain Routeing Protocol Discriminator byte (thus not including 678 the L2-IS-IS Ethertype) for TRILL IS-IS packets. 680 5.5 VXLAN Encapsulation 682 VXLAN [RFC7348] IP encapsulation of TRILL looks, on the wire, like 683 TRILL over Ethernet over VXLAN over UDP over IP. 685 +--------+--------+--------+----------+-----------+ 686 | IP | UDP | VXLAN | Ethernet | TRILL | 687 | Header | Header | Header | Header | Payload | 688 +--------+--------+--------+----------+-----------+ 690 The outer UDP uses a destination port number indicating VXLAN and the 691 outer UDP source port MAY be used for entropy as with native 692 encapsulation (see Section 5.4). The VXLAN header after the outer UDP 693 header adds a 24 bit Virtual Network Identifier (VNI). The Ethernet 694 header after the VXLAN header and before the TRILL header consists of 695 source MAC address, destination MAC address, and Ethertype. The 696 Ethertype distinguishes TRILL Data from TRILL IS-IS; however, the 697 destination and source MAC addresses in this inner Ethernet header 698 are not used and are 12 wasted bytes. 700 A TRILL over IP port using VXLAN encapsulation by default uses a VNI 701 of 1 but can be configured as described in Section 9.2.3.1 to use 702 some other fixed VNI or to map from VLAN/FGL to VNI. 704 5.6 Other Encapulsations 706 It is anticipated that additional TRILL over IP encapsulations will 707 be specified in future documents and allocated a bit in the TRILL 708 Hello as per Section 11.3. A primary consideration for whether it is 709 worth the effort to specify an encapsulation is good existing or 710 anticipated fast path support. 712 6. Handling Multicast 714 By default, both TRILL IS-IS packets and multi-destination TRILL Data 715 packets are sent to an All-RBridges IPv4 or IPv6 IP multicast Address 716 as appropriate (see Section 11.2); however, a TRILL over IP port may 717 be configured (see Section 9) to use a different multicast address or 718 to use serial IP unicast with a list of one or more unicast IP 719 addresses of other TRILL over IP ports to which multi-destination 720 packets are sent. In the serial unicast case the outer IP header of 721 each copy of the packet sent shows an IP unicast destination address 722 even through the TRILL header has the M bit set to one to indicate 723 multi-destination. Serial unicast configuration is necessary if the 724 TRILL over IP port is connected to an IP network that does not 725 support IP multicast. In any case, unicast TRILL packets are sent by 726 unicast IP. 728 Even if a TRILL over IP port is configured to send multi-destination 729 packets with serial unicast, it MUST be prepared to receive IP 730 multicast TRILL packets. All TRILL over IP ports default to 731 periodically transmitting appropriate IGMP (IPv4 [RFC3376] or MLD 732 (IPv6 [RFC2710]) packets, so that the TRILL multicast IP traffic will 733 be sent to them, unless they are configured not to do so. 735 Although TRILL fully supports broadcast links with more than 2 736 RBridges connected to the link there may be good reasons for 737 configuring TRILL over IP ports to use serial unicast even where 738 native IP multicast is available. Use of serial unicast provides the 739 network manager with more precise control over adjacencies and how 740 TRILL over IP links will be formed in an IP network. In some 741 networks, unicast is more reliable than multicast. If multiple point- 742 to-point TRILL over IP connections between parts of a TRILL campus 743 are configured, TRILL will in any case spread traffic across them, 744 treating them as parallel links, and appropriately fail over traffic 745 if a link fails or incorporate a new link that comes up. 747 7. Use of IPsec and IKEv2 749 All TRILL switches (RBridges) that support TRILL over IP MUST 750 implement IPsec [RFC4301] and support the use of IPsec Encapsulating 751 Security Protocol (ESP [RFC4303]) in tunnel mode to secure both TRILL 752 IS-IS and TRILL data packets. When IPsec is used to secure a TRILL 753 over IP link and no IS-IS security is enabled, the IPsec session MUST 754 be fully established before any TRILL IS-IS or data packets are 755 exchanged. When there is IS-IS security [RFC5310] provided, 756 implementers SHOULD use IS-IS security to protect TRILL IS-IS 757 packets. However, in this case, the IPsec session still MUST be fully 758 established before any data packets transmission since IS-IS security 759 does not provide any protection to data packets. 761 All RBridges that support TRILL over IP MUST implement the Internet 762 Key Exchange Protocol version 2 (IKEv2) for automated key management. 764 7.1 Keying 766 The following subsections discuss pairwise and group keying for TRILL 767 over IP IPsec. 769 7.1.1 Pairwise Keying 771 When IS-IS security is in use, IKEv2 will use a pre-shared key that 772 incorporates the IS-IS shared key in order to bind the TRILL data 773 session to the IS-IS session. The pre-shared key that will be used 774 for IKEv2 exchanges for TRILL over IP is determined as follows: 776 HKDF-Expand-SHA256 ( IS-IS-key, 777 "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port ) 779 In the above "|" indicates concatenation, HKDF is as in [RFC5869], 780 SHA256 is as in [RFC6234], and "TRILL IP" is the eight byte US ASCII 781 [RFC0020] string indicated. "IS-IS-key" is an IS-IS key usable for 782 IS-IS security of link local IS-IS PDUs such as Hello, CSNP, and 783 PSNP. This SHOULD be a link scope IS-IS key. With [RFC5310] there 784 could be multiple keys identified with 16-bit key IDs. In this case, 785 the Key ID of IS-IS-key is also used to identify the derived key. 786 P1-System-ID and P2-System ID are the System IDs of the two TRILL 787 RBridges, and P1-Port and P2-Port are the ports in use on each end. 788 System IDs are guaranteed to be unique within the TRILL campus. Both 789 of the RBridges involved treat the larger magnitude System ID, 790 comparing System IDs as unsigned integers, as P1 and the smaller as 791 P2 so both will derive the same key. 793 When IS-IS security is in use, the IS-IS-shared key from which the 794 IKEv2 shared secret is derived might expire and be updated as 795 described in [RFC5310]. The IKEv2 pre-shared keys derived from the 796 IS-IS shared key MUST expire within the same lifetime as the IS-IS- 797 shared key from which they were derived. When the IKEv2 pre-shared 798 key expires, the IKEv2 Security Association must be rekeyed using a 799 new shared secret derived from the new IS-IS shared key. 801 When IS-IS security is not in use, IKEv2 will not use a pre-shared 802 key. 804 7.1.2 Group Keying 806 In the case of a TRILL over IP port configured as point-to-point (see 807 Section 4.2.4.1 of [RFC6325]), there is no group keying and the 808 pairwise key determined as in Section 7.1.1 is used for IP multicast 809 traffic. 811 In the case of a TRILL over IP port configured as broadcast but where 812 the port is configured to use serial unicast (see Section 8), there 813 is no group keying and the pairwise keying determined as in Section 814 7.1.1 is used for IP multicast traffic. 816 In the case of a TRILL over IP port configured as broadcast and using 817 native multicast, ... tbd ... 819 7.2 Mandatory-to-Implement Algorithms 821 All RBridges that support TRILL over IP MUST implement IPsec ESP 822 [RFC4303] in tunnel mode. The implementation requirements for ESP 823 cryptographic algorithms are as specified for IPsec. That 824 specification is currently [RFC7321]. 826 8. Transport Considerations 828 This section discusses a variety of important transport 829 considerations. 831 8.1 Congestion Considerations 833 Section 3.1.3 of [RFC5405] discussed the congestion implications of 834 UDP tunnels. As discussed in [RFC5405], because other flows can share 835 the path with one or more UDP tunnels, congestion control [RFC2914] 836 needs to be considered. 838 The default initial determination of the TRILL over IP encapsulation 839 to be used through the exchange of TRILL IS-IS Hellos is a low 840 bandwidth process. Hellos are not permitted to be sent any more often 841 than once per second, and so are unlikely to cause congestion. 843 One motivation for including UDP in a TRILL encapsulation is to 844 improve the use of multipath (such as ECMP) in cases where traffic is 845 to traverse routers which are able to hash on UDP Port and IP 846 address. In many cases this may reduce the occurrence of congestion 847 and improve usage of available network capacity. However, it is also 848 necessary to ensure that the network, including applications that use 849 the network, responds appropriately in more difficult cases, such as 850 when link or equipment failures have reduced the available capacity. 852 The impact of congestion must be considered both in terms of the 853 effect on the rest of the network of a UDP tunnel that is consuming 854 excessive capacity, and in terms of the effect on the flows using the 855 UDP tunnels. The potential impact of congestion from a UDP tunnel 856 depends upon what sort of traffic is carried over the tunnel, as well 857 as the path of the tunnel. 859 TRILL is used to carry a wide range of traffic. In many cases TRILL 860 is used to carry IP traffic. IP traffic is generally assumed to be 861 congestion controlled, and thus a tunnel carrying general IP traffic 862 (as might be expected to be carried across the Internet) generally 863 does not need additional congestion control mechanisms. As specified 864 in [RFC5405]: 866 "IP-based traffic is generally assumed to be congestion- 867 controlled, i.e., it is assumed that the transport protocols 868 generating IP-based traffic at the sender already employ 869 mechanisms that are sufficient to address congestion on the path. 870 Consequently, a tunnel carrying IP-based traffic should already 871 interact appropriately with other traffic sharing the path, and 872 specific congestion control mechanisms for the tunnel are not 873 necessary". 875 For this reason, where TRILL is sent using UDP and used to carry IP 876 traffic that is known to be congestion controlled, the UDP paths MAY 877 be used across any combination of a single or cooperating service 878 providers or across the general Internet. 880 However, TRILL is also used to carry traffic that is not necessarily 881 congestion controlled. For example, TRILL may be used to carry 882 traffic where specific bandwidth guarantees are provided. 884 In such cases congestion may be avoided by careful provisioning of 885 the network and/or by rate limiting of user data traffic. Where TRILL 886 is carried, directly or indirectly, over UDP over IP, the identity of 887 each individual TRILL flow is in general lost. 889 For this reason, where the TRILL traffic is not congestion 890 controlled, TRILL over UDP/IP MUST only be used within a single 891 service provider that utilizes careful provisioning (e.g., rate 892 limiting at the entries of the network while over-provisioning 893 network capacity) to ensure against congestion, or within a limited 894 number of service providers who closely cooperate in order to jointly 895 provide this same careful provisioning. As such, TRILL over UDP/IP 896 MUST NOT be used over the general Internet, or over non-cooperating 897 service providers, to carry traffic that is not congestion- 898 controlled. 900 Measures SHOULD be taken to prevent non-congestion-controlled TRILL 901 over UDP/IP traffic from "escaping" to the general Internet, for 902 example the following: 904 a. Physical or logical isolation of the TRILL over IP links from the 905 general Internet. 907 b. Deployment of packet filters that block the UDP ports assigned for 908 TRILL-over-UDP. 910 c. Imposition of restrictions on TRILL over UDP/IP traffic by 911 software tools used to set up TRILL over UDP paths between 912 specific end systems (as might be used within a single data 913 center). 915 d. Use of a "Managed Circuit Breaker" for the TRILL traffic as 916 described in [circuit-breaker]. 918 8.2 Recursive Ingress 920 TRILL is specified to transport data to and from end stations over 921 Ethernet and IP is frequently transported over Ethernet. Thus, an end 922 station native data Ethernet frame EF might get TRILL ingressed to 923 TRILL(EF) that was then sent out a TRILL over IP over Ethernet port 924 resulting in a packet on the wire of the form 925 Ethernet(IP(TRILL(EF))). There is a risk of such a packet being re- 926 ingressed by the same TRILL campus, due to physical or logical 927 misconfiguration, looping round, being further re-ingressed, and so 928 on. The packet might get discarded if it got too large but if 929 fragmentation is enabled, it would just keep getting split into 930 fragments that would continue to loop and grow and re-fragment until 931 the path was saturated with junk and packets were being discarded due 932 to queue overflow. The TRILL Header TTL would provide no protection 933 because each TRILL ingress adds a new TRILL header with a new TTL. 935 To protect against this scenario, a TRILL over IP port MUST by, 936 default, test whether a TRILL packet it is about to transmit appears 937 to be a TRILL ingress of a TRILL over IP over Ethernet packet. That 938 is, is it of the form TRILL(Ethernet(IP(TRILL(...)))? If so, the 939 default action of the TRILL over IP output port is to discard the 940 packet rather than transmit it. However, there are cases where some 941 level of nested ingress is desired so it MUST be possible to 942 configure the port to allow such packets. 944 8.3 Fat Flows 946 For the purpose of load balancing, it is worthwhile to consider how 947 to transport the TRILL packets over the Equal Cost Multiple Paths 948 (ECMPs) existing internal to the IP path between TRILL over IP ports. 950 The ECMP election for the IP traffic could be based, at least for 951 IPv4, on the quintuple of the outer IP header { Source IP, 952 Destination IP, Source Port, Destination Port, and IP protocol }. 953 Such tuples, however, could be exactly the same for all TRILL Data 954 packets between two RBridge ports, even if there is a huge amount of 955 data being sent between a variety of ingress and egress RBridges. On 956 solution to this is to use the Source Port in as an entropy field. 957 (This idea is also introduced in [gre-in-udp].) For example, for 958 TRILL Data this entropy field could be based on some hash of the 959 Inner.MacDA, Inner.MacSA, and Inner.VLAN or Inner.FGL. Unfortunately, 960 this can conflict with middleboxes inside the TRILL over IP link (see 961 8.5). Therefore, in order to better support ECMP, a RBridge SHOULD 962 set the Source Port to a range of values as an entropy field for ECMP 963 decisions. However, if there are middleboxes in the path, the range 964 of different Source Port values used MUST be restricted sufficiently 965 to avoid disrupting connectivity. 967 8.4 MTU Considerations 969 In TRILL each TRILL switch advertises in its LSP number zero the 970 largest LSP frame it can accept (but not less than 1,470 bytes) on 971 any of its interfaces (at least those interfaces with adjacencies to 972 other TRILL switches in the campus) through the 973 originatingLSPBufferSize TLV [RFC6325] [RFC7177]. The campus minimum 974 MTU (Maximum Transmission Unit), denoted Sz, is then established by 975 taking the minimum of this advertised MTU for all RBridges in the 976 campus. Links that do not meet the Sz MTU are not included in the 977 routing topology. This protects the operation of IS-IS from links 978 that would be unable to accommodate some LSPs. 980 A method of determining originatingLSPBufferSize for an RBridge with 981 one or more TRILL over IP ports is described in [rfc7180bis]. 982 However, if an IP link either can accommodate jumbo frames or is a 983 link on which IP fragmentation is enabled and acceptable, then it is 984 unlikely that the IP link will be a constraint on the 985 originatingLSPBufferSize of an RBridge using the link. On the other 986 hand, if the IP link can only handle smaller frames and fragmentation 987 is to be avoided when possible, a TRILL over IP port might constrain 988 the RBridge's originatingLSPBufferSize. Because TRILL sets the 989 minimum values of Sz at 1,470 bytes, there may be links that meet the 990 minimum MTU for the IP protocol (1,280 bytes for IPv6, 576 bytes for 991 IPv4) on which it would be necessary to enable fragmentation for 992 TRILL use. 994 The use of TRILL IS-IS MTU PDUs, as specified in [RFC6325] and 995 [RFC7177] can provide added assurance of the actual MTU of a link. 997 8.5 Middlebox Considerations 999 This section gives some middlebox considerations for the IP 1000 encapsulations covered by this document, namely native and VXLAN 1001 encapsulation. 1003 The requirements on the usage of the zero UDP Checksum in a UDP 1004 tunnel protocol are detailed in [RFC6936]. These requirements apply 1005 to TRILL over IP the encapsulations specified herein (native and 1006 VXLAN), which are applications of UDP tunnel. 1008 Besides the Checksum, the Source Port number of the UDP header is 1009 also pertinent to the middlebox behavior. Network Address/Port 1010 Translator (NAPT) is the most commonly deployed Network Address 1011 Translation (NAT) device [RFC4787]. For a UDP tunnel protocol, the 1012 NAPT device establishes a NAT session to translate the {private IP 1013 address, private source port number} tuple to a {public IP address, 1014 public source port number} tuple, and vice versa, for the duration of 1015 the UDP session. This provides the UDP tunnel protocol application 1016 with the "NAT-pass-through" function. NAPT allows multiple internal 1017 hosts to share a single public IP address. The port number, i.e., the 1018 UDP Source Port number, is used as the demultiplexer of the multiple 1019 internal hosts. 1021 However, the above NAPT behavior conflicts with the behavior that the 1022 UDP Source Port number is used as an entropy (See Section 8.3). 1023 Hence, the tunnel operator MUST ensure the TRILL switch ports sending 1024 through local or remote NAPT middleboxes disable the entropy usage of 1025 the UDP Source Port number. 1027 9. TRILL over IP Port Configuration 1029 This section specifies the configuration information needed at a 1030 TRILL over IP port beyond that needed for a general RBridge port. 1032 9.1 Per IP Port Configuration 1034 Each RBridge port used for a TRILL over IP link should have at least 1035 one IP (v4 or v6) address. If no IP address is associated with the 1036 port, perhaps as a transient condition during re-configuration, the 1037 port is disabled. Implementations MAY allow a single port to operate 1038 as multiple IPv4 and/or IPv6 logical ports. Each IP address 1039 constitutes a different logical port and the RBridge with those ports 1040 MUST associate a different Port ID (see Section 4.4.2 of [RFC6325]) 1041 with each logical port. 1043 By default a TRILL over IP port discards output packets that fail the 1044 possible recursive ingress test (see Section 10.1) unless configured 1045 to disable that test. 1047 9.2 Additional per IP Address Configuration 1049 The configuration information specified below is per TRILL over IP 1050 port IP address. 1052 The mapping from TRILL packet priority to Differentiated Services 1053 Code Point (DSCP [RFC2474]) can be configured (see Section 10.5). 1055 Each TRILL over IP port has a list of acceptable encapsulations it 1056 will use. By default this list consists of one entry for native 1057 encapsulation (see Section 7). Additional encapsulations MAY be 1058 configured. Additional configuration can be required or possible for 1059 specific encapsulations as described in Section 9.2.3. 1061 Each IP address at a TRILL over IP port uses native IP multicast by 1062 default but may be configured whether to use serial IP unicast 1063 (Section 9.2.2) or native IP multicast (Section 9.2.1). Each IP 1064 address at a TRILL over IP is configured whether or not to use IPsec 1065 (Section 9.2.4). 1067 9.2.1 Native Multicast Configuration 1069 If a TRILL over IP port address is using native IP multicast for 1070 multi-destination TRILL packets (IS-IS and data), by default 1071 transmissions from that IP address use the IP multicast address (IPv4 1072 or IPv6) specified in Section 11.2. The TRILL over IP port may be 1073 configured to use a different IP address to multicast packets. 1075 9.2.2 Serial Unicast Configuration 1077 If a TRILL over IP port address has been configured to use serial 1078 unicast for multi-destination packets (IS-IS and data), it should 1079 have associated with it a non-empty list of unicast IP destination 1080 addresses with the same IP version as the version of the port's IP 1081 address (IPv4 or IPv6). Multi-destination TRILL packets are serially 1082 unicast to the addresses in this list. Such a TRILL over IP port will 1083 only be able to form adjacencies [RFC7177] with the RBridges at the 1084 addresses in this list as those are the only RBridges to which it 1085 will send TRILL Hellos. 1087 If this list of destination IP addresses is empty, there is no way to 1088 transmit a multi-destination TRILL over IP packet such as a TRILL 1089 Hello. Thus it is impossible to achieve adjacency [RFC7177] or if 1090 adjacency had been achieved (perhaps the list was non-empty and has 1091 just been configured to be empty), no way to maintain such adjacency. 1092 Thus, in the empty list case, TRILL Data multi-destination packets 1093 cannot be sent and TRILL Data unicast packets will not start flowing 1094 or, if they are already flowing, will soon cease, effectively 1095 disabling the port. 1097 9.2.3 Encapsulation Specific Configuration 1099 Specific TRILL over IP encapsulation methods may provide for further 1100 configuration as specified below. 1102 9.2.3.1 VXLAN Configuration 1104 A TRILL over IP port using VXLAN encapsulation can be configured with 1105 a non-default VXLAN Network Identifier (VNI) that is used in that 1106 field of the VXLAN header for all TRILL packets sent using the 1107 encapsulation and required in all TRILL packets received using the 1108 encapsulation. The default VNI is 1. A TRILL packet received with the 1109 wrong VNI is discarded. 1111 A TRILL over IP port using VXLAN encapsulation can also be configured 1112 to map the Inner.VLAN or Inner.FGL of a TRILL Data packet being 1113 transported to the value it places in the VNI field. 1115 9.2.3.2 Other Encapsulation Configuration 1117 Additional encapsulation methods, beyond the native UDP encapsulation 1118 and VXLAN encapsulation specified in this document, may be specified 1119 in future documents and may require further configuration. 1121 9.2.4 Security Configuration 1123 tbd ... 1125 10. Security Considerations 1127 TRILL over IP is subject to all of the security considerations for 1128 the base TRILL protocol [RFC6325]. In addition, there are specific 1129 security requirements for different TRILL deployment scenarios, as 1130 discussed in the "Use Cases for TRILL over IP" section above. 1132 For communication between end stations in a TRILL campus, security is 1133 possible at three levels: end-to-end security between those end 1134 stations, edge-to-edge security between ingress and egress RBridges 1135 [LinkSec], and link security to protect a TRILL hop. Any combination 1136 of these can be used, including all three. 1138 TRILL over IP link security protects the contents of TRILL Data and 1139 IS-IS packets, including the identities of the end stations for data 1140 and the identities of the edge RBridges, from observers of the link 1141 and transit devices within the link such as IP routers, but does not 1142 encrypt the link local IP addresses used in a packet and does not 1143 protect against observation by the sending and receiving RBridges on 1144 the link. Edge-to-edge TRILL security protects the contents of TRILL 1145 data packets including the identities of the end stations for data 1146 from transit RBridges but does not encrypt the identities of the edge 1147 RBridges involved and does not protect against observation by those 1148 edge RBridges. End-to-end security does not protect the identities of 1149 the end stations or edge RBridge involved but does protect the 1150 content of TRILL data packets from observation by all RBridges or 1151 other intervening devices between the end stations involved. End-to- 1152 end security should always be considered as an added layer of 1153 security and to protect any particularly sensitive information from 1154 unintended disclosure. 1156 If VXLAN encapsulation is used, the unused Ethernet source and 1157 destination MAC addresses mentioned in Section 5.5, provide a 96 bit 1158 per packet covert path. 1160 10.1 IPsec 1162 This document specifies that all RBridges that support TRILL over IP 1163 links MUST implement IPsec for the security of such links, and makes 1164 it clear that it is both wise and good to use IPsec in all cases 1165 where a TRILL over IP link will traverse a network that is not under 1166 the same administrative control as the rest of the TRILL campus or is 1167 not physically secure. IPsec is important, in these cases, to protect 1168 the privacy and integrity of data traffic. However, in cases where 1169 IPsec is impractical due to lack of fast path support, use of TRILL 1170 edge-to-edge security or use by the end stations of end-to-end 1171 security can provide significant security. 1173 Further Security Considerations for IPsec ESP and for the 1174 cryptographic algorithms used with IPsec can be found in the RFCs 1175 referenced by this document. 1177 10.2 IS-IS Security 1179 TRILL over IP is compatible with the use of IS-IS Security [RFC5310], 1180 which can be used to authenticate TRILL switches before allowing them 1181 to join a TRILL campus. This is sufficient to protect against rogue 1182 devices impersonating TRILL switches, but is not sufficient to 1183 protect data packets that may be sent in TRILL over IP outside of the 1184 local network or across the public Internet. To protect the privacy 1185 and integrity of that traffic, use IPsec. 1187 In cases were IPsec is used, the use of IS-IS security may not be 1188 necessary, but there is nothing about this specification that would 1189 prevent using both IPsec and IS-IS security together. 1191 11. IANA Considerations 1193 IANA considerations are given below. 1195 11.1 Port Assignments 1197 IANA is requested to assign destination UDP Ports for the TRILL IS-IS 1198 and Data channels: 1200 UDP Port Protocol 1201 ---------- --------------------- 1202 (TBD1) TRILL IS-IS Channel 1203 (TBD2) TRILL Data Channel 1205 11.2 Multicast Address Assignments 1207 IANA is requested to one IPv4 and one IPv6 multicast address, as 1208 shown below, which correspond to the All-RBridges and All-IS-IS- 1209 RBridges multicast MAC addresses that the IEEE Registration Authority 1210 has assigned for TRILL. Because the low level hardware MAC address 1211 dispatch considerations for TRILL over Ethernet do not apply to TRILL 1212 over IP, one IP multicast address for each version of IP is 1213 sufficient. 1215 (Values recommended to IANA in square brackets) 1217 Name IPv4 IPv6 1218 ------------ ------------------ -------------------------- 1219 All-RBridges TBD3[233.252.14.0] TBD4[FF0X:0:0:0:0:0:0:205] 1221 The hex digit "X" in the IPv6 address indicates the scope and 1222 defaults to 8. The IPv6 All-RBridges IP address may be used with 1223 other values of X. 1225 11.3 Encapsulation Method Support Indication 1227 The existing "RBridge Channel Protocols" registry is re-named and a 1228 new sub-registry under that registry added as follows: 1230 The TRILL Parameters registry for "RBridge Channel Protocols" is 1231 renamed the "RBridge Channel Protocols and Link Technology Specific 1232 Flags" registry. [this document] is added as a second reference for 1233 this registry. The first part of the table is changed to the 1234 following: 1236 Range Registration Note 1237 ----------- ---------------- ---------------------------- 1238 0x002-0x0FF Standards Action 1239 0x100-0xFCF RFC Required allocation of a single value 1240 0x100-0xFCF IESG Approval allocation of multiple values 1241 0xFD0 0xFF7 see Note link technology dependent, 1242 see subregistry 1244 In the existing table of RBridge Channel Protocols, the following 1245 line is changed to two lines as shown: 1247 OLD 1248 0x004-0xFF7 Unassigned 1249 NEW 1250 0x004-0xFCF Unassigned 1251 0xFD0-0xFF7 (link technology dependent, see subregistry) 1253 A new subregistry under the re-named "RBridge Channel Protocols and 1254 Link Technology Specific Flags" registry is added as follows: 1256 Name: TRILL over IP Link Flags 1257 Registration Procedure: IETF Review 1258 Reference: [this document] 1260 Flag Meaning Reference 1261 ----------- ------------------------------ --------- 1262 0xFD0 Native encapsulation supported [this document] 1263 0xFD1 VXLAN encapsulation supported [this document] 1264 0xFD2-0xFF7 Unassigned 1266 Normative References 1268 [IS-IS] - "Intermediate system to Intermediate system routeing 1269 information exchange protocol for use in conjunction with the 1270 Protocol for providing the Connectionless-mode Network Service 1271 (ISO 8473)", ISO/IEC 10589:2002, 2002". 1273 [RFC0020] - Cerf, V., "ASCII format for network interchange", STD 80, 1274 RFC 20, DOI 10.17487/RFC0020, October 1969, . 1277 [RFC0768] - Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 1278 10.17487/RFC0768, August 1980, . 1281 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1282 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1283 March 1997, . 1285 [RFC2474] - Nichols, K., Blake, S., Baker, F., and D. Black, 1286 "Definition of the Differentiated Services Field (DS Field) in 1287 the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, 1288 December 1998, . 1290 [RFC2710] - Deering, S., Fenner, W., and B. Haberman, "Multicast 1291 Listener Discovery (MLD) for IPv6", RFC 2710, DOI 1292 10.17487/RFC2710, October 1999, . 1295 [RFC2914] - Floyd, S., "Congestion Control Principles", BCP 41, RFC 1296 2914, DOI 10.17487/RFC2914, September 2000, . 1299 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1300 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 1301 10.17487/RFC3168, September 2001, . 1304 [RFC3376] - Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1305 Thyagarajan, "Internet Group Management Protocol, Version 3", 1306 RFC 3376, DOI 10.17487/RFC3376, October 2002, . 1309 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 1310 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 1311 2005, . 1313 [RFC4303] - Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1314 4303, DOI 10.17487/RFC4303, December 2005, . 1317 [RFC5405] - Li, T. and R. Atkinson, "IS-IS Cryptographic 1318 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, 1319 . 1321 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1322 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1323 5310, DOI 10.17487/RFC5310, February 2009, . 1326 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 1327 Expand Key Derivation Function (HKDF)", RFC 5869, DOI 1328 10.17487/RFC5869, May 2010, . 1331 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1332 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1333 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 1334 . 1336 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1337 D., and A. Banerjee, "Transparent Interconnection of Lots of 1338 Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, 1339 May 2014, . 1341 [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., 1342 and V. Manral, "Transparent Interconnection of Lots of Links 1343 (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, 1344 . 1346 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1347 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1348 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 1349 2014, . 1351 [RFC7321] - McGrew, D. and P. Hoffman, "Cryptographic Algorithm 1352 Implementation Requirements and Usage Guidance for 1353 Encapsulating Security Payload (ESP) and Authentication Header 1354 (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, 1355 . 1357 [RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1358 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1359 eXtensible Local Area Network (VXLAN): A Framework for 1360 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 1361 RFC 7348, DOI 10.17487/RFC7348, August 2014, . 1364 [rfc7180bis] - Eastlake, D., et al, "TRILL: Clarifications, 1365 Corrections, and Updates", draft-ietf-trill-rfc7180bis, work in 1366 progress. 1368 Informative References 1370 [RFC4787] - Audet, F., Ed., and C. Jennings, "Network Address 1371 Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 1372 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, 1373 . 1375 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 1376 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 1377 10.17487/RFC6234, May 2011, . 1380 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 1381 Interconnection of Lots of Links (TRILL) Protocol Control 1382 Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, 1383 . 1385 [RFC6864] - Touch, J., "Updated Specification of the IPv4 ID Field", 1386 RFC 6864, DOI 10.17487/RFC6864, February 2013, . 1389 [RFC6936] - Fairhurst, G. and M. Westerlund, "Applicability Statement 1390 for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 1391 6936, DOI 10.17487/RFC6936, April 2013, . 1394 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1395 and D. Dutt, "Transparent Interconnection of Lots of Links 1396 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 1397 10.17487/RFC7172, May 2014, . 1400 [RFC7173] - Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, 1401 "Transparent Interconnection of Lots of Links (TRILL) Transport 1402 Using Pseudowires", RFC 7173, DOI 10.17487/RFC7173, May 2014, 1403 . 1405 [RFC7296] - Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1406 Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", 1407 STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, 1408 . 1410 [circuit-breaker] - Fairhurst, G., "Network Transport Circuit 1411 Breakers", draft-ietf-tsvwg-circuit-breaker, work in progress. 1413 [gre-in-udp] - Crabbe, E., Yong, L., and X. Xu, "Generic UDP 1414 Encapsulation for IP Tunneling", draft-yong-tsvwg-gre-in-udp- 1415 encap, work in progress. 1417 [LinkSec] - Eastlake, D., D. Zhang, "TRILL: Link Security", draft- 1418 eastlake-trill-link-security, work in progress. 1420 Acknowledgements 1422 The following people have provided useful feedback on the contents of 1423 this document: Sam Hartman, Adrian Farrel, and Mohammed Umair. 1425 Some material in Section 10.2 is derived from draft-ietf-mpls-in-udp 1426 by Xiaohu Xu, Nischal Sheth, Lucy Yong, Carlos Pignataro, and 1427 Yongbing Fan. 1429 The document was prepared in raw nroff. All macros used were defined 1430 within the source file. 1432 Authors' Addresses 1434 Margaret Cullen 1435 Painless Security 1436 356 Abbott Street 1437 North Andover, MA 01845 1438 USA 1440 Phone: +1 781 405-7464 1441 Email: margaret@painless-security.com 1442 URI: http://www.painless-security.com 1444 Donald Eastlake 1445 Huawei Technologies 1446 155 Beaver Street 1447 Milford, MA 01757 1448 USA 1450 Phone: +1 508 333-2270 1451 Email: d3e3e3@gmail.com 1453 Mingui Zhang 1454 Huawei Technologies 1455 No.156 Beiqing Rd. Haidian District, 1456 Beijing 100095 P.R. China 1458 EMail: zhangmingui@huawei.com 1460 Dacheng Zhang 1461 Alibaba 1462 Beijing, Chao yang District 1463 P.R. China 1465 Email: dacheng.zdc@alibaba-inc.com 1467 Copyright, Disclaimer, and Additional IPR Provisions 1469 Copyright (c) 2015 IETF Trust and the persons identified as the 1470 document authors. All rights reserved. 1472 This document is subject to BCP 78 and the IETF Trust's Legal 1473 Provisions Relating to IETF Documents 1474 (http://trustee.ietf.org/license-info) in effect on the date of 1475 publication of this document. Please review these documents 1476 carefully, as they describe your rights and restrictions with respect 1477 to this document. Code Components extracted from this document must 1478 include Simplified BSD License text as described in Section 4.e of 1479 the Trust Legal Provisions and are provided without warranty as 1480 described in the Simplified BSD License.