idnits 2.17.1 draft-ietf-trill-channel-tunnel-06.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 (June 15, 2015) is 3237 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 3610 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** 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: 4 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: December 14, 2015 June 15, 2015 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, called RBridge Channel, that 16 is specified in RFC 7178, for the transmission of typed messages 17 between TRILL switches in the same campus and between TRILL switches 18 and end stations on the same link. This document specifies two 19 optional extensions to the RBridge Channel protocol: (1) A standard 20 method to tunnel a variety of payload types by encapsulating them in 21 an RBridge Channel message; and (2) A method to support security 22 facilities for RBridge Channel messages. This document updates RFC 23 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 Ethertype Without Addresses............................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 Ethertype With Addresses..............................11 64 4. Security, Keying, and Algorithms.......................14 65 4.1 Basic Security Format.................................14 66 4.2 Authentication and Encryption Coverage................15 67 4.3 Derived Keying Material...............................16 68 4.4 SType None............................................16 69 4.5 RFC 5310 Based Authentication.........................16 70 4.6 DTLS Based Security...................................17 71 4.7 RFC 5310 Based Encryption and Authentication..........18 73 5. Channel Tunnel Errors..................................20 74 5.1 SubERRs under ERR 6...................................20 75 5.2 Nested RBridge Channel Errors.........................20 77 6. IANA Considerations....................................21 78 6.1 RBridge Channel Protocol Number.......................21 79 6.2 Channel Tunnel Crypto Suites..........................21 81 7. Security Considerations................................22 83 Normative References......................................23 84 Informative References....................................24 86 Appendix Z: Change History................................25 88 Acknowledgements..........................................27 89 Authors' Addresses........................................28 91 1. Introduction 93 The IETF TRILL base protocol [RFC6325] has been extended with an 94 optional RBridge Channel [RFC7178] facility to support transmission 95 of typed messages (for example BFD (Bidirectional Forwarding 96 Detection) [RFC7175]) between two TRILL switches (RBridges) in the 97 same campus and between RBridges and end stations on the same link. 98 When sent between RBridges in the same campus, a TRILL Data packet 99 with a TRILL header is used and the destination RBridge is indicated 100 by nickname. When sent between a RBridge and an end station on the 101 same link in either direction a native RBridge Channel messages 102 [RFC7178] is used with no TRILL header and with the destination port 103 or ports indicated by a MAC address. (There is no mechanism to stop 104 end stations on the same link, from sending native RBridge Channel 105 messages to each other; however, such use is outside the scope of 106 this document.) 108 This document updates [RFC7178] and specifies extensions to RBridge 109 Channel that provide two additional facilities as listed below. Use 110 of each of these facilities is optional, except that if Channel 111 Tunnel is implemented there are two payload types that MUST be 112 implemented. 114 (1) A standard method to tunnel a variety of payload types by 115 encapsulating them in an RBridge Channel message. 117 (2) A method to provide security facilities for RBridge Channel 118 messages. 120 Both of the above facilities can be used in the same packet. In case 121 of conflict between this document and [RFC7178], this document takes 122 precedence. 124 1.1 Terminology and Acronyms 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 This document uses terminology and acronyms defined in [RFC6325] and 131 [RFC7178]. Some of these are repeated below for convenience along 132 with additional terms and acronyms. 134 AES - Advanced Encryption Standard. 136 CCM - Counter with CBC-MAC (Cypher Block Chaining - Message 137 Authentication Code). 139 CT-CCM - Channel Tunnel CCM. 141 Data Label - VLAN or FGL. 143 DTLS - Datagram Transport Level Security [RFC6347]. 145 FCS - Frame Check Sequence. 147 FGL - Fine Grained Label [RFC7172]. 149 HKDF - Hash based Key Derivation Function [RFC5869]. 151 IS-IS - Intermediate System to Intermediate Systems [IS-IS]. 153 PDU - Protocol Data Unit. 155 RBridge - An alternative term for a TRILL switch. 157 SHA - Secure Hash Algorithm [RFC6234]. 159 TRILL - Transparent Interconnection of Lots of Links or Tunneled 160 Routing in the Link Layer. 162 TRILL switch - A device that implements the TRILL protocol 163 [RFC6325], sometimes referred to as an RBridge. 165 2. Channel Tunnel Packet Format 167 The general structure of an RBridge Channel message between two TRILL 168 switches (RBridges) in the same campus is shown in Figure 2.1 below. 169 The structure of a native RBridge Channel message sent between an 170 RBridge and an end station on the same link, in either direction, is 171 shown in Figure 2.2 and, compared with the first case, omits the 172 TRILL Header, inner Ethernet addresses, and Data Label. A Protocol 173 field in the RBridge Channel Header gives the type of RBridge Channel 174 message and indicates how to interpret the Channel Protocol Specific 175 Payload [RFC7178]. 177 +-----------------------------------+ 178 | Link Header | 179 +-----------------------------------+ 180 | TRILL Header | 181 +-----------------------------------+ 182 | Inner Ethernet Addresses | 183 +-----------------------------------+ 184 | Data Label (VLAN or FGL) | 185 +-----------------------------------+ 186 | RBridge Channel Header | 187 +-----------------------------------+ 188 | Channel Protocol Specific Payload | 189 +-----------------------------------+ 190 | Link Trailer (FCS if Ethernet) | 191 +-----------------------------------+ 193 Figure 2.1 RBridge Channel Packet Structure 195 +-----------------------------------+ 196 | Ethernet Link Header | 197 +-----------------------------------+ 198 | RBridge Channel Header | 199 +-----------------------------------+ 200 | Channel Protocol Specific Payload | 201 +-----------------------------------+ 202 | FCS | 203 +-----------------------------------+ 205 Figure 2.2 Native RBridge Channel Frame 207 The RBridge Channel Header looks like this: 209 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | 0x8946 | CHV=0 | Channel Protocol | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Flags | ERR | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 216 / Channel Protocol Specific Data / 217 /-+-+-+-+-+- / 219 Figure 2.3 RBridge Channel Header 221 where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel 222 Header Version. This document is based on RBridge Channel version 223 zero. 225 The extensions specified herein are in the form of an RBridge Channel 226 protocol, the Channel Tunnel Protocol. Figure 2.4 below expands the 227 RBridge Channel Header and Protocol Specific Payload above for the 228 case of the Channel Tunnel Protocol. 230 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 231 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 232 RBridge Channel Header: 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | 0x8946 | CHV=0 | Tunnel Protocol =TBD | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Flags | ERR | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Channel Tunnel Protocol Specific: | SubERR| RESV4 | SType | PType | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Security Information, variable length (0 length if SType = 0) 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 243 | Tunneled Data, variable length 244 | ... 246 Figure 2.4 Channel Tunnel Header Structure 248 The RBridge Channel Header field specific to the RBridge Channel 249 Tunnel Protocol is the Protocol field. Its contents MUST be the value 250 allocated for this purpose (see Section 6). 252 The RBridge Tunnel Channel Protocol Specific Data fields are as 253 follows: 255 SubERR: This field provides further details when a Channel Tunnel 256 error is indicated in the RBridge Channel ERR field. If ERR is 257 zero, then SubERR MUST be sent as zero and ignored on receipt. 258 See Section 5. 260 RESV4: This field MUST be sent as zero. If non-zero when received, 261 this is an error condition (see Section 5). 263 SType: This field describes the type of security information and 264 features, including keying material, being used or provided by 265 the Channel Tunnel packet. See Section 4. 267 PType: Payload type. This describes the tunneled data. See Section 268 3 below. 270 Security Information: Variable length information. Length is zero 271 if SType is zero. See Section 4. 273 The Channel Tunnel protocol is integrated with the RBridge Channel 274 facility. Channel Tunnel errors are reported as if they were RBridge 275 Channel errors, using newly allocated code points in the ERR field of 276 the RBridge Channel Header supplemented by the SubERR field. 278 3. Channel Tunnel Payload Types 280 The Channel Tunnel Protocol can carry a variety of payloads as 281 indicated by the PType field. Values are shown in the table below 282 with further explanation after the table. 284 PType Section Description 285 ----- ------- ----------- 286 0 Reserved 287 1 3.1 Null 288 2 3.2 Ethertype Without Addresses 289 3 3.3 Ethertype With Addresses 290 4-14 (Available for assignment by IETF Review) 291 15 Reserved 293 Table 1. Payload Type Values 295 While implementation of the Channel Tunnel protocol is optional, if 296 it is implemented PType 1 (Null) and PType 2 (Ethertype without 297 addresses) with the RBridge Channel Ethertype MUST be implemented. 298 PType 2 for any Ethertypes other than the RBridge Channel Ethertype 299 MAY be implemented. PType 3 MAY be implemented. 301 The processing of any particular Channel Protocol message and its 302 payload depends on meeting local security and other policy at the 303 destination TRILL switch or end station. 305 3.1 Null Payload 307 The Null payload type (PType = 1) is intended to be used for testing 308 or for messages such as key negotiation or the like. It indicates 309 that there is no payload. Any data after the Security Information 310 field is ignored. If the Channel Tunnel feature is implemented, Null 311 Payload MUST be supported. Any particular use of the Null Payload 312 should specify what VLAN or priority should be used when relevant. 314 3.2 Ethertype Without Addresses 316 A PType of 2 indicates that the payload of the Channel Tunnel message 317 begins with an Ethertype. A TRILL switch supporting the Channel 318 Tunnel RBridge Channel protocol MUST support a PType of 2 with a 319 payload beginning with the RBridge Channel Ethertype as describe in 320 Section 3.2.1. Other Ethertypes, including the TRILL and L2-IS-IS 321 Ethertype as described in Section 3.2.2 and 3.2.3, MAY be supported. 323 3.2.1 Tunneled RBridge Channel Message 325 A PType of 2 with an initial RBridge Channel Ethertype indicates an 326 encapsulated RBridge Channel message payload. A typical reason for 327 sending an RBridge Channel message inside a Channel Tunnel message is 328 to provide security services, such as authentication or encryption. 330 This payload type looks like the following: 332 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Possible Security information 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Flags | ERR | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 345 | Channel Protocol Specific Data ... / 346 / / 348 Figure 3.1 Tunneled RBridge Channel Message Structure 350 3.2.2 Tunneled TRILL Data Packet 352 A PType of 2 and an initial TRILL Ethertype indicates that the 353 payload of the Tunnel protocol message is an encapsulated TRILL Data 354 packet as shown in the figure below. If this Ethertype is supported 355 for PType = 2 and the message meets local policy for acceptance, the 356 tunneled TRILL Data packet is handled as if it had been received by 357 the destination TRILL switch on the port where the Channel Tunnel 358 message was received. 360 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Possible Security information 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Egress Nickname | Ingress Nickname | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Optional Flags Word | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Inner.MacDA | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Inner.MacDA continued | Inner.MacSA | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Inner.MacSA (cont.) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Inner Data Label (2 or 4 bytes) 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 383 | TRILL Data Packet payload 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 386 Figure 3.2 Nested TRILL Data Packet Channel Tunnel Structure 388 The optional flags word is only present if the F bit in the TRILL 389 Header is one [rfc7180bis]. 391 3.2.3 Tunneled TRILL IS-IS Packet 393 A PType of 2 and an initial L2-IS-IS Ethertype indicates that the 394 payload of the Tunnel protocol message is an encapsulated TRILL IS-IS 395 PDU packet as shown in the figure below. If this Ethertype is 396 supported, the tunneled TRILL IS-IS packet is processed by the 397 destination RBridge if it meets local policy. One possible use is to 398 expedite the receipt of a link state PDU (LSP) by some TRILL switch 399 or switches with an immediate requirement for the link state 400 information. Since they can be transmitted directly on the link, a 401 link local IS-IS PDU (Hello, CSNP, or PSNP [IS-IS]; MTU-probe or MTU- 402 ack [RFC7176]; or circuit scoped FS-LSP, FS-CSNP or FS-PSNP 403 [RFC7356]) would not normally be sent via this Channel Tunnel method 404 except possibly to encrypt it. 406 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Possible Security information 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 415 | L2-IS-IS (0x22F4) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | 0x83 | rest of IS-IS PDU 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 420 Figure 3.3 Tunneled TRILL IS-IS Packet Structure 422 3.3 Ethertype With Addresses 424 If PType is 3, the Tunnel Protocol payload is an Ethernet frame as 425 might be received from or sent to an end station except that the 426 tunneled Ethernet frame's FCS is omitted, as shown in Figure 3.4. 427 (There is still an overall FCS if the RBridge Channel message is 428 being sent on an Ethernet link.) If this PType is implemented and the 429 message meets local policy, the tunneled frame is handled as if it 430 had been received on the port on which the Channel Tunnel message was 431 received. 433 The priority of the RBridge Channel message can be copied from the 434 Ethernet frame VLAN tag, if one is present, except that priority 7 435 SHOULD only be used for messages critical to adjacency and priority 6 436 SHOULD only be used for other important control messages. 438 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol = TBD | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Possible Security information 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | MacDA | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | MacDA (cont.) | MacSA | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | MacSA (cont.) | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Any Ethernet frame tagging... 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=+-+-... 455 | Ethernet frame payload... 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 458 Figure 3.4 Ethernet Frame Channel Tunnel Structure 460 In the case of a non-Ethernet link, such as a PPP (Point-to-Point 461 Protocol) link [RFC6361], the ports on the link are considered to 462 have link local synthetic 48-bit MAC addresses constructed as 463 described below. These constructed addresses MAY be used as a MacSA. 464 If the RBridge Channel message is link local, the source TRILL switch 465 will have the information to construct such a MAC address for the 466 destination TRILL switch port and that MAC address MAY be used as the 467 MacDA. By the use of such a MacSA and either such a unicast MacDA or 468 a group addressed MacDA, an Ethernet frame can be sent between two 469 TRILL switch ports connected by a non-Ethernet link. 471 These synthetic TRILL switch port MAC addresses for non-Ethernet 472 ports are constructed as follows: 0xFEFF, the nickname of the TRILL 473 switch used in TRILL Hellos sent on that port, and the Port ID that 474 the TRILL switch has assigned to that port, as shown in Figure 3.5. 475 (Both the nickname and Port ID of the port on which a TRILL Hello is 476 sent appear in the Special VLANs and Flags sub-TLV [RFC7176] in that 477 Hello.) The resulting MAC address has the Local bit on and the Group 478 bit off [RFC7042]. Since end stations are connected to TRILL switches 479 over Ethernet, there will be no end stations on a non-Ethernet link 480 in a TRILL campus. Thus such synthetic MAC addresses cannot conflict 481 on the link with a real Ethernet port address. 483 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | 0xFEFF | Nickname | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Port ID | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 3.5 Synthetic MAC Address 493 4. Security, Keying, and Algorithms 495 The following table gives the initial assigned values of the SType 496 field and their meaning. 498 SType Section Meaning 499 ----- ------- ------- 500 0 4.4 None 501 1 4.5 [RFC5310] Based Authentication 502 2 4.6 DTLS Based Security 503 3 4.7 [RFC5310] Based Encryption and Authentication 504 4-14 Available for assignment by IETF Review 505 15 Reserved 507 Table 3. SType Values 509 4.1 Basic Security Format 511 When SType is zero, there is no Security Information after the 512 Channel Tunnel header and before the payload. For all SType values 513 except zero, the Security Information starts with a byte of flag bits 514 and a byte of remaining length as follows: 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 517 |A|E| RESV | Size | More Info 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 520 Figure 4.1 Security Information Format 522 The fields are as follows: 524 A: Zero if authentication is not being provided. One if it is. 526 E: Zero if encryption is not being provided. One if it is. 528 RESV: Six reserved bits that MUST be sent as zero and ignored on 529 receipt. In the future, meanings may be assigned to these bits and 530 those meanings may differ for different STypes. 532 Size: The number of bytes, as an unsigned integer, of More Info in 533 the Security Information after the Size byte itself. Thus the 534 maximum possible length of Security Information is 257 bytes for a 535 Size of 255 plus the flags and Size bytes. 537 More Info: Additional Security Information of length Size. Contents 538 depends on the SType. 540 The A and E bits are intended as hints and to assist in debugging. 542 They are not guaranteed to be correct. They can be interpreted as 543 follows: 545 A E Comments 546 ----- ---------- 548 0 0 Neither authentication nor encryption is being provided. 550 1 0 Authentication only. The payload should be parsable by a 551 security ignorant receiver if it understands the payload 552 format. The Size field permits skipping the More Info 553 field. 555 0 1 Encryption only, perhaps some form of opportunistic 556 security [RFC7435]. 558 1 1 Authentication and Encryption. 560 4.2 Authentication and Encryption Coverage 562 Authentication in the RBridge Channel case (see Figure 2.1) is 563 computed across the inner Ethernet Addresses, Data Label, relevant 564 Channel Tunnel header information, and the payload. To be more 565 precise, the covered area starts with the byte immediately after the 566 TRILL Header ingress nickname unless the optional flag word 567 [rfc7180bis] is present in which case it starts after the flag word, 568 and extends to just before the TRILL Data packet link trailer, for 569 example just before the FCS for Ethernet. If an authentication value 570 is included in the More Info field shown in Section 4.1, it is 571 treated as zero when authentication is calculated. If an 572 authentication value is included in a payload after the security 573 information, it is calculated as provided by the SType and security 574 algorithms in use. 576 Authentication in the native RBridge Channel case (see Figure 2.2), 577 is as specified in the above paragraph except that it starts with the 578 RBridge Channel Ethertype, since there are no TRILL Header, inner 579 Ethernet address, or inner Data Label. 581 If encryption is provided, it covers the payload from right after the 582 Channel Tunnel header Security Information through to just before the 583 TRILL Data packet link trailer. 585 4.3 Derived Keying Material 587 In some cases, it is possible to use keying material derived from 588 [RFC5310] IS-IS keying material. In such cases, the More Info field 589 shown in Figure 4.1 includes a two byte Key ID to identify the IS-IS 590 keying material. The keying material actually used in Channel Tunnel 591 security is derived from the IS-IS keying material as follows: 593 HKDF-Expand-SHA256 ( IS-IS-key, "Channel Tunnel" | 0x0S, L ) 595 where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is 596 as in [RFC6234], IS-IS-key is the input keying material, "Channel 597 Tunnel" is the 14-character [RFC20] string indicated, 0x0S is a 598 single byte where S is the SType for which this key derivation is 599 being used, and L is the length of output keying material needed. 601 4.4 SType None 603 No security services are being invoked. The length of the Security 604 Information field (see Figure 2.4) is zero. 606 4.5 RFC 5310 Based Authentication 608 The Security Information (see Figure 2.4) is the flags and Size bytes 609 specified in Section 4.1 with the value of the [RFC5310] Key ID and 610 Authentication Data as shown in Figure 4.2. 612 1 1 1 1 1 1 613 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 |1|0| RESV | Size | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Key ID | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | | 620 + 621 | Authentication Data (Variable) 622 + 623 | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-... 626 Figure 4.2 SType 1 Security Information 628 o RESV: Six bits that MUST be sent as zero and ignored or receipt. 630 o Size: Set to 2 + the size of Authentication Data in bytes. 632 o Key ID: specifies the same keying value and authentication 633 algorithm that the Key ID specifies for TRILL IS-IS LSP [RFC5310] 634 Authentication TLVs. The keying material actually used is derived 635 as shown in Section 4.3. 637 o Authentication Data: The authentication data produced by the key 638 and algorithm associated with the Key ID acting on the packet as 639 specified in Section 4.2. Length of the authentication data 640 depends on the algorithm. 642 4.6 DTLS Based Security 644 DTLS supports key negotiation and provides both encryption and 645 authentication. This optional SType in Channel Tunnel uses DTLS 1.2 646 [RFC6347]. It is intended for pairwise use. The presumption is that 647 in the RBridge Channel case (Figure 2.1) the M bit in the TRILL 648 Header would be zero and in the native RBridge Channel case (Figure 649 2.2), the Outer.MacDA would be individually addressed. 651 TRILL switches that implement the Channel Tunnel DTLS SType SHOULD 652 support the use of certificates for DTLS. In this case the Size field 653 shown in Section 4.1 MUST be zero and the Security Information is as 654 shown in Figure 4.3. 656 Also, if they support certificates, they MUST support the following 657 algorithm: 659 o TLS_RSA_WITH_AES_128_CBC_SHA256 [RFC5246] 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 |1|1| RESV | 0 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 Figure 4.3 DTLS Cert or Special Pre-shared Key Security Information 667 TRILL switches that support the Channel Tunnel DTLS SType MUST 668 support the use of pre-shared keys for DTLS. The Size field as shown 669 in Section 4.1 MUST be either zero or 2. If Size is zero as shown in 670 Figure 4.3, a pre-shared key specifically associated with Channel 671 Tunnel DTLS is used. If Size is 2 as shown in Figure 4.4, a two byte 672 [RFC5310] Key ID is present and the pre-shared key is derived from 673 the secret key associated with that Key ID as shown in Section 4.3. 675 The following cryptographic algorithms MUST be supported for use with 676 pre-shared keys: 678 o TLS_PSK_WITH_AES_128_CBC_SHA256 [RFC5487] 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 |1|1| RESV | 2 | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Key ID | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Figure 4.4 DTLS Derived Pre-shared Key Security Information 688 When DTLS security is used, the entire payload of the Channel Tunnel 689 packet, starting just after the Security Information and ending just 690 before the link trailer, is a DTLS record [RFC6347]. 692 4.7 RFC 5310 Based Encryption and Authentication 694 This SType is based on pre-existing [RFC5310] keying material but 695 does not use any algorithm that may be associated with a Key ID under 696 [RFC5310]. Instead it uses the derived key as specified in Section 697 4.3 with the algorithm specified by a Crypto Suite ID as shown in 698 Figure 4.5. Key negotiation is not provided and this SType is 699 intended for use in securing multi-destination packets. The 700 presumption is that in the RBridge Channel case (Figure 2.1) the M 701 bit in the TRILL Header would be one and in the native RBridge 702 Channel case (Figure 2.2), the Outer.MacDA would be group addressed. 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 |1|1| RESV | 4 | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Key ID | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Crypto Suite ID | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Figure 4.5 DTLS Derived Pre-shared Key Security Information 714 4.7.1 Channel-Tunnel-CCM 716 The initially specified Crypto Suites is called CT-CCM-128 (Channel 717 Tunnel Counter with CBC-MAC using AES-128), and is designed by Crypto 718 Suite ID 0x0001. 720 CT-CCM is based on [RFC3610] using AES-128 as the encryption 721 function. The minimum authentication field size permitted is 8 722 octets. There is additional authenticated data which is the 723 authenticated data indicated in Section 4.2 up to but not including 724 any of the Tunneled Data (Figure 2.4). The message size is limited to 725 2**16 - 2**8 bytes so 2 bytes are used for the length of message 726 field. There are thus 13 bytes available for nonce [RFC3610]. Since 727 it is possible that the same Key ID could be used by different TRILL 728 switches, the nonce MUST include an identifier for the originating 729 TRILL switch. It is RECOMMENDED that this be the first 6 bytes of its 730 IS-IS System ID as these will be unique across the campus. The 731 remaining 7 bytes (56 bits) need to be such that the nonce is always 732 unique for a particular key, for example a counter for which care is 733 taken that it is always incremented after each use and its value is 734 preserved over TRILL switch crashes, re-starts, and the like. Should 735 there be a danger of exhausting such a counter, the TRILL switch MUST 736 take steps such as causing re-keying of the [RFC5310] key ID it is 737 using and/or changing to use a different Key ID. 739 5. Channel Tunnel Errors 741 RBridge Channel Tunnel Protocol errors are reported like RBridge 742 Channel level errors. The ERR field is set to one of the following 743 error codes: 745 ERR Meaning 746 --- --------- 747 6 Unknown or unsupported field value 748 7 Authentication failure 749 8 Error in nested RBridge Channel message 751 Table 4. Additional ERR Values 753 5.1 SubERRs under ERR 6 755 If the ERR field is 6, the SubERR field indicates the problematic 756 field or value as show in the table below. 758 SubERR Meaning (for ERR = 6) 759 ------ --------------------- 760 0 Reserved 761 1 Non-zero RESV4 nibble 762 2 Unsupported SType 763 3 Unsupported PType 764 4 Unsupported Crypto Suite ID 765 5 Unknown Key ID 766 6 Unknown Ethertype with PType = 2 768 Table 5. SubERR values under ERR 6 770 5.2 Nested RBridge Channel Errors 772 If 773 a Channel Tunnel message is sent with security and with a payload 774 type (PType) indicating a nested RBridge Channel message 775 and 776 there is an error in the processing of that nested message that 777 results in a return RBridge Channel message with a non-zero ERR 778 field, 779 then that returned message SHOULD also be nested in an Channel Tunnel 780 message using the same type of security. In this case, the ERR field 781 in the Channel Tunnel envelope is set to 8 indicating that there is a 782 nested error in the message being tunneled back. 784 6. IANA Considerations 786 This section list IANA Considerations. 788 6.1 RBridge Channel Protocol Number 790 IANA is requested to assign TBD as the RBridge Channel protocol 791 number for the "Channel Tunnel" protocol from the range assigned by 792 Standards Action. 794 The added RBridge Channel protocols registry entry on the TRILL 795 Parameters web page is as follows: 797 Protocol Description Reference 798 -------- -------------- --------- 800 TBD Tunnel Channel [this document] 802 6.2 Channel Tunnel Crypto Suites 804 IANA is requested to create a subregistry in the TRILL Parameters 805 registry as follows: 807 Name: RBridge Channel Tunnel Crypto Suites 808 Registration Procedures: Expert Review 809 Reference: [this document] 811 Value Description Reference 812 ------- ------------- ----------- 813 0 Reserved 814 1 CT-CCM [this document] 815 2-65534 available for assignment 816 65535 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 Tunnel Protocol. 830 On the negative side, the optional ability to tunnel various payload 831 types and to tunnel them between TRILL switches and to and from end 832 stations can increase risk unless precautions are taken. The 833 processing of decapsulating Tunnel Protocol payloads is not a good 834 place to be liberal in what you accept. This is because the tunneling 835 facility makes it easier for unexpected messages to pop up in 836 unexpected places in a TRILL campus due to accidents or the actions 837 of an adversary. Local policies should generally be strict and only 838 process payload types required and then only with adequate 839 authentication for the particular circumstances. 841 While simple [RFC5310] based authentication as specified in Section 842 4.5 is better than nothing, in general it is RECOMMENDED that DTLS 843 based security, as specified in Section 4.6, be used for all point- 844 to-point Channel Tunnel messages and [RFC5310] based encryption and 845 authentication, as specified in Section 4.7, be used for all multi- 846 destination Channel Tunnel messages. If IS-IS authentication is not 847 being used, then [RFC5310] keying information would not normally be 848 available but that presumably represents a judgment by the TRILL 849 campus operator that security is not needed. 851 In connection with the use of DTLS for security as specified in 852 Section 4.5, see [RFC7457]. 854 See [RFC7178] for general RBridge Channel Security Considerations and 855 [RFC6325] for general TRILL Security Considerations. 857 Normative References 859 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology 860 -- Telecommunications and information exchange between systems 861 -- Intermediate System to Intermediate System intra-domain 862 routeing information exchange protocol for use in conjunction 863 with the protocol for providing the connectionless-mode network 864 service (ISO 8473)", 2002. 866 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, 867 RFC 20, October 1969, . 869 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, March 1997. 872 [RFC3610] - Whiting, D., Housley, R., and N. Ferguson, "Counter with 873 CBC-MAC (CCM)", RFC 3610, September 2003, . 876 [RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security 877 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 878 . 880 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 881 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 882 5310, February 2009. 884 [RFC5487] - Badra, M., "Pre-Shared Key Cipher Suites for TLS with 885 SHA-256/384 and AES Galois Counter Mode", RFC 5487, March 2009, 886 . 888 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 889 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 890 . 892 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 893 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 894 July 2011. 896 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 897 Security Version 1.2", RFC 6347, January 2012, . 900 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 901 and D. Dutt, "Transparent Interconnection of Lots of Links 902 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 904 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 905 D., and A. Banerjee, "Transparent Interconnection of Lots of 906 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 907 . 909 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 910 Ward, "Transparent Interconnection of Lots of Links (TRILL): 911 RBridge Channel Support", RFC 7178, May 2014. 913 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 914 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 915 . 917 [rfc7180bis] - Eastlake, D., Zhang, M., Perlman, R. Banerjee, A., 918 Ghanwani, A., and S. Gupta, "TRILL: Clarifications, 919 Corrections, and Updates", Draft-ietf-trill-rfc7180bis, work in 920 progress. 922 Informative References 924 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 925 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 926 2011. 928 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 929 Interconnection of Lots of Links (TRILL) Protocol Control 930 Protocol", RFC 6361, August 2011 932 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 933 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 934 BCP 141, RFC 7042, October 2013. 936 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 937 "Transparent Interconnection of Lots of Links (TRILL): 938 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 939 May 2014. 941 [RFC7435] - Dukhovni, V., "Opportunistic Security: Some Protection 942 Most of the Time", RFC 7435, December 2014, . 945 [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 946 Known Attacks on Transport Layer Security (TLS) and Datagram 947 TLS (DTLS)", RFC 7457, February 2015, . 950 Appendix Z: Change History 952 From -00 to -01 954 1. Fix references for RFCs published, etc. 956 2. Explicitly mention in the Abstract and Introduction that this 957 document updates [RFC7178]. 959 3. Add this Change History Appendix. 961 From -01 to -02 963 1. Remove section on the "Scope" feature as mentioned in 964 http://www.ietf.org/mail-archive/web/trill/current/msg06531.html 966 2. Editorial changes to IANA Considerations to correspond to draft- 967 leiba-cotton-iana-5226bis-11.txt. 969 3. Improvements to the Ethernet frame payload type. 971 4. Other Editorial changes. 973 From -02 to -03 975 1. Update TRILL Header to correspond to [rfc7180bis]. 977 2. Remove a few remnants of the "Scope" feature that was removed from 978 -01 to -02. 980 3. Substantial changes to and expansion of Section 4 including adding 981 details of DTLS security. 983 4. Updates and additions to the References. 985 5. Other minor editorial changes. 987 From -03 to -04 989 1. Add SType for [RFC5310] keying based security that provides 990 encryption as well as authentication. 992 2. Editorial improvements and fixes. 994 From -04 to -05 996 1. Primary change is collapsing the previous PTypes 2, 3, and 4 for 997 RBridge Channel message, TRILL Data, and TRILL IS-IS into one by 998 including the Ethertype. Previous PType 5 is renumbered as 3. 1000 2. Add Channel Tunnel Crypto Suites to IANA Considerations 1002 3. Add some material to Security Considerations, 1004 4. Assorted Editorial changes. 1006 From -05 to -06 1008 Fix editorials found during WG Last Call. 1010 Acknowledgements 1012 The contributions of the following are hereby acknowledged: 1014 Gayle Noble 1016 The document was prepared in raw nroff. All macros used were defined 1017 within the source file. 1019 Authors' Addresses 1021 Donald E. Eastlake, 3rd 1022 Huawei Technologies 1023 155 Beaver Street 1024 Milford, MA 01757 USA 1026 Phone: +1-508-333-2270 1027 EMail: d3e3e3@gmail.com 1029 Mohammed Umair 1030 IPinfusion 1032 EMail: mohammed.umair2@gmail.com 1034 Yizhou Li 1035 Huawei Technologies 1036 101 Software Avenue, 1037 Nanjing 210012, China 1039 Phone: +86-25-56622310 1040 EMail: liyizhou@huawei.com 1042 Copyright, Disclaimer, and Additional IPR Provisions 1044 Copyright (c) 2015 IETF Trust and the persons identified as the 1045 document authors. All rights reserved. 1047 This document is subject to BCP 78 and the IETF Trust's Legal 1048 Provisions Relating to IETF Documents 1049 (http://trustee.ietf.org/license-info) in effect on the date of 1050 publication of this document. Please review these documents 1051 carefully, as they describe your rights and restrictions with respect 1052 to this document. Code Components extracted from this document must 1053 include Simplified BSD License text as described in Section 4.e of 1054 the Trust Legal Provisions and are provided without warranty as 1055 described in the Simplified BSD License. The definitive version of 1056 an IETF Document is that published by, or under the auspices of, the 1057 IETF. Versions of IETF Documents that are published by third parties, 1058 including those that are translated into other languages, should not 1059 be considered to be definitive versions of IETF Documents. The 1060 definitive version of these Legal Provisions is that published by, or 1061 under the auspices of, the IETF. Versions of these Legal Provisions 1062 that are published by third parties, including those that are 1063 translated into other languages, should not be considered to be 1064 definitive versions of these Legal Provisions. For the avoidance of 1065 doubt, each Contributor to the IETF Standards Process licenses each 1066 Contribution that he or she makes as part of the IETF Standards 1067 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1068 language to the contrary, or terms, conditions or rights that differ 1069 from or are inconsistent with the rights and licenses granted under 1070 RFC 5378, shall have any effect and shall be null and void, whether 1071 published or posted by such Contributor, or included with or in such 1072 Contribution.