idnits 2.17.1 draft-ietf-trill-channel-tunnel-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 18, 2016) is 2953 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 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Updates: 7178 Huawei 3 Intended status: Proposed Standard Mohammed Umair 4 IPinfusion 5 Yizhou Li 6 Huawei 7 Expires: September 1, 2016 March 18, 2016 9 TRILL: RBridge Channel Tunnel Protocol 10 12 Abstract 14 The IETF TRILL (Transparent Interconnection of Lots of Links) 15 protocol includes an optional mechanism (specified in RFC 7178), 16 called RBridge Channel, for the transmission of typed messages 17 between TRILL switches in the same campus and the transmission of 18 such messages between TRILL switches and end stations on the same 19 link. This document specifies two optional extensions to the RBridge 20 Channel protocol: (1) a standard method to tunnel a variety of 21 payload types by encapsulating them in an RBridge Channel message; 22 and (2) a method to support security facilities for RBridge Channel 23 messages. This document updates RFC 7178. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Distribution of this document is unlimited. Comments should be sent 31 to the authors or the TRILL working group mailing list: 32 trill@ietf.org 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 46 Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Table of Contents 51 1. Introduction............................................3 52 1.1 Terminology and Acronyms..............................3 54 2. Channel Tunnel Packet Format............................5 56 3. Channel Tunnel Payload Types............................8 57 3.1 Null Payload...........................................8 58 3.2 Ethertyped Payload.....................................8 59 3.2.1 Tunneled RBridge Channel Message.....................9 60 3.2.2 Tunneled TRILL Data Packet...........................9 61 3.2.3 Tunneled TRILL IS-IS Packet.........................10 62 3.3 Ethernet Frame........................................11 64 4. Security, Keying, and Algorithms.......................14 65 4.1 Basic Security Information Format.....................14 66 4.2 Authentication and Encryption Coverage................15 67 4.3 Derived Keying Material...............................17 68 4.4 SType None............................................17 69 4.5 RFC 5310 Based Authentication.........................17 70 4.6 DTLS Pairwise Security................................18 72 5. Channel Tunnel Errors..................................20 73 5.1 SubERRs under ERR 6...................................20 74 5.2 Secure Nested RBridge Channel Errors..................20 76 6. IANA Considerations....................................21 77 6.1 Channel Tunnel RBridge Channel Protocol Number........21 78 6.2 RBridge Channel Error Codes Subregistry...............21 80 7. Security Considerations................................22 82 Normative References......................................23 83 Informative References....................................24 85 Appendix Z: Change History................................25 87 Acknowledgements..........................................27 88 Authors' Addresses........................................28 90 1. Introduction 92 The IETF TRILL base protocol [RFC6325] [RFC7780] has been extended 93 with the RBridge Channel [RFC7178] facility to support transmission 94 of typed messages (for example BFD (Bidirectional Forwarding 95 Detection) [RFC7175]) between two TRILL switches (RBridges) in the 96 same campus and the transmission of such messages between RBridges 97 and end stations on the same link. When sent between RBridges in the 98 same campus, a TRILL Data packet with a TRILL Header is used and the 99 destination RBridge is indicated by nickname. When sent between a 100 RBridge and an end station on the same link in either direction a 101 native RBridge Channel messages [RFC7178] is used with no TRILL 102 Header and with the destination port or ports are indicated by a MAC 103 address. (There is no mechanism to stop end stations on the same 104 link, from sending native RBridge Channel messages to each other; 105 however, such use is outside the scope of this document.) 107 This document updates [RFC7178] and specifies extensions to RBridge 108 Channel that provide two additional facilities as follows: 110 (1) A standard method to tunnel a variety of payload types by 111 encapsulating them in an RBridge Channel message. 113 (2) A method to provide security facilities for RBridge Channel 114 messages. 116 Use of each of these facilities is optional, except that if Channel 117 Tunnel is implemented there are two payload types that MUST be 118 implemented. Both of the above facilities can be used in the same 119 packet. In case of conflict between this document and [RFC7178], this 120 document takes precedence. 122 1.1 Terminology and Acronyms 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in 127 [RFC2119]. 129 This document uses terminology and acronyms defined in [RFC6325] and 130 [RFC7178]. Some of these are repeated below for convenience along 131 with additional new terms and acronyms. 133 Data Label - VLAN or FGL. 135 DTLS - Datagram Transport Level Security [RFC6347]. 137 FCS - Frame Check Sequence. 139 FGL - Fine Grained Label [RFC7172]. 141 HKDF - Hash based Key Derivation Function [RFC5869]. 143 IS-IS - Intermediate System to Intermediate Systems [IS-IS]. 145 PDU - Protocol Data Unit. 147 RBridge - An alternative term for a TRILL switch. 149 SHA - Secure Hash Algorithm [RFC6234]. 151 Sz - Campus wide minimum link MTU [RFC6325] [RFC7780]. 153 TRILL - Transparent Interconnection of Lots of Links or Tunneled 154 Routing in the Link Layer. 156 TRILL switch - A device that implements the TRILL protocol 157 [RFC6325], sometimes referred to as an RBridge. 159 2. Channel Tunnel Packet Format 161 The general structure of an RBridge Channel message between two TRILL 162 switches (RBridges) in the same campus is shown in Figure 2.1 below. 163 The structure of a native RBridge Channel message sent between an 164 RBridge and an end station on the same link, in either direction, is 165 shown in Figure 2.2 and, compared with the first case, omits the 166 TRILL Header, inner Ethernet addresses, and Data Label. A Protocol 167 field in the RBridge Channel Header gives the type of RBridge Channel 168 message and indicates how to interpret the Channel Protocol Specific 169 Payload [RFC7178]. 171 +-----------------------------------+ 172 | Link Header | 173 +-----------------------------------+ 174 | TRILL Header | 175 +-----------------------------------+ 176 | Inner Ethernet Addresses | 177 +-----------------------------------+ 178 | Data Label (VLAN or FGL) | 179 +-----------------------------------+ 180 | RBridge Channel Header | 181 +-----------------------------------+ 182 | Channel Protocol Specific Payload | 183 +-----------------------------------+ 184 | Link Trailer (FCS if Ethernet) | 185 +-----------------------------------+ 187 Figure 2.1 RBridge Channel Packet Structure 189 +-----------------------------------+ 190 | Ethernet Link Header | 191 +-----------------------------------+ 192 | RBridge Channel Header | 193 +-----------------------------------+ 194 | Channel Protocol Specific Payload | 195 +-----------------------------------+ 196 | FCS | 197 +-----------------------------------+ 199 Figure 2.2 Native RBridge Channel Frame 201 The RBridge Channel Header looks like this: 203 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | 0x8946 | CHV=0 | Channel Protocol | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Flags | ERR | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 210 / Channel Protocol Specific Data / 211 /-+-+-+-+-+- / 213 Figure 2.3 RBridge Channel Header 215 where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel 216 Header Version. This document is based on RBridge Channel version 217 zero. 219 The extensions specified herein are in the form of an RBridge Channel 220 protocol, the Channel Tunnel Protocol. Figure 2.4 below expands the 221 RBridge Channel Header and Protocol Specific Payload above for the 222 case of the Channel Tunnel Protocol. 224 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 225 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 226 RBridge Channel Header: 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | 0x8946 | CHV=0 | Tunnel Protocol = TBD | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Flags | ERR | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Channel Tunnel Protocol Specific: | SubERR| RESV4 | SType | PType | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Security Information, variable length (0 length if SType = 0) / 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 237 | Tunneled Data, variable length 238 | ... 240 Figure 2.4 Channel Tunnel Header Structure 242 The RBridge Channel Header field specific to the RBridge Channel 243 Tunnel Protocol is the Protocol field. Its contents MUST be the value 244 allocated for this purpose (see Section 6). 246 The RBridge Channel Tunnel Protocol Specific Data fields are as 247 follows: 249 SubERR: This field provides further details when a Channel Tunnel 250 error is indicated in the RBridge Channel ERR field. If ERR is 251 zero, then SubERR MUST be sent as zero and ignored on receipt. 252 See Section 5. 254 RESV4: This field MUST be sent as zero. If non-zero when received, 255 this is an error condition (see Section 5). 257 SType: This field describes the type of security information and 258 features, including keying material, being used or provided by 259 the Channel Tunnel packet. See Section 4. 261 PType: Payload type. This describes the tunneled data. See Section 262 3 below. 264 Security Information: Variable length information. Length is zero 265 if SType is zero. See Section 4. 267 The Channel Tunnel protocol is integrated with the RBridge Channel 268 facility. Channel Tunnel errors are reported as if they were RBridge 269 Channel errors, using newly allocated code points in the ERR field of 270 the RBridge Channel Header supplemented by the SubERR field. 272 3. Channel Tunnel Payload Types 274 The Channel Tunnel Protocol can carry a variety of payloads as 275 indicated by the PType field. Values are shown in the table below 276 with further explanation after the table. 278 PType Section Description 279 ----- ------- ----------- 280 0 Reserved 281 1 3.1 Null 282 2 3.2 Ethertyped Payload 283 3 3.3 Ethernet Frame 284 4-14 Unassigned 285 15 Reserved 287 Table 3.1 Payload Type Values 289 While implementation of the Channel Tunnel protocol is optional, if 290 it is implemented PType 1 (Null) MUST be implemented and PType 2 291 (Ethertyped Payload) with the RBridge Channel Ethertype MUST be 292 implemented. PType 2 for any Ethertypes other than the RBridge 293 Channel Ethertype MAY be implemented. PType 3 MAY be implemented. 295 The processing of any particular Channel Protocol message and its 296 payload depends on meeting local security and other policy at the 297 destination TRILL switch or end station. 299 3.1 Null Payload 301 The Null payload type (PType = 1) is intended to be used for testing 302 or for messages such as key negotiation or the like where only 303 security information is present. It indicates that there is no 304 payload. Any data after the Security Information field is ignored. If 305 the Channel Tunnel feature is implemented, Null Payload MUST be 306 supported in the sense that an "Unsupported PType" error is not 307 returned (see Section 5). Any particular use of the Null Payload 308 should specify what VLAN or priority should be used when relevant. 310 3.2 Ethertyped Payload 312 A PType of 2 indicates that the payload of the Channel Tunnel message 313 begins with an Ethertype. A TRILL switch supporting the Channel 314 Tunnel protocol MUST support a PType of 2 with a payload beginning 315 with the RBridge Channel Ethertype as describe in Section 3.2.1. 316 Other Ethertypes, including the TRILL and L2-IS-IS Ethertypes as 317 described in Section 3.2.2 and 3.2.3, MAY be supported. 319 3.2.1 Tunneled RBridge Channel Message 321 A PType of 2 with an initial RBridge Channel Ethertype indicates an 322 encapsulated RBridge Channel message payload. A typical reason for 323 sending an RBridge Channel message inside a Channel Tunnel message is 324 to provide security services, such as authentication or encryption. 326 This payload type looks like the following: 328 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 / Security Information, variable length (0 length if SType = 0) / 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol| 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Flags | ERR | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 341 | Nested Channel Protocol Specific Data ... / 342 / / 344 Figure 3.1 Tunneled RBridge Channel Message Structure 346 3.2.2 Tunneled TRILL Data Packet 348 A PType of 2 and an initial TRILL Ethertype indicates that the 349 payload of the Tunnel protocol message is an encapsulated TRILL Data 350 packet as shown in the figure below. If this Ethertype is supported 351 for PType = 2 and the message meets local policy for acceptance, the 352 tunneled TRILL Data packet is handled as if it had been received by 353 the destination TRILL switch on the port where the Channel Tunnel 354 message was received. 356 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 / Security Information, variable length (0 length if SType = 0) / 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Egress Nickname | Ingress Nickname | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 / Optional Flags Word / 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Inner.MacDA | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Inner.MacDA continued | Inner.MacSA | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Inner.MacSA (cont.) | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Inner Data Label (2 or 4 bytes) 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 379 | TRILL Data Packet payload 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 382 Figure 3.2 Nested TRILL Data Packet Channel Tunnel Structure 384 The optional flags word is only present if the F bit in the TRILL 385 Header is one [RFC7780]. 387 3.2.3 Tunneled TRILL IS-IS Packet 389 A PType of 2 and an initial L2-IS-IS Ethertype indicates that the 390 payload of the Tunnel protocol message is an encapsulated TRILL IS-IS 391 PDU as shown in Figure 3.3. If this Ethertype is supported for PType 392 = 2, the tunneled TRILL IS-IS packet is processed by the destination 393 RBridge if it meets local policy. One possible use is to expedite the 394 receipt of a link state PDU (LSP) by some TRILL switch or switches 395 with an immediate requirement for the link state information. A link 396 local IS-IS PDU (Hello, CSNP, or PSNP [IS-IS]; MTU-probe or MTU-ack 397 [RFC7176]; or circuit scoped FS-LSP, FS-CSNP or FS-PSNP [RFC7356]) 398 would not normally be sent via this Channel Tunnel method except 399 possibly to encrypt it since such PDUs can just be transmitted on the 400 link and do not normally need RBridge Channel tunneling. 402 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 / Security Information, variable length (0 length if SType = 0) / 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 411 | L2-IS-IS (0x22F4) | 0x83 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | rest of IS-IS PDU 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 416 Figure 3.3 Tunneled TRILL IS-IS Packet Structure 418 3.3 Ethernet Frame 420 If PType is 3, the Tunnel Protocol payload is an Ethernet frame as 421 might be received from or sent to an end station except that the 422 tunneled Ethernet frame's FCS is omitted, as shown in Figure 3.4. 423 (There is still an overall final FCS if the RBridge Channel message 424 is being sent on an Ethernet link.) If this PType is implemented and 425 the message meets local policy, the tunneled frame is handled as if 426 it had been received on the port on which the Channel Tunnel message 427 was received. 429 The priority of the RBridge Channel message can be copied from the 430 Ethernet frame VLAN tag, if one is present, except that priority 7 431 SHOULD only be used for messages critical to establishing or 432 maintaining adjacency and priority 6 SHOULD only be used for other 433 important control messages. 435 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol = TBD | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Flags | ERR | SubERR| RESV4 | SType | 0x3 | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 / Security Information, variable length (0 length if SType = 0) / 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | MacDA | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | MacDA (cont.) | MacSA | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | MacSA (cont.) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Any Ethernet frame tagging... 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 452 | Ethernet frame payload... 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 455 Figure 3.4 Ethernet Frame Channel Tunnel Structure 457 In the case of a non-Ethernet link, such as a PPP (Point-to-Point 458 Protocol) link [RFC6361], the ports on the link are considered to 459 have link local synthetic 48-bit MAC addresses constructed as 460 described below. These constructed addresses MAY be used as a MacSA. 461 If the RBridge Channel message is link local, the source TRILL switch 462 will have the information to construct such a MAC address for the 463 destination TRILL switch port and that MAC address MAY be used as the 464 MacDA. By the use of such a MacSA and either such a unicast MacDA or 465 a group addressed MacDA, an Ethernet frame can be sent between two 466 TRILL switch ports connected by a non-Ethernet link. 468 These synthetic TRILL switch port MAC addresses for non-Ethernet 469 ports are constructed as follows: 0xFEFF, the nickname of the TRILL 470 switch used in TRILL Hellos sent on that port, and the Port ID that 471 the TRILL switch has assigned to that port, as shown in Figure 3.5. 472 (Both the Port ID of the port on which a TRILL Hello is sent and the 473 nickname of the sending TRILL switch appear in the Special VLANs and 474 Flags sub-TLV [RFC7176] in TRILL IS-IS Hellos.) The resulting MAC 475 address has the Local bit on and the Group bit off [RFC7042]. 476 However, since there will be no Ethernet end stations on a non- 477 Ethernet link in a TRILL campus, such synthetic MAC addresses cannot 478 conflict on the link with a real Ethernet port address. 480 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | 0xFEFF | Nickname | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Port ID | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 3.5 Synthetic MAC Address 490 4. Security, Keying, and Algorithms 492 Table 4.1 below gives the assigned values of the SType field and 493 their meaning. Use of DTLS Pairwise Security (SType = 2) is 494 RECOMMENDED. While [RFC5310] based authentication applies to both 495 pairwise and multi-destination traffic, it provides only 496 authentication and is generally considered not to met current 497 security standards, as it does not provide for key negotiation; thus, 498 its use is NOT RECOMMENDED. 500 Channel Tunnel DTLS based security specified in Section 4.6 below is 501 intended for pairwise (known unicast) use in which case the M bit in 502 the TRILL Header would be zero and in the native RBridge Channel case 503 (Figure 2.2) the Outer.MacDA would be individually addressed. 505 Multi-destination Channel Tunnel packets would be those with the M 506 bit in the TRILL Header set to one or, in the native RBridge Channel 507 case, the Outer.MacDA would be group addressed. However, the DTLS 508 Pairwise Security SType can be used in the multi-destination case by 509 serially unicasting the messages to all data accessible RBridges (or 510 end stations in the native RBridge Channel case) in the recipient 511 group. For TRILL Data packets, that group is specified by the Data 512 Label; for native frames, the group is specified by the groupcast 513 destination MAC address. It is intended to specify a true group keyed 514 SType to secure multi-destination packets in a separate document 515 [GroupKey]. 517 SType Section Meaning 518 ----- ------- ------- 519 0 4.4 None 520 1 4.5 [RFC5310] Based Authentication 521 2 4.6 DTLS Pairwise Security 522 3-14 Available for assignment by IETF Review 523 15 Reserved 525 Table 4.1 SType Values 527 4.1 Basic Security Information Format 529 When SType is zero, there is no Security Information after the 530 Channel Tunnel header and before the payload. For all SType values 531 except zero, the Security Information starts with four reserved flag 532 bits and twelve bits of remaining length as follows: 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 535 | RESV | Size | More Info 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 538 Figure 4.1 Security Information Format 540 The fields are as follows: 542 RESV: Four reserved bits that MUST be sent as zero and ignored on 543 receipt. In the future, meanings may be assigned to these bits and 544 those meanings may differ for different STypes. 546 Size: The number of bytes, as an unsigned integer, of More Info in 547 the Security Information after the Size byte itself. Thus the 548 maximum possible length of Security Information is 4,097 bytes for 549 a Size of 4,095 plus 2 for the RESV and Size fields. 551 More Info: Additional Security Information of length Size. Contents 552 depends on the SType. 554 4.2 Authentication and Encryption Coverage 556 As show in Figure 4.2, the area covered by Channel Tunnel 557 authentication starts with the byte immediately after the TRILL 558 Header optional Flag Word if it is present. Otherwise, it starts 559 after the TRILL Header Ingress Nickname. In either case, it extends 560 to just before the TRILL Data packet link trailer. For example, for 561 an Ethernet packet it would extend to just before the FCS. 563 +-----------------------------+ 564 | Link Header | 565 +-----------------------------+ 566 | TRILL Header | 567 | (plus optional flag word) | 568 +-----------------------------+ ^ 569 | Inner Ethernet Addresses | | <-authentication 570 +-----------------------------+ . 571 | Data Label (VLAN or FGL) | | 572 +-----------------------------+ . 573 | RBridge Channel Header | | 574 +-----------------------------+ . 575 | Channel Tunnel Header | | 576 | (Security Information) | . 577 +-----------------------------+ | ^ 578 | Payload | . | <-encryption 579 +-----------------------------+ v v 580 | Link Trailer | 581 +-----------------------------+ 583 Figure 4.2. Channel Tunnel Security Coverage 585 Channel Tunnel authentication in the native RBridge Channel case (see 586 Figure 4.3), is as specified in the above paragraph except that it 587 starts with the RBridge Channel Ethertype, since there is no TRILL 588 Header, inner Ethernet addresses, or inner Data Label. 590 +-----------------------------+ 591 | Ethernet Header | 592 +-----------------------------+ ^ 593 | RBridge Channel Header | | <-authentication 594 +-----------------------------+ . 595 | Channel Tunnel Header | | 596 | (plus Security Information)| . 597 +-----------------------------+ | ^ 598 | Payload | . | <-encryption 599 +-----------------------------+ v v 600 | Ethernet Trailer | 601 +-----------------------------+ 603 Figure 4.3. Native Channel Tunnel Security Coverage 605 If an authentication value is included in the More Info field shown 606 in Section 4.1, it is treated as zero when authentication is 607 calculated. If an authentication value is included in a payload after 608 the security information, it is calculated as provided by the SType 609 and security algorithms in use. 611 If encryption is provided, it covers the payload from right after the 612 Channel Tunnel header Security Information through to just before the 613 TRILL Data packet link trailer (see Figures 4.2 and 4.3). 615 4.3 Derived Keying Material 617 In some cases, it is possible to use material derived from [RFC5310] 618 IS-IS keying material as an element of Channel Tunnel security. In 619 such cases, the More Info field shown in Figure 4.1 includes the two 620 byte IS-IS Key ID to identify the keying material. It is assumed that 621 the IS-IS keying material is of high quality. The material actually 622 used in Channel Tunnel security is derived from the IS-IS keying 623 material as follows: 625 Derived Material = 626 HKDF-Expand-SHA256 ( IS-IS-key, "Channel Tunnel" | 0x0S, L ) 628 where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is 629 as in [RFC6234], IS-IS-key is the input IS-IS keying material, 630 "Channel Tunnel" is the 14-character ASCII [RFC20] string indicated 631 without any leading length byte or trailing zero byte, 0x0S is a 632 single byte where S is the SType for which this key derivation is 633 being used and the upper nibble is zero, and L is the length of 634 output-derived material needed. 636 Whenever IS-IS keying material is being used as above, the underlying 637 [RFC5310] keying material might expire or become invalidated. At the 638 time of or before such expiration or invalidation, the use Derived 639 Material from the IS-IS keying material MUST cease. Continued 640 security may depend on using new derived material from currently 641 valid [RFC5310] keying material. 643 4.4 SType None 645 No security services are being invoked. The length of the Security 646 Information field (see Figure 2.4) is zero. 648 4.5 RFC 5310 Based Authentication 650 The Security Information (see Figure 2.4) is the RESV and Size fields 651 specified in Section 4.1 with the value of the [RFC5310] Key ID and 652 Authentication Data, as shown in Figure 4.4. 654 1 1 1 1 1 1 655 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | RESV | Size | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Key ID | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | | 662 + 663 | Authentication Data (Variable) 664 + 665 | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-... 668 Figure 4.4 SType 1 Security Information 670 o RESV: Four bits that MUST be sent as zero and ignored or receipt. 672 o Size: Set to 2 + the size of Authentication Data in bytes. 674 o Key ID: specifies the keying value and authentication algorithm 675 that the Key ID specifies for TRILL IS-IS LSP [RFC5310] 676 Authentication TLVs. The keying material actually used is derived 677 as shown in Section 4.3. 679 o Authentication Data: The authentication data produced by the 680 derived key and algorithm associated with the Key ID acting on the 681 packet as specified in Section 4.2. Length of the authentication 682 data depends on the algorithm. 684 While RBridges, which are IS-IS routers, can reasonable be expected 685 to hold [RFC5310] keying, so that this SType can be used for RBridge 686 Channel messages, how end stations might come to hold [rfc5310] 687 keying is beyond the scope of this document. Thus this SType might 688 not be applicable to native RBridge Channel messages. 690 4.6 DTLS Pairwise Security 692 DTLS supports key negotiation and provides both encryption and 693 authentication. The Channel Tunnel DTLS [RFC6347] SType uses a 694 negotiated DTLS version that MUST NOT be less than 1.2. 696 When DTLS pairwise security is used, the entire payload of the 697 Channel Tunnel packet, starting just after the Security Information 698 and ending just before the link trailer, is one or more DTLS records 699 [RFC6347]. As specified in [RFC6347], DTLS records MUST be limited 700 by the path MTU, in this case so each record fits entirely within a 701 single Channel Tunnel message. A minimum path MTU can be determined 702 from the TRILL campus wide minimum MTU Sz, which will not be less 703 than 1470 bytes, by allowing for the TRILL Data packet, Channel 704 Tunnel, and DTLS framing overhead. With this SType, the security 705 information provided before the DTLS record(s) is 0, as shown in 706 Figure 4.5, because all the security information is in the payload 707 area. 709 The DTLS Pairwise keying is set up between a pair of RBridges 710 independent of Data Label using messages of a priority configurable 711 at the RBridge level which defaults to priority 6. DTLS messages 712 other than application_data can be encapsulated in the Channel Tunnel 713 protocol with a TRILL Header using any Data Label. Actual 714 application_data sent with Channel Tunnel using this SType should use 715 the Data Label and priority as specified for that application_data. 716 The PType indicates the nature of the application_data. 718 TRILL switches that support the Channel Tunnel DTLS SType MUST 719 support the use of pre-shared keys for DTLS. If the psk_identity (see 720 [RFC4279]) is two bytes, it represents, as a pre-shared key to be 721 used in the DTLS negotiation, the value derived as shown in Section 722 4.3 from the key associated with that psk_identity as a [RFC5310] Key 723 ID. A psk_identity with a length other than two bytes MAY be used to 724 indicate other implementation dependent pre-shared keys. 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | RESV | 0 | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 Figure 4.5 DTLS Channel Tunnel Security Info 732 TRILL switches that implement the Channel Tunnel DTLS SType MAY 733 support the use of certificates for DTLS but certificate size may be 734 limited by the DTLS requirement that each record fit within a single 735 message. 737 5. Channel Tunnel Errors 739 RBridge Channel Tunnel Protocol errors are reported like RBridge 740 Channel level errors. The ERR field is set to one of the following 741 error codes: 743 ERR Meaning 744 --- --------- 745 6 Unknown or unsupported field value 746 7 Authentication failure 747 8 Error in nested RBridge Channel message 749 Table 5.1 Additional ERR Values 751 5.1 SubERRs under ERR 6 753 If the ERR field is 6, the SubERR field indicates the problematic 754 field or value as show in the table below. 756 SubERR Meaning (for ERR = 6) 757 ------ --------------------- 758 0 Reserved 759 1 Non-zero RESV4 nibble 760 2 Unsupported SType 761 3 Unsupported PType 762 4 Unknown Key ID 763 5 Unknown Ethertype with PType = 2 765 Table 5.2 SubERR values under ERR 6 767 5.2 Secure Nested RBridge Channel Errors 769 If 770 a Channel Tunnel message is sent with security and with a payload 771 type (PType) indicating a nested RBridge Channel message 772 and 773 there is an error in the processing of that nested message that 774 results in a return RBridge Channel message with a non-zero ERR 775 field, 776 then that returned message SHOULD also be nested in an Channel Tunnel 777 message using the same type of security. In this case, the ERR field 778 in the Channel Tunnel envelope is set to 8 indicating that there is a 779 nested error in the message being tunneled back. 781 6. IANA Considerations 783 This section lists IANA Considerations. 785 6.1 Channel Tunnel RBridge Channel Protocol Number 787 IANA is requested to assign TBD as the RBridge Channel protocol 788 number for the "Channel Tunnel" protocol from the range assigned by 789 Standards Action. 791 The added RBridge Channel protocols registry entry on the TRILL 792 Parameters web page is as follows: 794 Protocol Description Reference 795 -------- -------------- ------------------ 796 TBD Channel Tunnel [this document] 798 6.2 RBridge Channel Error Codes Subregistry 800 IANA is requested to create a "RBridge Channel Error Codes" 801 subregistry under the "RBridge Channel Protocols" registry. The 802 header information is as follows: 804 Registration Procedures: IETF Review References: [RFC7178] [this 805 document] 807 The subregistry is to have columns and entries as follows: 809 Code Meaning Reference 810 ---- ------- --------- 811 [populate rows for codes 0 through 5 from Section xxx of 812 [RFC7178] with reference [RFC7178] ] 813 [populate rows for codes 6 through 8 from Table 5.1 of this 814 document with reference [this document] ] 815 9-15 Unassigned 816 16 Reserved 818 7. Security Considerations 820 The RBridge Channel Tunnel facility has potentially positive and 821 negative effects on security. 823 On the positive side, it provides optional security that can be used 824 to authenticate and/or encrypt RBridge Channel messages. Some RBridge 825 Channel message payloads, such as BFD [RFC7175], provide their own 826 security but where this is not true, consideration should be given, 827 when specifying an RBridge Channel protocol, to recommending or 828 requiring use of the security features of the Channel Tunnel 829 protocol. 831 On the negative side, the optional ability to tunnel various payload 832 types and to tunnel them between TRILL switches and to and from end 833 stations can increase risk unless precautions are taken. The 834 processing of decapsulating Tunnel Protocol payloads is not a good 835 place to be liberal in what you accept. This is because the tunneling 836 facility makes it easier for unexpected messages to pop up in 837 unexpected places in a TRILL campus due to accidents or the actions 838 of an adversary. Local policies should generally be strict and only 839 process payload types required and then only with adequate 840 authentication for the particular circumstances. 842 See the first paragraph of Section 4 for recommendations on SType 843 usage. See [RFC7457] for Security Considerations of DTLS for 844 security. 846 If IS-IS authentication is not being used, then [RFC5310] keying 847 information would not normally be available but that presumably 848 represents a judgment by the TRILL campus operator that no security 849 is needed. 851 See [RFC7178] for general RBridge Channel Security Considerations and 852 [RFC6325] for general TRILL Security Considerations. 854 Normative References 856 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology 857 -- Telecommunications and information exchange between systems 858 -- Intermediate System to Intermediate System intra-domain 859 routeing information exchange protocol for use in conjunction 860 with the protocol for providing the connectionless-mode network 861 service (ISO 8473)", 2002. 863 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, 864 RFC 20, DOI 10.17487/RFC0020, October 1969, . 867 [RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate 868 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 869 March 1997, . 871 [RFC4279] - Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key 872 Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 873 10.17487/RFC4279, December 2005, . 876 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 877 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 878 5310, DOI 10.17487/RFC5310, February 2009, . 881 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 882 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 883 . 885 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 886 Ghanwani, "Routing Bridges (RBridges): Base Protocol 887 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 888 . 890 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 891 Security Version 1.2", RFC 6347, January 2012, . 894 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 895 and D. Dutt, "Transparent Interconnection of Lots of Links 896 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 897 10.17487/RFC7172, May 2014, . 900 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 901 D., and A. Banerjee, "Transparent Interconnection of Lots of 902 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 903 . 905 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 906 Ward, "Transparent Interconnection of Lots of Links (TRILL): 907 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 908 2014, . 910 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 911 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 912 . 914 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 915 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 916 Lots of Links (TRILL): Clarifications, Corrections, and 917 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 918 . 920 Informative References 922 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 923 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 924 10.17487/RFC6234, May 2011, . 927 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 928 Interconnection of Lots of Links (TRILL) Protocol Control 929 Protocol", RFC 6361, August 2011 931 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 932 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 933 BCP 141, RFC 7042, October 2013. 935 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 936 "Transparent Interconnection of Lots of Links (TRILL): 937 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 938 May 2014. 940 [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 941 Known Attacks on Transport Layer Security (TLS) and Datagram 942 TLS (DTLS)", RFC 7457, February 2015, . 945 [GroupKey] - D. Eastlake et al, "Group Keying Protocol", draft-ietf- 946 trill-group-keying, work in progress. 948 Appendix Z: Change History 950 From -00 to -01 952 1. Fix references for RFCs published, etc. 954 2. Explicitly mention in the Abstract and Introduction that this 955 document updates [RFC7178]. 957 3. Add this Change History Appendix. 959 From -01 to -02 961 1. Remove section on the "Scope" feature as mentioned in 962 http://www.ietf.org/mail-archive/web/trill/current/msg06531.html 964 2. Editorial changes to IANA Considerations to correspond to draft- 965 leiba-cotton-iana-5226bis-11.txt. 967 3. Improvements to the Ethernet frame payload type. 969 4. Other Editorial changes. 971 From -02 to -03 973 1. Update TRILL Header to correspond to [RFC7780]. 975 2. Remove a few remnants of the "Scope" feature that was removed from 976 -01 to -02. 978 3. Substantial changes to and expansion of Section 4 including adding 979 details of DTLS security. 981 4. Updates and additions to the References. 983 5. Other minor editorial changes. 985 From -03 to -04 987 1. Add SType for [RFC5310] keying based security that provides 988 encryption as well as authentication. 990 2. Editorial improvements and fixes. 992 From -04 to -05 994 1. Primary change is collapsing the previous PTypes 2, 3, and 4 for 995 RBridge Channel message, TRILL Data, and TRILL IS-IS into one by 996 including the Ethertype. Previous PType 5 is renumbered as 3. 998 2. Add Channel Tunnel Crypto Suites to IANA Considerations 1000 3. Add some material to Security Considerations, 1002 4. Assorted Editorial changes. 1004 From -05 to -06 1006 Fix editorials found during WG Last Call. 1008 From -06 to -07 1010 Minor editorial changes resulting for Shepherd review. 1012 From -07 to -08 1014 Move group keyed security out of the draft. Simplify and improve 1015 remaining security provisions. 1017 Acknowledgements 1019 The contributions of the following are hereby gratefully 1020 acknowledged: 1022 Susan Hares, Gayle Noble, Yaron Sheffer 1024 The document was prepared in raw nroff. All macros used were defined 1025 within the source file. 1027 Authors' Addresses 1029 Donald E. Eastlake, 3rd 1030 Huawei Technologies 1031 155 Beaver Street 1032 Milford, MA 01757 USA 1034 Phone: +1-508-333-2270 1035 EMail: d3e3e3@gmail.com 1037 Mohammed Umair 1038 IPinfusion 1040 EMail: mohammed.umair2@gmail.com 1042 Yizhou Li 1043 Huawei Technologies 1044 101 Software Avenue, 1045 Nanjing 210012, China 1047 Phone: +86-25-56622310 1048 EMail: liyizhou@huawei.com 1050 Copyright, Disclaimer, and Additional IPR Provisions 1052 Copyright (c) 2016 IETF Trust and the persons identified as the 1053 document authors. All rights reserved. 1055 This document is subject to BCP 78 and the IETF Trust's Legal 1056 Provisions Relating to IETF Documents 1057 (http://trustee.ietf.org/license-info) in effect on the date of 1058 publication of this document. Please review these documents 1059 carefully, as they describe your rights and restrictions with respect 1060 to this document. Code Components extracted from this document must 1061 include Simplified BSD License text as described in Section 4.e of 1062 the Trust Legal Provisions and are provided without warranty as 1063 described in the Simplified BSD License. The definitive version of 1064 an IETF Document is that published by, or under the auspices of, the 1065 IETF. Versions of IETF Documents that are published by third parties, 1066 including those that are translated into other languages, should not 1067 be considered to be definitive versions of IETF Documents. The 1068 definitive version of these Legal Provisions is that published by, or 1069 under the auspices of, the IETF. Versions of these Legal Provisions 1070 that are published by third parties, including those that are 1071 translated into other languages, should not be considered to be 1072 definitive versions of these Legal Provisions. For the avoidance of 1073 doubt, each Contributor to the IETF Standards Process licenses each 1074 Contribution that he or she makes as part of the IETF Standards 1075 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1076 language to the contrary, or terms, conditions or rights that differ 1077 from or are inconsistent with the rights and licenses granted under 1078 RFC 5378, shall have any effect and shall be null and void, whether 1079 published or posted by such Contributor, or included with or in such 1080 Contribution.