idnits 2.17.1 draft-ietf-trill-channel-tunnel-07.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 (August 13, 2015) is 3179 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: February 12, 2016 August 13, 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 85 Appendix Z: Change History................................25 87 Acknowledgements..........................................27 88 Authors' Addresses........................................28 90 1. Introduction 92 The IETF TRILL base protocol [RFC6325] has been extended with an 93 optional 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 between RBridges and end stations on the same link. 97 When sent between RBridges in the same campus, a TRILL Data packet 98 with a TRILL header is used and the destination RBridge is indicated 99 by nickname. When sent between a RBridge and an end station on the 100 same link in either direction a native RBridge Channel messages 101 [RFC7178] is used with no TRILL header and with the destination port 102 or ports indicated by a MAC address. (There is no mechanism to stop 103 end stations on the same link, from sending native RBridge Channel 104 messages to each other; however, such use is outside the scope of 105 this document.) 107 This document updates [RFC7178] and specifies extensions to RBridge 108 Channel that provide two additional facilities as listed below. Use 109 of each of these facilities is optional, except that if Channel 110 Tunnel is implemented there are two payload types that MUST be 111 implemented. 113 (1) A standard method to tunnel a variety of payload types by 114 encapsulating them in an RBridge Channel message. 116 (2) A method to provide security facilities for RBridge Channel 117 messages. 119 Both of the above facilities can be used in the same packet. In case 120 of conflict between this document and [RFC7178], this document takes 121 precedence. 123 1.1 Terminology and Acronyms 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [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 terms and acronyms. 133 AES - Advanced Encryption Standard. 135 CCM - Counter with CBC-MAC (Cypher Block Chaining - Message 136 Authentication Code). 138 CT-CCM - Channel Tunnel CCM. 140 Data Label - VLAN or FGL. 142 DTLS - Datagram Transport Level Security [RFC6347]. 144 FCS - Frame Check Sequence. 146 FGL - Fine Grained Label [RFC7172]. 148 HKDF - Hash based Key Derivation Function [RFC5869]. 150 IS-IS - Intermediate System to Intermediate Systems [IS-IS]. 152 PDU - Protocol Data Unit. 154 RBridge - An alternative term for a TRILL switch. 156 SHA - Secure Hash Algorithm [RFC6234]. 158 TRILL - Transparent Interconnection of Lots of Links or Tunneled 159 Routing in the Link Layer. 161 TRILL switch - A device that implements the TRILL protocol 162 [RFC6325], sometimes referred to as an RBridge. 164 2. Channel Tunnel Packet Format 166 The general structure of an RBridge Channel message between two TRILL 167 switches (RBridges) in the same campus is shown in Figure 2.1 below. 168 The structure of a native RBridge Channel message sent between an 169 RBridge and an end station on the same link, in either direction, is 170 shown in Figure 2.2 and, compared with the first case, omits the 171 TRILL Header, inner Ethernet addresses, and Data Label. A Protocol 172 field in the RBridge Channel Header gives the type of RBridge Channel 173 message and indicates how to interpret the Channel Protocol Specific 174 Payload [RFC7178]. 176 +-----------------------------------+ 177 | Link Header | 178 +-----------------------------------+ 179 | TRILL Header | 180 +-----------------------------------+ 181 | Inner Ethernet Addresses | 182 +-----------------------------------+ 183 | Data Label (VLAN or FGL) | 184 +-----------------------------------+ 185 | RBridge Channel Header | 186 +-----------------------------------+ 187 | Channel Protocol Specific Payload | 188 +-----------------------------------+ 189 | Link Trailer (FCS if Ethernet) | 190 +-----------------------------------+ 192 Figure 2.1 RBridge Channel Packet Structure 194 +-----------------------------------+ 195 | Ethernet Link Header | 196 +-----------------------------------+ 197 | RBridge Channel Header | 198 +-----------------------------------+ 199 | Channel Protocol Specific Payload | 200 +-----------------------------------+ 201 | FCS | 202 +-----------------------------------+ 204 Figure 2.2 Native RBridge Channel Frame 206 The RBridge Channel Header looks like this: 208 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | 0x8946 | CHV=0 | Channel Protocol | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Flags | ERR | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 215 / Channel Protocol Specific Data / 216 /-+-+-+-+-+- / 218 Figure 2.3 RBridge Channel Header 220 where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel 221 Header Version. This document is based on RBridge Channel version 222 zero. 224 The extensions specified herein are in the form of an RBridge Channel 225 protocol, the Channel Tunnel Protocol. Figure 2.4 below expands the 226 RBridge Channel Header and Protocol Specific Payload above for the 227 case of the Channel Tunnel Protocol. 229 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 230 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 231 RBridge Channel Header: 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | 0x8946 | CHV=0 | Tunnel Protocol =TBD | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Flags | ERR | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Channel Tunnel Protocol Specific: | SubERR| RESV4 | SType | PType | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Security Information, variable length (0 length if SType = 0) / 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 242 | Tunneled Data, variable length 243 | ... 245 Figure 2.4 Channel Tunnel Header Structure 247 The RBridge Channel Header field specific to the RBridge Channel 248 Tunnel Protocol is the Protocol field. Its contents MUST be the value 249 allocated for this purpose (see Section 6). 251 The RBridge Channel Tunnel Protocol Specific Data fields are as 252 follows: 254 SubERR: This field provides further details when a Channel Tunnel 255 error is indicated in the RBridge Channel ERR field. If ERR is 256 zero, then SubERR MUST be sent as zero and ignored on receipt. 257 See Section 5. 259 RESV4: This field MUST be sent as zero. If non-zero when received, 260 this is an error condition (see Section 5). 262 SType: This field describes the type of security information and 263 features, including keying material, being used or provided by 264 the Channel Tunnel packet. See Section 4. 266 PType: Payload type. This describes the tunneled data. See Section 267 3 below. 269 Security Information: Variable length information. Length is zero 270 if SType is zero. See Section 4. 272 The Channel Tunnel protocol is integrated with the RBridge Channel 273 facility. Channel Tunnel errors are reported as if they were RBridge 274 Channel errors, using newly allocated code points in the ERR field of 275 the RBridge Channel Header supplemented by the SubERR field. 277 3. Channel Tunnel Payload Types 279 The Channel Tunnel Protocol can carry a variety of payloads as 280 indicated by the PType field. Values are shown in the table below 281 with further explanation after the table. 283 PType Section Description 284 ----- ------- ----------- 285 0 Reserved 286 1 3.1 Null 287 2 3.2 Ethertype Without Addresses 288 3 3.3 Ethertype With Addresses 289 4-14 (Available for assignment by IETF Review) 290 15 Reserved 292 Table 1. Payload Type Values 294 While implementation of the Channel Tunnel protocol is optional, if 295 it is implemented PType 1 (Null) and PType 2 (Ethertype without 296 addresses) with the RBridge Channel Ethertype MUST be implemented. 297 PType 2 for any Ethertypes other than the RBridge Channel Ethertype 298 MAY be implemented. PType 3 MAY be implemented. 300 The processing of any particular Channel Protocol message and its 301 payload depends on meeting local security and other policy at the 302 destination TRILL switch or end station. 304 3.1 Null Payload 306 The Null payload type (PType = 1) is intended to be used for testing 307 or for messages such as key negotiation or the like. It indicates 308 that there is no payload. Any data after the Security Information 309 field is ignored. If the Channel Tunnel feature is implemented, Null 310 Payload MUST be supported. Any particular use of the Null Payload 311 should specify what VLAN or priority should be used when relevant. 313 3.2 Ethertype Without Addresses 315 A PType of 2 indicates that the payload of the Channel Tunnel message 316 begins with an Ethertype. A TRILL switch supporting the Channel 317 Tunnel RBridge Channel protocol MUST support a PType of 2 with a 318 payload beginning with the RBridge Channel Ethertype as describe in 319 Section 3.2.1. Other Ethertypes, including the TRILL and L2-IS-IS 320 Ethertype as described in Section 3.2.2 and 3.2.3, MAY be supported. 322 3.2.1 Tunneled RBridge Channel Message 324 A PType of 2 with an initial RBridge Channel Ethertype indicates an 325 encapsulated RBridge Channel message payload. A typical reason for 326 sending an RBridge Channel message inside a Channel Tunnel message is 327 to provide security services, such as authentication or encryption. 329 This payload type looks like the following: 331 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Security Information, variable length (0 length if SType = 0) / 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol| 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Flags | ERR | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 344 | Nested Channel Protocol Specific Data ... / 345 / / 347 Figure 3.1 Tunneled RBridge Channel Message Structure 349 3.2.2 Tunneled TRILL Data Packet 351 A PType of 2 and an initial TRILL Ethertype indicates that the 352 payload of the Tunnel protocol message is an encapsulated TRILL Data 353 packet as shown in the figure below. If this Ethertype is supported 354 for PType = 2 and the message meets local policy for acceptance, the 355 tunneled TRILL Data packet is handled as if it had been received by 356 the destination TRILL switch on the port where the Channel Tunnel 357 message was received. 359 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Security Information, variable length (0 length if SType = 0) / 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Egress Nickname | Ingress Nickname | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Optional Flags Word | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Inner.MacDA | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Inner.MacDA continued | Inner.MacSA | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Inner.MacSA (cont.) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Inner Data Label (2 or 4 bytes) 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 382 | TRILL Data Packet payload 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 385 Figure 3.2 Nested TRILL Data Packet Channel Tunnel Structure 387 The optional flags word is only present if the F bit in the TRILL 388 Header is one [rfc7180bis]. 390 3.2.3 Tunneled TRILL IS-IS Packet 392 A PType of 2 and an initial L2-IS-IS Ethertype indicates that the 393 payload of the Tunnel protocol message is an encapsulated TRILL IS-IS 394 PDU packet as shown in figure 3.3. If this Ethertype is supported, 395 the tunneled TRILL IS-IS packet is processed by the destination 396 RBridge if it meets local policy. One possible use is to expedite the 397 receipt of a link state PDU (LSP) by some TRILL switch or switches 398 with an immediate requirement for the link state information. Since 399 they can be transmitted directly on the link, a link local IS-IS PDU 400 (Hello, CSNP, or PSNP [IS-IS]; MTU-probe or MTU-ack [RFC7176]; or 401 circuit scoped FS-LSP, FS-CSNP or FS-PSNP [RFC7356]) would not 402 normally be sent via this Channel Tunnel method except possibly to 403 encrypt it. 405 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Security Information, variable length (0 length if SType = 0) / 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 414 | L2-IS-IS (0x22F4) | 0x83 | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | rest of IS-IS PDU 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 419 Figure 3.3 Tunneled TRILL IS-IS Packet Structure 421 3.3 Ethertype With Addresses 423 If PType is 3, the Tunnel Protocol payload is an Ethernet frame as 424 might be received from or sent to an end station except that the 425 tunneled Ethernet frame's FCS is omitted, as shown in Figure 3.4. 426 (There is still an overall FCS if the RBridge Channel message is 427 being sent on an Ethernet link.) If this PType is implemented and the 428 message meets local policy, the tunneled frame is handled as if it 429 had been received on the port on which the Channel Tunnel message was 430 received. 432 The priority of the RBridge Channel message can be copied from the 433 Ethernet frame VLAN tag, if one is present, except that priority 7 434 SHOULD only be used for messages critical to adjacency and priority 6 435 SHOULD only be used for other important control messages. 437 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol = TBD | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Security Information, variable length (0 length if SType = 0) / 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | MacDA | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | MacDA (cont.) | MacSA | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | MacSA (cont.) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Any Ethernet frame tagging... 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=+-+-... 454 | Ethernet frame payload... 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 457 Figure 3.4 Ethernet Frame Channel Tunnel Structure 459 In the case of a non-Ethernet link, such as a PPP (Point-to-Point 460 Protocol) link [RFC6361], the ports on the link are considered to 461 have link local synthetic 48-bit MAC addresses constructed as 462 described below. These constructed addresses MAY be used as a MacSA. 463 If the RBridge Channel message is link local, the source TRILL switch 464 will have the information to construct such a MAC address for the 465 destination TRILL switch port and that MAC address MAY be used as the 466 MacDA. By the use of such a MacSA and either such a unicast MacDA or 467 a group addressed MacDA, an Ethernet frame can be sent between two 468 TRILL switch ports connected by a non-Ethernet link. 470 These synthetic TRILL switch port MAC addresses for non-Ethernet 471 ports are constructed as follows: 0xFEFF, the nickname of the TRILL 472 switch used in TRILL Hellos sent on that port, and the Port ID that 473 the TRILL switch has assigned to that port, as shown in Figure 3.5. 474 (Both the nickname and Port ID of the port on which a TRILL Hello is 475 sent appear in the Special VLANs and Flags sub-TLV [RFC7176] in that 476 Hello.) The resulting MAC address has the Local bit on and the Group 477 bit off [RFC7042]. Since end stations are connected to TRILL switches 478 over Ethernet, there will be no end stations on a non-Ethernet link 479 in a TRILL campus. Thus such synthetic MAC addresses cannot conflict 480 on the link with a real Ethernet port address. 482 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | 0xFEFF | Nickname | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Port ID | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 3.5 Synthetic MAC Address 492 4. Security, Keying, and Algorithms 494 The following table gives the initial assigned values of the SType 495 field and their meaning. 497 SType Section Meaning 498 ----- ------- ------- 499 0 4.4 None 500 1 4.5 [RFC5310] Based Authentication 501 2 4.6 DTLS Based Security 502 3 4.7 [RFC5310] Based Encryption and Authentication 503 4-14 Available for assignment by IETF Review 504 15 Reserved 506 Table 3. SType Values 508 4.1 Basic Security Format 510 When SType is zero, there is no Security Information after the 511 Channel Tunnel header and before the payload. For all SType values 512 except zero, the Security Information starts with a byte of flag bits 513 and a byte of remaining length as follows: 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 516 |A|E| RESV | Size | More Info 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 519 Figure 4.1 Security Information Format 521 The fields are as follows: 523 A: Zero if authentication is not being provided. One if it is. 525 E: Zero if encryption is not being provided. One if it is. 527 RESV: Six reserved bits that MUST be sent as zero and ignored on 528 receipt. In the future, meanings may be assigned to these bits and 529 those meanings may differ for different STypes. 531 Size: The number of bytes, as an unsigned integer, of More Info in 532 the Security Information after the Size byte itself. Thus the 533 maximum possible length of Security Information is 257 bytes for a 534 Size of 255 plus the flags and Size bytes. 536 More Info: Additional Security Information of length Size. Contents 537 depends on the SType. 539 The A and E bits are intended as hints and to assist in debugging. 541 They are not guaranteed to be correct. They can be interpreted as 542 follows: 544 A E Comments 545 ----- ---------- 547 0 0 Neither authentication nor encryption is being provided. 549 1 0 Authentication only. The payload should be parsable by a 550 security ignorant receiver if it understands the payload 551 format. The Size field permits skipping the More Info 552 field. 554 0 1 Encryption only, perhaps some form of opportunistic 555 security [RFC7435]. 557 1 1 Authentication and Encryption. 559 4.2 Authentication and Encryption Coverage 561 Authentication in the RBridge Channel case (see Figure 2.1) is 562 computed across the inner Ethernet Addresses, Data Label, relevant 563 Channel Tunnel header information, and the payload. 565 To be more precise, the covered area starts with the byte immediately 566 after the TRILL Header ingress nickname unless the optional flag word 567 [rfc7180bis] is present. If the optional flag word is present, then 568 the covered area starts after that flag word. In either case, it 569 extends to just before the TRILL Data packet link trailer. For 570 example, for an Ethernet packet it would extend to just before the 571 FCS. If an authentication value is included in the More Info field 572 shown in Section 4.1, it is treated as zero when authentication is 573 calculated. If an authentication value is included in a payload after 574 the security information, it is calculated as provided by the SType 575 and security algorithms in use. 577 Authentication in the native RBridge Channel case (see Figure 2.2), 578 is as specified in the above paragraph except that it starts with the 579 RBridge Channel Ethertype, since there are no TRILL Header, inner 580 Ethernet address, or inner Data Label. 582 If encryption is provided, it covers the payload from right after the 583 Channel Tunnel header Security Information through to just before the 584 TRILL Data packet link trailer. 586 4.3 Derived Keying Material 588 In some cases, it is possible to use keying material derived from 589 [RFC5310] IS-IS keying material. In such cases, the More Info field 590 shown in Figure 4.1 includes a two byte Key ID to identify the IS-IS 591 keying material. The keying material actually used in Channel Tunnel 592 security is derived from the IS-IS keying material as follows: 594 HKDF-Expand-SHA256 ( IS-IS-key, "Channel Tunnel" | 0x0S, L ) 596 where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is 597 as in [RFC6234], IS-IS-key is the input keying material, "Channel 598 Tunnel" is the 14-character [RFC20] string indicated, 0x0S is a 599 single byte where S is the SType for which this key derivation is 600 being used, and L is the length of output keying material needed. 602 4.4 SType None 604 No security services are being invoked. The length of the Security 605 Information field (see Figure 2.4) is zero. 607 4.5 RFC 5310 Based Authentication 609 The Security Information (see Figure 2.4) is the flags and Size bytes 610 specified in Section 4.1 with the value of the [RFC5310] Key ID and 611 Authentication Data as shown in Figure 4.2. 613 1 1 1 1 1 1 614 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 |1|0| RESV | Size | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Key ID | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | | 621 + 622 | Authentication Data (Variable) 623 + 624 | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-... 627 Figure 4.2 SType 1 Security Information 629 o RESV: Six bits that MUST be sent as zero and ignored or receipt. 631 o Size: Set to 2 + the size of Authentication Data in bytes. 633 o Key ID: specifies the same keying value and authentication 634 algorithm that the Key ID specifies for TRILL IS-IS LSP [RFC5310] 635 Authentication TLVs. The keying material actually used is derived 636 as shown in Section 4.3. 638 o Authentication Data: The authentication data produced by the key 639 and algorithm associated with the Key ID acting on the packet as 640 specified in Section 4.2. Length of the authentication data 641 depends on the algorithm. 643 4.6 DTLS Based Security 645 DTLS supports key negotiation and provides both encryption and 646 authentication. This optional SType in Channel Tunnel uses DTLS 1.2 647 [RFC6347]. It is intended for pairwise use. The presumption is that 648 in the RBridge Channel case (Figure 2.1) the M bit in the TRILL 649 Header would be zero and in the native RBridge Channel case (Figure 650 2.2), the Outer.MacDA would be individually addressed. 652 TRILL switches that implement the Channel Tunnel DTLS SType SHOULD 653 support the use of certificates for DTLS. In this case the Size field 654 shown in Section 4.1 MUST be zero and the Security Information is as 655 shown in Figure 4.3. 657 Also, if they support certificates, they MUST support the following 658 algorithm: 660 o TLS_RSA_WITH_AES_128_CBC_SHA256 [RFC5246] 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |1|1| RESV | 0 | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Figure 4.3 DTLS Cert or Special Pre-shared Key Security Information 668 TRILL switches that support the Channel Tunnel DTLS SType MUST 669 support the use of pre-shared keys for DTLS. The Size field as shown 670 in Section 4.1 MUST be either zero or 2. If Size is zero as shown in 671 Figure 4.3, a pre-shared key specifically associated with Channel 672 Tunnel DTLS is used. If Size is 2 as shown in Figure 4.4, a two byte 673 [RFC5310] Key ID is present and the pre-shared key is derived from 674 the secret key associated with that Key ID as shown in Section 4.3. 676 The following cryptographic algorithms MUST be supported for use with 677 pre-shared keys: 679 o TLS_PSK_WITH_AES_128_CBC_SHA256 [RFC5487] 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 |1|1| RESV | 2 | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Key ID | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Figure 4.4 DTLS Derived Pre-shared Key Security Information 689 When DTLS security is used, the entire payload of the Channel Tunnel 690 packet, starting just after the Security Information and ending just 691 before the link trailer, is a DTLS record [RFC6347]. 693 4.7 RFC 5310 Based Encryption and Authentication 695 This SType is based on pre-existing [RFC5310] keying material but 696 does not use any algorithm that may be associated with a Key ID under 697 [RFC5310]. Instead it uses the derived key as specified in Section 698 4.3 with the algorithm specified by a Crypto Suite ID as shown in 699 Figure 4.5. Key negotiation is not provided and this SType is 700 intended for use in securing multi-destination packets. The 701 presumption is that in the RBridge Channel case (Figure 2.1) the M 702 bit in the TRILL Header would be one and in the native RBridge 703 Channel case (Figure 2.2), the Outer.MacDA would be group addressed. 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 |1|1| RESV | 4 | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Key ID | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Crypto Suite ID | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Figure 4.5 DTLS Derived Pre-shared Key Security Information 715 4.7.1 Channel-Tunnel-CCM 717 The initially specified Crypto Suites is called CT-CCM-128 (Channel 718 Tunnel Counter with CBC-MAC using AES-128), and is designed by Crypto 719 Suite ID 0x0001. 721 CT-CCM is based on [RFC3610] using AES-128 as the encryption 722 function. The minimum authentication field size permitted is 8 723 octets. There is additional authenticated data which is the 724 authenticated data indicated in Section 4.2 up to but not including 725 any of the Tunneled Data (Figure 2.4). The message size is limited to 726 2**16 - 2**8 bytes so 2 bytes are used for the length of message 727 field. There are thus 13 bytes available for nonce [RFC3610]. Since 728 it is possible that the same Key ID could be used by different TRILL 729 switches, the nonce MUST include an identifier for the originating 730 TRILL switch. It is RECOMMENDED that this be the first 6 bytes of its 731 IS-IS System ID as these will be unique across the campus. The 732 remaining 7 bytes (56 bits) need to be such that the nonce is always 733 unique for a particular key, for example a counter for which care is 734 taken that it is always incremented after each use and its value is 735 preserved over TRILL switch crashes, re-starts, and the like. Should 736 there be a danger of exhausting such a counter, the TRILL switch MUST 737 take steps such as causing re-keying of the [RFC5310] key ID it is 738 using and/or changing to use a different Key ID. 740 5. Channel Tunnel Errors 742 RBridge Channel Tunnel Protocol errors are reported like RBridge 743 Channel level errors. The ERR field is set to one of the following 744 error codes: 746 ERR Meaning 747 --- --------- 748 6 Unknown or unsupported field value 749 7 Authentication failure 750 8 Error in nested RBridge Channel message 752 Table 4. Additional ERR Values 754 5.1 SubERRs under ERR 6 756 If the ERR field is 6, the SubERR field indicates the problematic 757 field or value as show in the table below. 759 SubERR Meaning (for ERR = 6) 760 ------ --------------------- 761 0 Reserved 762 1 Non-zero RESV4 nibble 763 2 Unsupported SType 764 3 Unsupported PType 765 4 Unsupported Crypto Suite ID 766 5 Unknown Key ID 767 6 Unknown Ethertype with PType = 2 769 Table 5. SubERR values under ERR 6 771 5.2 Nested RBridge Channel Errors 773 If 774 a Channel Tunnel message is sent with security and with a payload 775 type (PType) indicating a nested RBridge Channel message 776 and 777 there is an error in the processing of that nested message that 778 results in a return RBridge Channel message with a non-zero ERR 779 field, 780 then that returned message SHOULD also be nested in an Channel Tunnel 781 message using the same type of security. In this case, the ERR field 782 in the Channel Tunnel envelope is set to 8 indicating that there is a 783 nested error in the message being tunneled back. 785 6. IANA Considerations 787 This section list IANA Considerations. 789 6.1 RBridge Channel Protocol Number 791 IANA is requested to assign TBD as the RBridge Channel protocol 792 number for the "Channel Tunnel" protocol from the range assigned by 793 Standards Action. 795 The added RBridge Channel protocols registry entry on the TRILL 796 Parameters web page is as follows: 798 Protocol Description Reference 799 -------- -------------- ------------------ 801 TBD Channel Tunnel [this document] 803 6.2 Channel Tunnel Crypto Suites 805 IANA is requested to create a subregistry in the TRILL Parameters 806 registry as follows: 808 Name: RBridge Channel Tunnel Crypto Suites 809 Registration Procedures: Expert Review 810 Reference: [this document] 812 Value Description Reference 813 ------- ------------- ----------- 814 0 Reserved 815 1 CT-CCM [this document] 816 2-65534 available for assignment 817 65535 Reserved 819 7. Security Considerations 821 The RBridge Channel tunnel facility has potentially positive and 822 negative effects on security. 824 On the positive side, it provides optional security that can be used 825 to authenticate and/or encrypt RBridge Channel messages. Some RBridge 826 Channel message payloads, such as BFD [RFC7175], provide their own 827 security but where this is not true, consideration should be given, 828 when specifying an RBridge Channel protocol, to recommending or 829 requiring use of the security features of the Tunnel 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 While simple [RFC5310] based authentication as specified in Section 843 4.5 is better than nothing, in general it is RECOMMENDED that DTLS 844 based security, as specified in Section 4.6, be used for all point- 845 to-point Channel Tunnel messages and [RFC5310] based encryption and 846 authentication, as specified in Section 4.7, be used for all multi- 847 destination Channel Tunnel messages. If IS-IS authentication is not 848 being used, then [RFC5310] keying information would not normally be 849 available but that presumably represents a judgment by the TRILL 850 campus operator that security is not needed. 852 In connection with the use of DTLS for security as specified in 853 Section 4.5, see [RFC7457]. 855 See [RFC7178] for general RBridge Channel Security Considerations and 856 [RFC6325] for general TRILL Security Considerations. 858 Normative References 860 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology 861 -- Telecommunications and information exchange between systems 862 -- Intermediate System to Intermediate System intra-domain 863 routeing information exchange protocol for use in conjunction 864 with the protocol for providing the connectionless-mode network 865 service (ISO 8473)", 2002. 867 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, 868 RFC 20, October 1969, . 870 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, March 1997. 873 [RFC3610] - Whiting, D., Housley, R., and N. Ferguson, "Counter with 874 CBC-MAC (CCM)", RFC 3610, September 2003, . 877 [RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security 878 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 879 . 881 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 882 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 883 5310, February 2009. 885 [RFC5487] - Badra, M., "Pre-Shared Key Cipher Suites for TLS with 886 SHA-256/384 and AES Galois Counter Mode", RFC 5487, March 2009, 887 . 889 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 890 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 891 . 893 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 894 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 895 July 2011. 897 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 898 Security Version 1.2", RFC 6347, January 2012, . 901 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 902 and D. Dutt, "Transparent Interconnection of Lots of Links 903 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 905 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 906 D., and A. Banerjee, "Transparent Interconnection of Lots of 907 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 908 . 910 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 911 Ward, "Transparent Interconnection of Lots of Links (TRILL): 912 RBridge Channel Support", RFC 7178, May 2014. 914 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 915 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 916 . 918 [rfc7180bis] - Eastlake, D., Zhang, M., Perlman, R. Banerjee, A., 919 Ghanwani, A., and S. Gupta, "TRILL: Clarifications, 920 Corrections, and Updates", Draft-ietf-trill-rfc7180bis, work in 921 progress. 923 Informative References 925 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 926 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 927 2011. 929 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 930 Interconnection of Lots of Links (TRILL) Protocol Control 931 Protocol", RFC 6361, August 2011 933 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 934 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 935 BCP 141, RFC 7042, October 2013. 937 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 938 "Transparent Interconnection of Lots of Links (TRILL): 939 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 940 May 2014. 942 [RFC7435] - Dukhovni, V., "Opportunistic Security: Some Protection 943 Most of the Time", RFC 7435, December 2014, . 946 [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 947 Known Attacks on Transport Layer Security (TLS) and Datagram 948 TLS (DTLS)", RFC 7457, February 2015, . 951 Appendix Z: Change History 953 From -00 to -01 955 1. Fix references for RFCs published, etc. 957 2. Explicitly mention in the Abstract and Introduction that this 958 document updates [RFC7178]. 960 3. Add this Change History Appendix. 962 From -01 to -02 964 1. Remove section on the "Scope" feature as mentioned in 965 http://www.ietf.org/mail-archive/web/trill/current/msg06531.html 967 2. Editorial changes to IANA Considerations to correspond to draft- 968 leiba-cotton-iana-5226bis-11.txt. 970 3. Improvements to the Ethernet frame payload type. 972 4. Other Editorial changes. 974 From -02 to -03 976 1. Update TRILL Header to correspond to [rfc7180bis]. 978 2. Remove a few remnants of the "Scope" feature that was removed from 979 -01 to -02. 981 3. Substantial changes to and expansion of Section 4 including adding 982 details of DTLS security. 984 4. Updates and additions to the References. 986 5. Other minor editorial changes. 988 From -03 to -04 990 1. Add SType for [RFC5310] keying based security that provides 991 encryption as well as authentication. 993 2. Editorial improvements and fixes. 995 From -04 to -05 997 1. Primary change is collapsing the previous PTypes 2, 3, and 4 for 998 RBridge Channel message, TRILL Data, and TRILL IS-IS into one by 999 including the Ethertype. Previous PType 5 is renumbered as 3. 1001 2. Add Channel Tunnel Crypto Suites to IANA Considerations 1003 3. Add some material to Security Considerations, 1005 4. Assorted Editorial changes. 1007 From -05 to -06 1009 Fix editorials found during WG Last Call. 1011 From -06 to -07 1013 Minor editorial changes resulting for Shepherd review. 1015 Acknowledgements 1017 The contributions of the following are hereby acknowledged: 1019 Susan Hares, Gayle Noble 1021 The document was prepared in raw nroff. All macros used were defined 1022 within the source file. 1024 Authors' Addresses 1026 Donald E. Eastlake, 3rd 1027 Huawei Technologies 1028 155 Beaver Street 1029 Milford, MA 01757 USA 1031 Phone: +1-508-333-2270 1032 EMail: d3e3e3@gmail.com 1034 Mohammed Umair 1035 IPinfusion 1037 EMail: mohammed.umair2@gmail.com 1039 Yizhou Li 1040 Huawei Technologies 1041 101 Software Avenue, 1042 Nanjing 210012, China 1044 Phone: +86-25-56622310 1045 EMail: liyizhou@huawei.com 1047 Copyright, Disclaimer, and Additional IPR Provisions 1049 Copyright (c) 2015 IETF Trust and the persons identified as the 1050 document authors. All rights reserved. 1052 This document is subject to BCP 78 and the IETF Trust's Legal 1053 Provisions Relating to IETF Documents 1054 (http://trustee.ietf.org/license-info) in effect on the date of 1055 publication of this document. Please review these documents 1056 carefully, as they describe your rights and restrictions with respect 1057 to this document. Code Components extracted from this document must 1058 include Simplified BSD License text as described in Section 4.e of 1059 the Trust Legal Provisions and are provided without warranty as 1060 described in the Simplified BSD License. The definitive version of 1061 an IETF Document is that published by, or under the auspices of, the 1062 IETF. Versions of IETF Documents that are published by third parties, 1063 including those that are translated into other languages, should not 1064 be considered to be definitive versions of IETF Documents. The 1065 definitive version of these Legal Provisions is that published by, or 1066 under the auspices of, the IETF. Versions of these Legal Provisions 1067 that are published by third parties, including those that are 1068 translated into other languages, should not be considered to be 1069 definitive versions of these Legal Provisions. For the avoidance of 1070 doubt, each Contributor to the IETF Standards Process licenses each 1071 Contribution that he or she makes as part of the IETF Standards 1072 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1073 language to the contrary, or terms, conditions or rights that differ 1074 from or are inconsistent with the rights and licenses granted under 1075 RFC 5378, shall have any effect and shall be null and void, whether 1076 published or posted by such Contributor, or included with or in such 1077 Contribution.