idnits 2.17.1 draft-ietf-trill-channel-tunnel-11.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 5, 2016) is 2820 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) -- Looks like a reference, but probably isn't: '4' on line 812 -- 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 (==), 4 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 4, 2017 August 5, 2016 9 TRILL: RBridge Channel Header Extension 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 between 17 TRILL switches in the same campus and the transmission of such 18 messages between TRILL switches and end stations on the same link. 19 This document specifies extensions to the RBridge Channel protocol 20 header to support two features as follows: (1) a standard method to 21 tunnel payloads whose type can be indicated by Ethertype through 22 encapsulation in RBridge Channel messages; and (2) a method to 23 support security facilities for RBridge Channel messages. This 24 document updates RFC 7178. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Distribution of this document is unlimited. Comments should be sent 32 to the authors or the TRILL working group mailing list: 33 trill@ietf.org 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 47 Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Table of Contents 52 1. Introduction............................................3 53 1.1 Terminology and Acronyms..............................3 55 2. RBridge Channel Header Extension Format.................5 57 3. Extended RBridge Channel Payload Types..................8 58 3.1 Null Payload...........................................8 59 3.2 Ethertyped Payload.....................................8 60 3.2.1 RBridge Channel Message as the Payload...............9 61 3.2.2 TRILL Data Packet as the Payload.....................9 62 3.2.3 TRILL IS-IS Packet as the Payload...................10 63 3.3 Ethernet Frame........................................11 65 4. Extended RBridge Channel Security......................14 66 4.1 Derived Keying Material...............................14 67 4.2 SType None............................................15 68 4.3 [RFC5310]-Based Authentication........................15 69 4.4 DTLS Pairwise Security................................17 70 4.5 Composite Security....................................18 72 5. Extended RBridge Channel Errors........................19 73 5.1 SubERRs...............................................19 74 5.2 Secure Nested RBridge Channel Errors..................19 76 6. IANA Considerations....................................21 77 6.1 Extended RBridge Channel Protocol Number..............21 78 6.2 RBridge Channel Protocol Subregistries................21 79 6.2.1 RBridge Channel Error Codes.........................21 80 6.2.2 RBridge Channel SubError Codes......................21 81 6.2.3 Extended RBridge Channel Payload Types Subregistry..22 82 6.2.4 Extended RBridge Channel Security Types Subregistry.22 84 7. Security Considerations................................23 86 Normative References......................................24 87 Informative References....................................25 89 Appendix Z: Change History................................27 90 Acknowledgements..........................................29 91 Authors' Addresses........................................30 93 1. Introduction 95 The IETF TRILL base protocol [RFC6325] [RFC7780] has been extended 96 with the RBridge Channel [RFC7178] facility to support transmission 97 of typed messages (for example BFD (Bidirectional Forwarding 98 Detection) [RFC7175]) between two TRILL switches (RBridges) in the 99 same campus and the transmission of such messages between RBridges 100 and end stations on the same link. When sent between RBridges in the 101 same campus, a TRILL Data packet with a TRILL Header is used and the 102 destination RBridge is indicated by nickname. When sent between a 103 RBridge and an end station on the same link in either direction, a 104 native RBridge Channel message [RFC7178] is used with no TRILL Header 105 and the destination port or ports are indicated by a MAC address. 106 (There is no mechanism to stop end stations on the same link from 107 sending native RBridge Channel messages to each other; however, such 108 use is outside the scope of this document.) 110 This document updates [RFC7178] and specifies extensions to the 111 RBridge Channel header that provide two additional facilities as 112 follows: 114 (1) A standard method to tunnel payloads whose type may be 115 indicated by Ethertype through encapsulation in RBridge 116 Channel messages. 118 (2) A method to provide security facilities for RBridge Channel 119 messages. Example uses requiring such facilities are the 120 security of Pull Directory messages [RFC7067], address flush 121 messages [AddrFlush], and port shutdown messages [rfc6439bis]. 123 Use of each of these facilities is optional, except that, as 124 specified below, if this header extension is implemented there are 125 two payload types that MUST be implemented. Both of the above 126 facilities can be used in the same packet. In case of conflict 127 between this document and [RFC7178], this document takes precedence. 129 1.1 Terminology and Acronyms 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in 134 [RFC2119]. 136 This document uses terminology and acronyms defined in [RFC6325] and 137 [RFC7178]. Some of these are repeated below for convenience along 138 with additional new terms and acronyms. 140 application_data - A DTLS [RFC6347] message type. 142 Data Label - VLAN or FGL. 144 DTLS - Datagram Transport Level Security [RFC6347]. 146 FCS - Frame Check Sequence. 148 FGL - Fine Grained Label [RFC7172]. 150 HKDF - HMAC-based Key Derivation Function [RFC5869]. 152 IS-IS - Intermediate System to Intermediate Systems [IS-IS]. 154 PDU - Protocol Data Unit. 156 MTU - Maximum Transmission Unit. 158 RBridge - An alternative term for a TRILL switch. 160 SHA - Secure Hash Algorithm [RFC6234]. 162 Sz - Campus-wide minimum link MTU [RFC6325] [RFC7780]. 164 TRILL - Transparent Interconnection of Lots of Links or Tunneled 165 Routing in the Link Layer. 167 TRILL switch - A device that implements the TRILL protocol 168 [RFC6325] [RFC7780], sometimes referred to as an RBridge. 170 2. RBridge Channel Header Extension Format 172 The general structure of an RBridge Channel message between two TRILL 173 switches (RBridges) in the same campus is shown in Figure 2.1 below. 174 The structure of a native RBridge Channel message sent between an 175 RBridge and an end station on the same link, in either direction, is 176 shown in Figure 2.2 and, compared with the first case, omits the 177 TRILL Header, inner Ethernet addresses, and Data Label. A Protocol 178 field in the RBridge Channel Header gives the type of RBridge Channel 179 message and indicates how to interpret the Channel Protocol Specific 180 Payload [RFC7178]. 182 +-----------------------------------+ 183 | Link Header | 184 +-----------------------------------+ 185 | TRILL Header | 186 +-----------------------------------+ 187 | Inner Ethernet Addresses | 188 +-----------------------------------+ 189 | Data Label (VLAN or FGL) | 190 +-----------------------------------+ 191 | RBridge Channel Header | 192 +-----------------------------------+ 193 | Channel Protocol Specific Payload | 194 +-----------------------------------+ 195 | Link Trailer (FCS if Ethernet) | 196 +-----------------------------------+ 198 Figure 2.1 RBridge Channel Packet Structure 200 +-----------------------------------+ 201 | Ethernet Link Header | 202 +-----------------------------------+ 203 | RBridge Channel Header | 204 +-----------------------------------+ 205 | Channel Protocol Specific Payload | 206 +-----------------------------------+ 207 | FCS | 208 +-----------------------------------+ 210 Figure 2.2 Native RBridge Channel Frame 212 The RBridge Channel Header looks like this: 214 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | 0x8946 | CHV=0 | Channel Protocol | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Flags | ERR | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 221 / Channel Protocol Specific Data / 222 /-+-+-+-+-+- / 224 Figure 2.3 RBridge Channel Header 226 where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel 227 Header Version. This document is based on RBridge Channel version 228 zero. 230 The header extensions specified herein are in the form of an RBridge 231 Channel protocol, the Extended RBridge Channel Protocol. Figure 2.4 232 below expands the RBridge Channel Header and Protocol Specific 233 Payload above for the case where the header extension is present. 235 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 236 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 237 RBridge Channel Header: 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | 0x8946 | CHV=0 | Channel Protocol=[TBD]| 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Flags | ERR | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Header Extension Specific: | SubERR| RESV4 | SType | PType | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Security Information, variable length (0 length if SType = 0) / 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 248 | Tunneled Data, variable length 249 | ... 251 Figure 2.4 RBridge Channel Header Extension Structure 253 The RBridge Channel Header Protocol field is used to indicate that 254 the header extension is present. Its contents MUST be the value 255 allocated for this purpose (see Section 6). The use of an RBridge 256 Channel protocol to indicate extension makes it easy to determine if 257 a remote RBridge in the campus supports extension since RBridges 258 advertise in their LSP which such protocols they support. 260 The Extended RBridge Channel Protocol Specific Data fields are as 261 follows: 263 SubERR: This field provides further details when an error is 264 indicated in the RBridge Channel ERR field. If ERR is zero, 265 then SubERR MUST be sent as zero and ignored on receipt. See 266 Section 5. 268 RESV4: This field MUST be sent as zero. If non-zero when received, 269 this is an error condition (see Section 5). 271 SType: This field describes the type of security information and 272 features, including keying material, being used or provided by 273 the extended RBridge Channel message. See Section 4. 275 PType: Payload type. This describes the tunneled data. See Section 276 3 below. 278 Security Information: Variable length information. Length is zero 279 if SType is zero. See Section 4. 281 The RBridge Channel Header Extension is integrated with the RBridge 282 Channel facility. Extension errors are reported as if they were 283 RBridge Channel errors, using newly allocated code points in the ERR 284 field of the RBridge Channel Header supplemented by the SubERR field. 286 3. Extended RBridge Channel Payload Types 288 The Extended RBridge Channel Protocol can carry a variety of payloads 289 as indicated by the PType (Payload Type) field. Values are shown in 290 the table below with further explanation after the table (see also 291 Section 6.2.2). 293 PType Description Reference 294 ----- ----------- --------- 295 0 Reserved 296 1 Null Section 3.1 of [this doc] 297 2 Ethertyped Payload Section 3.2 of [this doc] 298 3 Ethernet Frame Section 3.3 of [this doc] 299 4-14 Unassigned 300 15 Reserved 302 Table 3.1 Payload Type Values 304 While implementation of the RBridge Channel Header Extension is 305 optional, if it is implemented PType 1 (Null) MUST be implemented and 306 PType 2 (Ethertyped Payload) with the RBridge Channel Ethertype MUST 307 be implemented. PType 2 for any Ethertypes other than the RBridge 308 Channel Ethertype MAY be implemented. PType 3 MAY be implemented. 310 The processing of any particular extended header RBridge Channel 311 message and its payload depends on meeting local security and other 312 policy at the destination TRILL switch or end station. 314 3.1 Null Payload 316 The Null payload type (PType = 1) is intended to be used for testing 317 or for messages such as key negotiation or the like where only 318 security information is present. It indicates that there is no user 319 data payload. Any tunneled user data after the Security Information 320 field is ignored. If the RBridge Channel Header Extension is 321 implemented, the Null Payload MUST be supported in the sense that an 322 "Unsupported PType" error is not returned (see Section 5). Any 323 particular use of the Null Payload should specify what VLAN or FGL 324 and what priority should be used in the inner Data Label of the 325 RBridge Channel message (or in an outer VLAN tag for the native 326 RBridge Channel message case) when those values are relevant. 328 3.2 Ethertyped Payload 330 A PType of 2 indicates that the payload (tunneled data) of the 331 extended RBridge Channel message begins with an Ethertype. A TRILL 332 switch supporting the RBridge Channel Header Extension MUST support a 333 PType of 2 with a payload beginning with the RBridge Channel 334 Ethertype as described in Section 3.2.1. Other Ethertypes, including 335 the TRILL and L2-IS-IS Ethertypes as described in Section 3.2.2 and 336 3.2.3, MAY be supported. 338 3.2.1 RBridge Channel Message as the Payload 340 A PType of 2 whose payload has an initial RBridge Channel Ethertype 341 indicates an encapsulated RBridge Channel message. A typical reason 342 for sending an RBridge Channel message inside an extended RBridge 343 Channel message is to provide security services, such as 344 authentication or encryption, for the encapsulated message. 346 This RBridge Channel message type looks like the following: 348 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=[TBD]| 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 / Security Information, variable length (0 length if SType = 0) / 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol| 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Flags | ERR | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 361 | Nested Channel Protocol Specific Data ... / 362 / / 364 Figure 3.1 Message Structure with RBridge Channel Payload 366 3.2.2 TRILL Data Packet as the Payload 368 A PType of 2 whose payload has an initial TRILL Ethertype indicates 369 an encapsulated TRILL Data packet as shown in the figure below. If 370 this Ethertype is supported for PType = 2 and the message meets local 371 policy for acceptance, the TRILL Data packet is handled as if it had 372 been received by the destination TRILL switch on the port where the 373 Extended RBridge Channel message was received. 375 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=[TBD]| 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 / Security Information, variable length (0 length if SType = 0) / 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Egress Nickname | Ingress Nickname | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 / Optional Flags Word / 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Inner.MacDA | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Inner.MacDA continued | Inner.MacSA | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Inner.MacSA (cont.) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Inner Data Label (2 or 4 bytes) 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 398 | TRILL Data Packet payload 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 401 Figure 3.2 Message Structure with TRILL Data Packet Payload 403 The optional flags word is only present if the F bit in the TRILL 404 Header is one [RFC7780]. 406 3.2.3 TRILL IS-IS Packet as the Payload 408 A PType of 2 and an initial L2-IS-IS Ethertype indicates that the 409 payload of the Extended RBridge Channel protocol message is an 410 encapsulated TRILL IS-IS PDU as shown in Figure 3.3. If this 411 Ethertype is supported for PType = 2, the tunneled TRILL IS-IS packet 412 is processed by the destination RBridge if it meets local policy. One 413 possible use is to expedite the receipt of a link state PDU (LSP) by 414 some TRILL switch or switches with an immediate requirement for the 415 link state information. A link local IS-IS PDU (Hello, CSNP, or PSNP 416 [IS-IS]; MTU-probe or MTU-ack [RFC7176]; or circuit scoped FS-LSP, 417 FS-CSNP or FS-PSNP [RFC7356]) would not normally be sent via this 418 Extended RBridge Channel method except possibly to encrypt it since 419 such PDUs can just be transmitted on the link and do not normally 420 need RBridge Channel handling. 422 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=[TBD]| 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 / Security Information, variable length (0 length if SType = 0) / 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 431 | L2-IS-IS (0x22F4) | 0x83 | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | rest of IS-IS PDU 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 436 Figure 3.3 Message Structure with TRILL IS-IS Packet Payload 438 3.3 Ethernet Frame 440 If PType is 3, the extended RBridge Channel payload is an Ethernet 441 frame as might be received from or sent to an end station except that 442 the encapsulated Ethernet frame's FCS is omitted, as shown in Figure 443 3.4. (There is still an overall final FCS if the RBridge Channel 444 message is being sent on an Ethernet link.) If this PType is 445 implemented and the message meets local policy, the encapsulated 446 frame is handled as if it had been received on the port on which the 447 Extended RBridge Channel message was received. 449 The priority of the RBridge Channel message can be copied from the 450 Ethernet frame VLAN tag, if one is present, except that priority 7 451 SHOULD only be used for messages critical to establishing or 452 maintaining adjacency and priority 6 SHOULD only be used for other 453 important control messages. 455 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol=[TBD]| 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Flags | ERR | SubERR| RESV4 | SType | 0x3 | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 / Security Information, variable length (0 length if SType = 0) / 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | MacDA | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | MacDA (cont.) | MacSA | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | MacSA (cont.) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Any Ethernet frame tagging... 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 472 | Ethernet frame payload... 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 475 Figure 3.4 Message Structure with Ethernet Frame Payload 477 In the case of a non-Ethernet link, such as a PPP (Point-to-Point 478 Protocol) link [RFC6361], the ports on the link are considered to 479 have link-local synthetic 48-bit MAC addresses constructed as 480 described below. Such a constructed address MAY be used as a MacSA. 481 If the RBridge Channel message is individually addressed to a link 482 local port, the source TRILL switch will have the information to 483 construct such a MAC address for the destination TRILL switch port 484 and that MAC address MAY be used as the MacDA. By the use of such a 485 MacSA and either such a unicast MacDA or a group addressed MacDA, an 486 Ethernet frame can be sent between two TRILL switch ports connected 487 by a non-Ethernet link. 489 These synthetic TRILL switch port MAC addresses for non-Ethernet 490 ports are constructed as follows: 0xFEFF, the nickname of the TRILL 491 switch used in TRILL Hellos sent on that port, and the Port ID that 492 the TRILL switch has assigned to that port, as shown in Figure 3.5. 493 (Both the Port ID of the port on which a TRILL Hello is sent and the 494 nickname of the sending TRILL switch appear in the Special VLANs and 495 Flags sub-TLV [RFC7176] in TRILL IS-IS Hellos.) The resulting MAC 496 address has the Local bit on and the Group bit off [RFC7042]. 497 However, since there will be no Ethernet end stations on a non- 498 Ethernet link in a TRILL campus, such synthetic MAC addresses cannot 499 conflict on the link with a real Ethernet port address regardless of 500 their value. 502 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | 0xFEFF | Nickname | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Port ID | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 3.5 Synthetic MAC Address 512 4. Extended RBridge Channel Security 514 Table 4.1 below gives the assigned values of the SType (Security 515 Type) field and their meaning. Use of DTLS Pairwise Security (SType = 516 2) or Composite Security (SType = 3) is RECOMMENDED. 518 While [RFC5310]-based authentication is also specified and can be 519 used for both pairwise and multi-destination traffic, it provides 520 only authentication and is not considered to meet current security 521 standards. For example, it does not provide for key negotiation; 522 thus, its use is NOT RECOMMENDED. 524 The Extended RBridge Channel DTLS-based security specified in Section 525 4.4 and the Composite Security specified in Section 4.5 below are 526 intended for pairwise (known unicast) use. That is, the case where 527 the M bit in the TRILL Header is zero and any Outer.MacDA is 528 individually addressed. 530 Multi-destination Extended RBridge Channel packets would be those 531 with the M bit in the TRILL Header set to one or, in the native 532 RBridge Channel case, the Outer.MacDA would be group addressed. The 533 DTLS Pairwise Security and Composite Security STypes can also be used 534 in the multi-destination case by serially unicasting the messages to 535 all data-accessible RBridges (or stations in the native RBridge 536 Channel case) in the recipient group. For TRILL Data packets, that 537 group is specified by the Data Label; for native frames, the group is 538 specified by the groupcast destination MAC address. It is intended to 539 specify a true group keyed SType to secure multi-destination packets 540 in a separate document [GroupKey]. 542 SType Description Reference 543 ----- ----------- --------- 544 0 None Section 4.2 of [this doc] 545 1 [RFC5310]-Based Authentication Section 4.3 of [this doc] 546 2 DTLS Pairwise Security Section 4.4 of [this doc] 547 3 Composite Security Section 4.5 of [this doc] 548 4-14 Unassigned 549 15 Reserved 551 Table 4.1 SType Values 553 4.1 Derived Keying Material 555 In some cases, it is possible to use material derived from [RFC5310] 556 IS-IS keying material as an element of Extended RBridge Channel 557 security. It is assumed that the IS-IS keying material is of high 558 quality. The material actually used is derived from the IS-IS keying 559 material as follows: 561 Derived Material = 562 HKDF-Expand-SHA256 ( IS-IS-key, "Extended Channel" | 0x0S, L ) 564 where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is 565 as in [RFC6234], IS-IS-key is the input IS-IS keying material, 566 "Extended Channel" is the 16-character ASCII [RFC20] string indicated 567 without any leading length byte or trailing zero byte, 0x0S is a 568 single byte where S is the SType for which this key derivation is 569 being used and the upper nibble is zero, and L is the length of the 570 output-derived material needed. 572 Whenever IS-IS keying material is being used as above, the underlying 573 [RFC5310] keying material might expire or be invalidated. At the time 574 of or before such expiration or invalidation, the use of the Derived 575 Material from the IS-IS keying material MUST cease. Continued 576 security MAY use new derived material from currently valid [RFC5310] 577 keying material. 579 4.2 SType None 581 No security services are being invoked. The length of the Security 582 Information field (see Figure 2.4) is zero. 584 4.3 [RFC5310]-Based Authentication 586 This SType provides security for Extended RBridge Channel messages 587 similar to that provided for [IS-IS] PDUs by the [IS-IS] 588 Authentication TLV. The Security Information (see Figure 2.4) is as 589 shown in Figure 4.1. 591 1 1 1 1 1 1 592 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | RESV | Size | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Key ID | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | | 599 + 600 | Authentication Data (Variable) 601 + 602 | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-... 605 Figure 4.1 SType 1 Security Information 607 o RESV: Four bits that MUST be sent as zero and ignored on receipt. 609 o Size: Set to 2 + the size of Authentication Data in bytes. 611 o Key ID: specifies the keying value and authentication algorithm 612 that the Key ID specifies for TRILL IS-IS LSP [RFC5310] 613 Authentication TLVs. The keying material actually used is always 614 derived as shown in Section 4.1. 616 o Authentication Data: The authentication data produced by the 617 derived key and algorithm associated with the Key ID acting on the 618 part of the TRILL Data packet shown. Length of the authentication 619 data depends on the algorithm. The authentication value is 620 included in the security information field and is treated as zero 621 when authentication is calculated. 623 As show in Figure 4.2, the area covered by this authentication starts 624 with the byte immediately after the TRILL Header optional Flag Word 625 if it is present. If the Flag Word is not present, it starts after 626 the TRILL Header Ingress Nickname. In either case, it extends to just 627 before the TRILL Data packet link trailer. For example, for an 628 Ethernet packet it would extend to just before the FCS. 630 +-----------------------------+ 631 | Link Header | 632 +-----------------------------+ 633 | TRILL Header | 634 | (plus optional flag word) | 635 +-----------------------------+ ^ 636 | Inner Ethernet Addresses | | 637 +-----------------------------+ . 638 | Data Label (VLAN or FGL) | | 639 +-----------------------------+ . 640 | RBridge Channel Header | | <-authentication 641 +-----------------------------+ . 642 | Extended Channel Header | | 643 | (plus Security Information)| . 644 +-----------------------------+ | 645 | Payload | . 646 +-----------------------------+ v 647 | Link Trailer | 648 +-----------------------------+ 650 Figure 4.2. SType 1 Authentication Coverage 652 In the native RBridge Channel case this authentication coverage is as 653 specified in the above paragraph except that it starts with the 654 RBridge Channel Ethertype, since there is no TRILL Header, inner 655 Ethernet addresses, or inner Data Label (see Figure 4.3). 657 +-----------------------------+ 658 | Ethernet Header | 659 +-----------------------------+ ^ 660 | RBridge Channel Header | | 661 +-----------------------------+ . 662 | Extended Channel Header | | <-authentication 663 | (plus Security Information)| . 664 +-----------------------------+ | 665 | Payload | . 666 +-----------------------------+ v 667 | Ethernet Trailer | 668 +-----------------------------+ 670 Figure 4.3. Native SType 1 Authentication Coverage 672 While RBridges, which are IS-IS routers, can reasonably be expected 673 to hold [RFC5310] keying so that this SType can be used for RBridge 674 Channel messages, how end stations might come to hold [RFC5310] 675 keying is beyond the scope of this document. Thus this SType might 676 not be applicable to native RBridge Channel messages. 678 4.4 DTLS Pairwise Security 680 DTLS [RFC6347] supports key negotiation and provides both encryption 681 and authentication. The RBridge Channel Extended Header DTLS Pairwise 682 SType uses a negotiated DTLS version that MUST NOT be less than 1.2. 684 When DTLS pairwise security is used, the entire payload of the 685 Extended RBridge Channel packet, starting just after the null 686 Security Information and ending just before the link trailer, is one 687 or more DTLS records [RFC6347]. As specified in [RFC6347], DTLS 688 records MUST be limited by the path MTU, in this case so each record 689 fits entirely within a single Extended RBridge Channel message. A 690 minimum path MTU can be determined from the TRILL campus minimum MTU 691 Sz, which will not be less than 1470 bytes, by allowing for the TRILL 692 Data packet, extended RBridge Channel, and DTLS framing overhead. 693 With this SType, the security information between the extended 694 RBridge Channel header and the payload is null because all the 695 security information is in the payload area. 697 The DTLS Pairwise keying is set up between a pair of RBridges 698 independent of Data Label using messages of a priority configurable 699 at the RBridge level which defaults to priority 6. DTLS message types 700 other than application_data can be the payload of an extended RBridge 701 Channel message with a TRILL Header using any Data Label and, for 702 such DTLS message types, the PType in the RBridge Channel Header 703 Extension is ignored. 705 Actual application_data sent within such a message using this SType 706 SHOULD use the Data Label and priority as specified for that 707 application_data. In this case, the PType value in the RBridge 708 Channel Header Extension applies to the decrypted application_data. 710 TRILL switches that implement the extended RBridge Channel DTLS 711 Pairwise SType SHOULD support the use of certificates for DTLS but 712 certificate size may be limited by the DTLS requirement that each 713 record fit within a single message. Appropriate certificate contents 714 is out of scope for this document. 716 TRILL switches that support the extended RBridge Channel DTLS 717 Pairwise SType MUST support the use of pre-shared keys. If the 718 psk_identity (see [RFC4279]) is two bytes, it is interpreted as a 719 [RFC5310] Key ID and the value derived as shown in Section 4.1 from 720 that key is used as a pre-shared key for DTLS negotiation. A 721 psk_identity with a length other than two bytes MAY be used to 722 indicate other implementation dependent pre-shared keys. Pre-shared 723 keys used for DTLS negotiation SHOULD be shared only by the pair of 724 end points; otherwise, security could be attacked by diverting 725 messages to another end point holding that pre-shared key. 727 4.5 Composite Security 729 Composite Security (SType = 3) is the combination of DTLS Pairwise 730 Security and [RFC5310]-Based Authentication. On transmission, the 731 DTLS record or records to be sent are secured as specified in Section 732 4.4 then used as the payload for the application of Authentication as 733 specified in Section 4.3. On reception, the [RFC5310]-based 734 authentication is verified first and an error returned if it fails. 735 If the [RFC5310]-based authentication succeeds, then the DTLS 736 record(s) are processed. 738 An advantage of Composite Security is that the payload is 739 authenticated and encrypted with a modern security protocol and, in 740 addition, the RBridge Channel Header and (except in the native case) 741 preceding MAC addresses and Data Label are provided with some 742 authentication. 744 5. Extended RBridge Channel Errors 746 RBridge Channel Header Extension errors are reported like RBridge 747 Channel errors. The ERR field is set to one of the following error 748 codes: 750 Value RBridge Channel Error Code Meaning 751 ----- ------------------------------------ 752 6 Unknown or unsupported field value 753 7 Authentication failure 754 8 Error in nested RBridge Channel message 756 Table 5.1 Additional ERR Values 758 5.1 SubERRs 760 If the ERR field is 6, the SubERR field indicates the problematic 761 field or value as shown in the table below. At this time no suberrror 762 codes are assigned under any other ERR field value. 764 Err SubERR Meaning (for ERR = 6) 765 --- ------ ----------------------- 766 0 No Error, suberrors not allowed 767 1-5 (no suberrors assigned) 768 6 0 Reserved 769 6 1 Non-zero RESV4 nibble 770 6 2 Unsupported SType 771 6 3 Unsupported PType 772 6 4 Unknown Key ID 773 6 5 Unsupported Ethertype with PType = 2 774 6 6 Unsupported authentication algorithm for SType = 1 775 6 7 Non-zero SubERR with zero ERR field 776 7-14 (no suberrors assigned) 777 15 (Reserved) 779 Table 5.2 SubERR values 781 5.2 Secure Nested RBridge Channel Errors 783 If 784 an extended RBridge Channel message is sent with security and with 785 a payload type (PType) indicating an Ethertyped payload and the 786 Ethertype indicates a nested RBridge Channel message 787 and 788 there is an error in the processing of that nested message that 789 results in a return RBridge Channel message with a non-zero ERR 790 field, 791 then that returned message SHOULD also be nested in an extended 792 RBridge Channel message using the same type of security. In this 793 case, the ERR field in the Extended RBridge Channel envelope is set 794 to 8 indicating that there is a nested error in the message being 795 tunneled back. 797 6. IANA Considerations 799 This section lists IANA Considerations. 801 6.1 Extended RBridge Channel Protocol Number 803 IANA is requested to assign TBD [4 recommended] from the range 804 assigned by Standards Action as the RBridge Channel protocol number 805 to indicate RBridge Channel Header Extension. 807 The added RBridge Channel protocols registry entry on the TRILL 808 Parameters web page is as follows: 810 Protocol Description Reference 811 -------- -------------------------- ---------------- 812 TBD[4] RBridge Channel Extension [this document] 814 6.2 RBridge Channel Protocol Subregistries 816 IANA is requested to create three subregistries under the "RBridge 817 Channel Protocols" registry as in the subsections below. 819 6.2.1 RBridge Channel Error Codes 821 IANA is requested to assign three additional code points in the 822 "RBridge Channel Error Codes" registry on the TRILL Parameters web 823 page. The additional entries are as show in Table 5.1 in Section 5 824 and the "Reference" column value is "[this document]". 826 6.2.2 RBridge Channel SubError Codes 828 IANA is request to create a subregistry indented under the RBridge 829 Channel Error Codes registry, for RBridge Chanel SubError Code. The 830 initial contents of this subregistry is as show in Table 5.2 in 831 Section 5.1 except that a fourth column "Reference" is added with 832 value "[this document]" for all rows. The header information is as 833 follows: 835 Registry Name: RBridge Channel SubError Codes 836 Registration Procedures: IETF Review 837 Reference: [this document] 839 6.2.3 Extended RBridge Channel Payload Types Subregistry 841 IANA is requested to create an "Extended RBridge Channel Payload 842 Types" registry after the "RBridge Channel Protocols" registry on the 843 TRILL Parameters web page. The header information is as follows: 845 Registration Procedures: IETF Review 846 Reference: [this document] 848 The initial registry content is Table 3.1 in Section 3 of this 849 document. 851 6.2.4 Extended RBridge Channel Security Types Subregistry 853 IANA is requested to create an "Extended RBridge Channel Security 854 Types" registry after the "Extended RBridge Channel Payload Types" 855 registry on the TRILL Parameters web page. The header information is 856 as follows: 858 Registration Procedures: IETF Review 859 Reference: [this document] 861 The initial registry content is Table 4.1 in Section 4 of this 862 document. 864 7. Security Considerations 866 The RBridge Channel Header Extension has potentially positive and 867 negative effects on security. 869 On the positive side, it provides optional security that can be used 870 to authenticate and/or encrypt RBridge Channel messages. Some RBridge 871 Channel message payloads, such as BFD [RFC7175], provide their own 872 security but where this is not true, consideration should be given, 873 when specifying an RBridge Channel protocol, to recommending or 874 requiring use of the security features of the RBridge Channel Header 875 Extension. 877 On the negative side, the optional ability to tunnel more payload 878 types and to tunnel them between TRILL switches and to and from end 879 stations can increase risk unless precautions are taken. The 880 processing of decapsulated extended RBridge Channel payloads is a 881 place where you SHOULD NOT be liberal in what you accept. This is 882 because the tunneling facility makes it easier for unexpected 883 messages to pop up in unexpected places in a TRILL campus due to 884 accidents or the actions of an adversary. Local policies SHOULD 885 generally be strict and only accept payload types required and then 886 only with adequate security for the particular circumstances. 888 See the first paragraph of Section 4 for recommendations on SType 889 usage. 891 See [RFC7457] for Security Considerations of DTLS for security. 893 If IS-IS authentication is not being used, then [RFC5310] keying 894 information would not normally be available but that presumably 895 represents a judgment by the TRILL campus operator that no security 896 is needed. 898 See [RFC7178] for general RBridge Channel Security Considerations and 899 [RFC6325] for general TRILL Security Considerations. 901 Normative References 903 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology 904 -- Telecommunications and information exchange between systems 905 -- Intermediate System to Intermediate System intra-domain 906 routeing information exchange protocol for use in conjunction 907 with the protocol for providing the connectionless-mode network 908 service (ISO 8473)", 2002. 910 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, 911 RFC 20, DOI 10.17487/RFC0020, October 1969, . 914 [RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate 915 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 916 March 1997, . 918 [RFC4279] - Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key 919 Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 920 10.17487/RFC4279, December 2005, . 923 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 924 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 925 5310, DOI 10.17487/RFC5310, February 2009, . 928 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 929 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 930 . 932 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 933 Ghanwani, "Routing Bridges (RBridges): Base Protocol 934 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 935 . 937 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 938 Security Version 1.2", RFC 6347, January 2012, . 941 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 942 and D. Dutt, "Transparent Interconnection of Lots of Links 943 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 944 10.17487/RFC7172, May 2014, . 947 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 948 D., and A. Banerjee, "Transparent Interconnection of Lots of 949 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 950 . 952 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 953 Ward, "Transparent Interconnection of Lots of Links (TRILL): 954 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 955 2014, . 957 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 958 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 959 . 961 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 962 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 963 Lots of Links (TRILL): Clarifications, Corrections, and 964 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 965 . 967 Informative References 969 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 970 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 971 10.17487/RFC6234, May 2011, . 974 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 975 Interconnection of Lots of Links (TRILL) Protocol Control 976 Protocol", RFC 6361, August 2011 978 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 979 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 980 BCP 141, RFC 7042, October 2013. 982 [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 983 Gashinsky, "Directory Assistance Problem and High-Level Design 984 Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, 985 . 987 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 988 "Transparent Interconnection of Lots of Links (TRILL): 989 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 990 May 2014. 992 [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 993 Known Attacks on Transport Layer Security (TLS) and Datagram 994 TLS (DTLS)", RFC 7457, February 2015, . 997 [AddrFlush] - W. Hao, D. Eastlake, Y. Li, "TRILL: Address Flush 998 Message", draft-ietf-trill-address-flush, work in progress. 1000 [GroupKey] - D. Eastlake et al, "Group Keying Protocol", draft- 1001 eastlake-trill-group-keying, work in progress. 1003 [rfc6439bis] - D. Eastlake, Y. Li, M. Umair, A. Banerjee, H. Fangwei, 1004 "TRILL: Appointed Forwarders", draft-ietf-trill-rfc6439bis, 1005 work in progress. 1007 Appendix Z: Change History 1009 RFC Editor: Please delete this Appendix before publication. 1011 From -00 to -01 1013 1. Fix references for RFCs published, etc. 1015 2. Explicitly mention in the Abstract and Introduction that this 1016 document updates [RFC7178]. 1018 3. Add this Change History Appendix. 1020 From -01 to -02 1022 1. Remove section on the "Scope" feature as mentioned in 1023 http://www.ietf.org/mail-archive/web/trill/current/msg06531.html 1025 2. Editorial changes to IANA Considerations to correspond to draft- 1026 leiba-cotton-iana-5226bis-11.txt. 1028 3. Improvements to the Ethernet frame payload type. 1030 4. Other Editorial changes. 1032 From -02 to -03 1034 1. Update TRILL Header to correspond to [RFC7780]. 1036 2. Remove a few remnants of the "Scope" feature that was removed from 1037 -01 to -02. 1039 3. Substantial changes to and expansion of Section 4 including adding 1040 details of DTLS security. 1042 4. Updates and additions to the References. 1044 5. Other minor editorial changes. 1046 From -03 to -04 1048 1. Add SType for [RFC5310] keying based security that provides 1049 encryption as well as authentication. 1051 2. Editorial improvements and fixes. 1053 From -04 to -05 1055 1. Primary change is collapsing the previous PTypes 2, 3, and 4 for 1056 RBridge Channel message, TRILL Data, and TRILL IS-IS into one by 1057 including the Ethertype. Previous PType 5 is renumbered as 3. 1059 2. Add Channel Tunnel Crypto Suites to IANA Considerations 1061 3. Add some material to Security Considerations, 1063 4. Assorted Editorial changes. 1065 From -05 to -06 1067 Fix editorials found during WG Last Call. 1069 From -06 to -07 1071 Minor editorial changes resulting for Shepherd review. 1073 From -07 to -08 1075 Move group keyed security out of the draft. Simplify and improve 1076 remaining security provisions. 1078 From -08 to -09 1080 1. Updates based on Routing Directorate review. 1082 2. Improvements to specification of pairwise DTLS and significant 1083 other security improvements. 1085 From -09 to -10 1087 Update based on GENART review. 1089 From -10 to -11 1091 1. Add IANA registry for suberror codes and make other minor IANA 1092 Considerations changes. 1094 2. Add informational references to [RFC7067], address flush, and 1095 rfc6439bis. 1097 3. Add RFC 2119 keyword emphasis to Security Considerations caution 1098 in handling decapsulated extended RBridge Channel payloads. 1100 Acknowledgements 1102 The contributions of the following are hereby gratefully 1103 acknowledged: 1105 Stephen Farrell, Jonathan Hardwick, Susan Hares, Gayle Noble, 1106 Alvaro Retana, Yaron Sheffer, and Peter Yee. 1108 The document was prepared in raw nroff. All macros used were defined 1109 within the source file. 1111 Authors' Addresses 1113 Donald E. Eastlake, 3rd 1114 Huawei Technologies 1115 155 Beaver Street 1116 Milford, MA 01757 USA 1118 Phone: +1-508-333-2270 1119 EMail: d3e3e3@gmail.com 1121 Mohammed Umair 1122 IPinfusion 1124 EMail: mohammed.umair2@gmail.com 1126 Yizhou Li 1127 Huawei Technologies 1128 101 Software Avenue, 1129 Nanjing 210012, China 1131 Phone: +86-25-56622310 1132 EMail: liyizhou@huawei.com 1134 Copyright, Disclaimer, and Additional IPR Provisions 1136 Copyright (c) 2016 IETF Trust and the persons identified as the 1137 document authors. All rights reserved. 1139 This document is subject to BCP 78 and the IETF Trust's Legal 1140 Provisions Relating to IETF Documents 1141 (http://trustee.ietf.org/license-info) in effect on the date of 1142 publication of this document. Please review these documents 1143 carefully, as they describe your rights and restrictions with respect 1144 to this document. Code Components extracted from this document must 1145 include Simplified BSD License text as described in Section 4.e of 1146 the Trust Legal Provisions and are provided without warranty as 1147 described in the Simplified BSD License. The definitive version of 1148 an IETF Document is that published by, or under the auspices of, the 1149 IETF. Versions of IETF Documents that are published by third parties, 1150 including those that are translated into other languages, should not 1151 be considered to be definitive versions of IETF Documents. The 1152 definitive version of these Legal Provisions is that published by, or 1153 under the auspices of, the IETF. Versions of these Legal Provisions 1154 that are published by third parties, including those that are 1155 translated into other languages, should not be considered to be 1156 definitive versions of these Legal Provisions. For the avoidance of 1157 doubt, each Contributor to the IETF Standards Process licenses each 1158 Contribution that he or she makes as part of the IETF Standards 1159 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1160 language to the contrary, or terms, conditions or rights that differ 1161 from or are inconsistent with the rights and licenses granted under 1162 RFC 5378, shall have any effect and shall be null and void, whether 1163 published or posted by such Contributor, or included with or in such 1164 Contribution.