idnits 2.17.1 draft-ietf-trill-channel-tunnel-03.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 (February 19, 2015) is 3353 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' ** 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: 3 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 Yizhou Li 3 Intended status: Proposed Standard Huawei 4 Expires: August 18, 2015 February 19, 2015 6 TRILL: RBridge Channel Tunnel Protocol 7 9 Abstract 11 The IETF TRILL (Transparent Interconnection of Lots of Links) 12 protocol includes an optional mechanism, called RBridge Channel and 13 specified in RFC 7178, for the transmission of typed messages between 14 TRILL switches in the same campus and between TRILL switches and end 15 stations on the same link. This document specifies two optional 16 extensions to the RBridge Channel protocol: (1) A standard method to 17 tunnel a variety of payload types by encapsulating them in an RBridge 18 Channel message; and (2) A method to support security facilities for 19 RBridge Channel messages. This document updates RFC 7178. 21 Status of This Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the authors or the TRILL working group mailing list: 28 trill@ietf.org 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................3 48 1.1 Terminology and Acronyms..............................3 50 2. Channel Tunnel Packet Format............................5 52 3. Tunnel Payload Types....................................8 53 3.1 Null Payload...........................................8 54 3.2 RBridge Channel Message Payload........................8 55 3.3 TRILL Data Packet......................................9 56 3.4 TRILL IS-IS Packet....................................10 57 3.5 Ethernet Frame........................................11 59 4. Security, Keying, and Algorithms.......................13 60 4.1 Basic Security Format.................................13 61 4.2 Authentication and Encryption Coverage................14 62 4.3 Derived Keying Material...............................14 63 4.4 SType None............................................15 64 4.5 RFC 5310 Based Authentication.........................15 65 4.6 DTLS Based Security...................................15 67 5. Channel Tunnel Errors..................................17 68 5.1 SubERRs under ERR 6...................................17 69 5.2 Nested RBridge Channel Errors.........................17 71 6. IANA Considerations....................................18 72 7. Security Considerations................................19 74 Normative References......................................20 75 Informative References....................................21 77 Appendix Z: Change History................................22 78 Acknowledgements..........................................23 80 Authors' Addresses........................................24 82 1. Introduction 84 The IETF TRILL base protocol [RFC6325] has been extended with an 85 optional RBridge Channel [RFC7178] facility to support transmission 86 of typed messages (for example BFD [RFC7175]) between two TRILL 87 switches (RBridges) in the same campus and between RBridges and end 88 stations on the same link. When sent between RBridges in the same 89 campus, a TRILL Data packet with a TRILL header is used and the 90 destination RBridge is indicated by nickname. When sent between a 91 RBridge and an end station on the same link in either direction a 92 native RBridge Channel messages [RFC7178] is used with no TRILL 93 header and the destination port or ports is indicated by a MAC 94 address. (There is no mechanism to stop end stations on the same 95 link, from sending native RBridge Channel messages to each other; 96 however, such use is outside the scope of this document.) 98 This document updates [RFC7178] and specifies extensions to RBridge 99 Channel that provides two additional optional facilities as listed 100 below. Implementation and use of each of these facilities is 101 optional, except that there are two payload types that MUST be 102 implemented. Both of these facilities can be used in the same packet. 104 (1) A standard method to tunnel a variety of payload types by 105 encapsulating them in an RBridge Channel message. 107 (2) A method to provide security facilities for RBridge Channel 108 messages. 110 1.1 Terminology and Acronyms 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 This document uses terminology and acronyms defined in [RFC6325] and 117 [RFC7178]. Some of these are repeated below for convenience along 118 with additional terms and acronyms. 120 Data Label - VLAN or FGL. 122 FGL - Fine Grained Label [RFC7172]. 124 RBridge - An alternative term for a TRILL switch. 126 TRILL - Transparent Interconnection of Lots of Links or Tunneled 127 Routing in the Link Layer. 129 TRILL switch - A device that implements the TRILL protocol 131 [RFC6325], sometimes referred to as an RBridge. 133 2. Channel Tunnel Packet Format 135 The general structure of an RBridge Channel message between two TRILL 136 switches (RBridges) in the same campus is shown in Figure 1 below. 137 The structure of a native RBridge Channel message sent between an 138 RBridge and an end station on the same link, in either direction, is 139 shown in Figure 2 and, compared with the first case, omits the TRILL 140 Header, inner Ethernet addresses, and Data Label. A Protocol field in 141 the RBridge Channel Header gives the type of RBridge Channel message 142 and indicates how to interpret the Channel Protocol Specific Payload 143 [RFC7178]. 145 +-----------------------------------+ 146 | Link Header | 147 +-----------------------------------+ 148 | TRILL Header | 149 +-----------------------------------+ 150 | Inner Ethernet Addresses | 151 +-----------------------------------+ 152 | Data Label (VLAN or FGL) | 153 +-----------------------------------+ 154 | RBridge Channel Header | 155 +-----------------------------------+ 156 | Channel Protocol Specific Payload | 157 +-----------------------------------+ 158 | Link Trailer (FCS if Ethernet) | 159 +-----------------------------------+ 161 Figure 1. RBridge Channel Packet Structure 163 +-----------------------------------+ 164 | Ethernet Link Header | 165 +-----------------------------------+ 166 | RBridge Channel Header | 167 +-----------------------------------+ 168 | Channel Protocol Specific Payload | 169 +-----------------------------------+ 170 | FCS | 171 +-----------------------------------+ 173 Figure 2. Native RBridge Channel Frame 175 The RBridge Channel Header looks like this: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | 0x8946 | CHV | Channel Protocol | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Flags | ERR | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 184 / Channel Protocol Specific Data / 185 /-+-+-+-+-+- / 187 Figure 3. RBridge Channel Header 189 where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel 190 Header Version, currently zero. 192 The extensions specified herein are in the form of an RBridge Channel 193 protocol, the Channel Tunnel Protocol. Figure 4 below expands the 194 RBridge Channel Header and Protocol Specific Payload above for the 195 case of the Channel Tunnel Protocol. 197 0 1 2 3 198 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 199 RBridge Channel Header: 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | 0x8946 | 0x0 | Tunnel Protocol =tbd1 | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Flags | ERR | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Channel Tunnel Protocol Specific: | SubERR| RESV4 | SType | PType | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Security Information, variable length (0 length if SType = 0) 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 210 | Tunneled Data, variable length 211 | ... 213 Figure 4. Channel Tunnel Header Structure 215 The RBridge Channel Header field specific to the RBridge Channel 216 Tunnel Protocol is the Protocol field. Its contents MUST be the value 217 allocated for this purpose (see Section 6). 219 The RBridge Tunnel Channel Protocol Specific Data fields are as 220 follows: 222 SubERR: This field provides further details when a Tunnel Channel 223 error is indicated in the RBridge Channel ERR field. If ERR is 224 zero, then SubERR MUST be sent as zero and ignored on receipt. 225 See Section 5. 227 RESV4: This field MUST be sent as zero. If non-zero when received, 228 this is an error condition (see Section 4). 230 SType: This field describes the type of security information and 231 features, including keying material, being provided. See 232 Section 4. 234 PType: Payload type. The describes the tunneled data. See Section 235 3 below. 237 Security Information: Variable length information. Length is zero 238 if SType is zero. See Section 4. 240 The Channel Tunnel protocol is integrated with the RBridge Channel 241 facility. Channel Tunnel errors are reported as if they were RBridge 242 Channel errors, using newly allocated code points in the ERR field of 243 the RBridge Channel Header supplemented by the SubERR field. 245 3. Tunnel Payload Types 247 The RBridge Channel Tunnel Protocol can carry a variety of payloads 248 as indicated by the PType field. Values are shown in the table below 249 with further explanation after the table. 251 PType Section Description 252 ----- ------- ----------- 253 0 Reserved 254 1 3.1 Null 255 2 3.2 RBridge Channel message 256 3 3.3 TRILL Data packet 257 4 3.4 TRILL IS-IS packet 258 5 3.5 Ethernet Frame 259 6-14 (Available for assignment by IETF Review) 260 15 Reserved 262 Table 1. Payload Type Values 264 While implementation of the Channel Tunnel protocol is optional, if 265 it is implemented PTypes 1 (Null) and 2 (RBridge Channel message) 266 MUST be implemented. PTypes 3, 4, and 5 MAY be implemented. The 267 processing of any particular Channel Protocol message and its payload 268 depends on meeting local security and other policy at the destination 269 TRILL switch or end station. 271 3.1 Null Payload 273 The Null payload type (PType=1) is intended to be used for testing or 274 messages such as key negotiation or the like. It indicates that there 275 is no payload. Any data after the Security Information fields is 276 ignored. 278 3.2 RBridge Channel Message Payload 280 A PType of 2 indicates that the payload of the Channel Tunnel message 281 is an encapsulated RBridge Channel message without the initial 282 RBridge Channel Ethertype. Typical reasons for sending an RBridge 283 Channel message inside a Channel Tunnel message are to provide 284 security services, such as authentication or encryption. 286 This payload type looks like the following: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol = tbd1| 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Possible Security information 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | 0x0 | Channel Protocol | Flags | ERR | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Channel Protocol Specific Data ... | 300 | 302 Figure 5. Tunneled Channel Message Channel Tunnel Structure 304 3.3 TRILL Data Packet 306 A PType of 3 indicates that the payload of the Tunnel protocol 307 message is an encapsulated TRILL Data packet as shown in the figure 308 below. (There is no TRILL Ethertype before the inner TRILL Data 309 packet because that is just part of the Ethernet link header for a 310 TRILL Data packet, not part of the TRILL header itself.) If this 311 PType is implemented and the message meets local policy for 312 acceptance, the tunneled TRILL Data packet is handled as if it had 313 been received by the destination TRILL switch on the port where the 314 Channel Tunnel message was received. 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol = tbd1| 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Flags | ERR | SubERR| RESV4 | SType | 0x3 | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Possible Security information 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | V |A|C|M| RESV |F| Hop Count | Egress Nickname | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Ingress Nickname | Inner.MacDA | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Inner.MacDA continued | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Inner.MacSA | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Inner.MacSA (cont.) | Inner Data Label ... 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 335 | TRILL Data Packet payload 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 338 Figure 6. Nested TRILL Data Packet Channel Tunnel Structure 340 3.4 TRILL IS-IS Packet 342 A PType of 4 indicates that the payload of the Tunnel protocol 343 message is an encapsulated TRILL IS-IS PDU packet without the initial 344 L2-IS-IS Ethertype as shown in the figure below. If this PType is 345 implemented, the tunneled TRILL IS-IS packet is processed by the 346 destination RBridge if it meets local policy. One possible use is to 347 expedite the receipt of a link state PDU by some TRILL switch or 348 switches with an immediate requirement for the enclosed link state 349 PDU. Any link local IS-IS PDU (Hello, CSNP, or PSNP [IS-IS]; MTU- 350 probe, MTU-ack [RFC7176]; or circuit scoped FS-LSP, FS-CSNP or FS- 351 PSNP [RFC7356]) received via this channel tunnel payload type MUST be 352 discarded. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol = tbd1| 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Flags | ERR | SubERR| RESV4 | SType | 0x4 | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Possible Scope Information 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 363 | Possible Security information 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 365 | 0x83 | rest of IS-IS PDU 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 368 Figure 7. Tunneled TRILL IS-IS Packet Structure 370 3.5 Ethernet Frame 372 If PType is 5, the Tunnel Protocol payload is an Ethernet frame as 373 might be received from or sent to an end station except that the 374 tunneled Ethernet frame's FCS is omitted, as shown in Figure 8. 375 (There is still an overall FCS if the RBridge Channel message is 376 being sent on an Ethernet link.) If this PType is implemented and the 377 message meets local policy, the tunneled frame is handled as if it 378 had been received on the port on which the Tunnel Protocol message 379 was received. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol = tbd1| 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Flags | ERR | SubERR| RESV4 | SType | 0x5 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Possible Security information 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | MacDA | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | MacDA (cont.) | MacSA | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | MacSA (cont.) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Any Ethernet frame tagging... 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 398 | Ethernet frame payload... 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 401 Figure 8. Ethernet Frame Channel Tunnel Structure 403 In the case of a non-Ethernet link, such as a PPP link [RFC6361], the 404 ports on the link are considered to have link local synthetic 48-bit 405 MAC addresses constructed by concatenating three 16-bit quantities. 406 This constructed address MAY be used as the MacSA and, if the RBridge 407 Channel message is link local, the source TRILL switch will have the 408 information to construct such a MAC address for the destination TRILL 409 switch port and that MAC address MAY be used as the MacDA. 411 These MAC addresses are constructed as follows: 0xFEFF, the nickname 412 of the TRILL switch used in TRILL Hellos sent on that port, and the 413 Port ID that the TRILL switch has assigned to that port, as shown in 414 Figure 9. Both the nickname and Port ID appear in the Special VLANs 415 and Flags sub-TLV [RFC7176]. The resulting MAC address has the Local 416 bit on and the Group bit off [RFC7042]. Since end stations are 417 connected to TRILL switches over Ethernet, there will be no end 418 stations on a non-Ethernet link in a TRILL campus. Thus such 419 synthetic MAC addresses cannot conflict on the link with a real 420 Ethernet port address. 422 0 1 2 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 | 0xFEFF | Nickname | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Port ID | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 9. Synthetic MAC Address 432 4. Security, Keying, and Algorithms 434 The following table gives the assigned values of the SType field and 435 their meaning. 437 SType Section Meaning 438 ----- ------- ------- 439 0 4.4 None 440 1 4.5 [RFC5310] Based Authentication 441 2 4.6 DTLS Based Security 442 3-14 Available for assignment on IETF Review 443 15 Reserved 445 Table 3. SType Values 447 4.1 Basic Security Format 449 For all SType values except zero, the Security Information starts 450 with a byte of flag bits and a byte of remaining length as follows: 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 453 |A|E| RESV | Size | More Info 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 456 Figure 12. Security Information Format 458 The fields are as follows: 460 A: Zero if authentication is not being provided. One if it is. 462 E: Zero if encryption is not being provided. One if it is. 464 RESV: Six reserved bits that MUST be sent as zero and ignored on 465 receipt. In the future, meanings may be assigned to these bits and 466 those meanings may differ for different STypes. 468 Size: The number of bytes, as an unsigned integer, of More Info in 469 the Security Information after the Size byte itself. 471 More Info: Additional Security Information of length Size. Contents 472 depends on the SType. 474 The A and E bits are intended as hints and to assist is debugging. 475 They are not guaranteed to be correct. They can be interpreted as 476 follows: 478 A E Comments 479 ----- ---------- 481 0 0 Neither authentication nor encryption is being provided. 483 1 0 Authentication only. The payload may be parsable by a 484 security ignorant receiver. The Size field permits 485 skipping the More Info field. 487 0 1 Encryption only. Some form of opportunistic security 488 [RFC7435]. 490 1 1 Authentication and Encryption. 492 4.2 Authentication and Encryption Coverage 494 Authentication is computed across relevant Channel Tunnel header 495 information and payload. To be more precise, the covered area starts 496 with the byte containing the CHV (RBridge Channel Header Version) and 497 extends to just before the TRILL Data packet link trailer. If an 498 authentication value is included in the Info field specified in 499 Section 4.1, it is treated as zero when authentication is calculated. 500 If an authentication value is included in a payload after the 501 security information, it is calculated as provided by the SType and 502 algorithms in use. 504 If encryption is provided, it covers the payload from right after the 505 Channel Tunnel header security information through to just before the 506 TRILL Data packet link trailer. 508 4.3 Derived Keying Material 510 In some cases, it is possible to use keying material derived from 511 [RFC5310] IS-IS keying material. In such cases, the More Info field 512 shown in Section 4.1 includes a two byte Key ID to identify the IS-IS 513 keying material. The keying material actually used in Channel Tunnel 514 security is derived from the IS-IS keying material as follows: 516 HKDF-Expand-SHA256 ( IS-IS-key, "Channel Tunnel" | 0x0P, L ) 518 where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is 519 as in [RFC6234],IS-IS-key is the input keying material, "Channel 520 Tunnel" is the 14-character [RFC20] string indicated, 0x0P is a 521 single byte where P is the PType for which this key derivation is 522 being used, and L is the length of output keying material needed. 524 4.4 SType None 526 No security services are being invoked. The length of the Security 527 Information field (see Figure 6) is zero. 529 4.5 RFC 5310 Based Authentication 531 The Security Information (see Figure 6) is the flags and Size bytes 532 specified in Section 4.1 with the value of the [RFC5310] Key ID and 533 Authentication Data as shown in Figure 13. 535 1 1 1 1 1 1 536 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 |1|0| RESV | Size | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Key ID | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | | 543 + 544 | Authentication Data (Variable) 545 + 546 | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-... 549 Figure 13. SType 1 Security Information 551 o RESV: Six bits that MUST be sent as zero and ignored or receipt. 553 o Size: Set to 2 + the size of Authentication Data in bytes. 555 o Key ID: specifies the same keying value and authentication 556 algorithm that that Key ID specifies for TRILL IS-IS LSP [RFC5310] 557 Authentication TLVs. The keying material actually used is derived 558 as shown in Section 4.3. 560 o Authentication Data: The authentication data produced by the key 561 and algorithm associated with the Key ID acting on the packet as 562 specified in Section 4.2. Length of authentication data depends on 563 the algorithm. 565 4.6 DTLS Based Security 567 DTLS supports key negotiation and provides both encryption and 568 authentication. This optional SType in Channel Tunnel uses DTLS 1.2 569 [RFC6347]. 571 TRILL switches that implement the Channel Tunnel DTLS SType SHOULD 572 support the use of certificates for DTLS. In this case the Size field 573 shown in Section 4.1 MUST be zero and the Security Information is as 574 shown in Figure 14. 576 Also, if they support certificates, they MUST support the following 577 algorithm: 579 o TLS_RSA_WITH_AES_128_CBC_SHA256 [RFC5246] 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 |1|1| RESV | 0 | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 Figure 14. DTLS Cert or Special Pre-shared Key Security Information 587 TRILL switches that support the Channel Tunnel DTLS SType MUST 588 support the use of pre-shared keys for DTLS. The Size field as shown 589 in Section 4.1 MUST be either zero or 2. If Size is zero as shown in 590 Figure 14, a pre-shared key specifically associated with Channel 591 Tunnel DTLS is used. If Size is 2 as shown in Figure 15, a two byte 592 [RFC5310] Key ID is present and the pre-shared key is derived from 593 the secret key associated with that Key ID as shown in Section 4.3. 595 The following cryptographic algorithms MUST be supported for use with 596 pre-shared keys: 598 o TLS_PSK_WITH_AES_128_CBC_SHA256 [RFC5487] 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |1|1| RESV | 2 | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Key ID | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Figure 15. DTLS Derived Pre-shared Key Security Information 608 When DTLS security is used, the entire payload of the Channel Tunnel 609 packet, starting just after the Security Information and ending just 610 before the link trailer, is a DTLS record [RFC6347]. 612 5. Channel Tunnel Errors 614 RBridge Channel Tunnel Protocol errors are reported like RBridge 615 Channel level errors. The ERR field is set to one of the following 616 error codes: 618 ERR Meaning 619 --- --------- 620 6 Unknown or unsupported field value 621 7 Authentication failure 622 8 Error in nested RBridge Channel message 623 (more TBD?) 625 Table 4. Additional ERR Values 627 5.1 SubERRs under ERR 6 629 If the ERR field is 6, the SubERR field indicates the problematic 630 field or value as show in the table below. 632 SubERR Meaning (for ERR = 6) 633 ------ --------------------- 634 0 Non-zero RESV4 nibble 635 1 Unsupported SType 636 2 Unsupported PType 637 3 Unknown or reserved Scope Egress Nickname in an 638 ESRB scope Tunnel Channel message 639 4 Unsupported crypto algorithm 640 5 Unknown Key ID for SType 1 641 (more TBD) 643 Table 5. SubERR values under ERR 6 645 5.2 Nested RBridge Channel Errors 647 If 648 a Channel Tunnel message is sent with security and with a payload 649 type (PType) indicating a nested RBridge Channel message 650 and 651 there is an error in the processing of that nested message that 652 results in a return RBridge Channel message with a non-zero ERR 653 field, 654 then that returned message SHOULD also be nested in an Channel Tunnel 655 message using the same type of security. In this case, the ERR field 656 in the Channel Tunnel envelope is set to 8 indicating that there is a 657 nested error. 659 6. IANA Considerations 661 IANA has assigned tbd1 as the RBridge Channel protocol number the 662 "Channel Tunnel" protocol from the range assigned by Standards 663 Action. 665 The added RBridge Channel protocols registry entry on the TRILL 666 Parameters web page is as follows: 668 Protocol Description Reference 669 -------- -------------- --------- 671 tbd1 Tunnel Channel [this document] 673 7. Security Considerations 675 The RBridge Channel tunnel facility has potentially positive and 676 negative effects on security. 678 On the positive side, it provides optional security that can be used 679 to authenticate and/or encrypt RBridge Channel messages. Some RBridge 680 Channel message payloads provide their own security [RFC7175] but 681 where this is not true, consideration should be give to requiring use 682 of the security features of the Tunnel Protocol. 684 On the negative side, the optional ability to tunnel various payload 685 types and to tunnel them not just between TRILL switches but to and 686 from end stations can increase risk unless precautions are taking. 687 The processing of decapsulated Tunnel Protocol payloads is not a good 688 place to be liberal in what you accept as the tunneling facility 689 makes it easier for unexpected messages to pop up in unexpected 690 places in a TRILL campus due to accidents or the actions of an 691 adversary. Local policies should generally be strict and only process 692 payload types required and then only with adequate authentication for 693 the particular circumstances. 695 In connection with the use of DTLS for security as specified in 696 Section 4.5, see [RFC7457]. 698 See [RFC7178] for general RBridge Channel Security Considerations. 700 See [RFC6325] for general TRILL Security Considerations. 702 Normative References 704 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology 705 -- Telecommunications and information exchange between systems 706 -- Intermediate System to Intermediate System intra-domain 707 routeing information exchange protocol for use in conjunction 708 with the protocol for providing the connectionless-mode network 709 service (ISO 8473)", 2002. 711 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, 712 RFC 20, October 1969, . 714 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security 718 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 719 . 721 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 722 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 723 5310, February 2009. 725 [RFC5487] - Badra, M., "Pre-Shared Key Cipher Suites for TLS with 726 SHA-256/384 and AES Galois Counter Mode", RFC 5487, March 2009, 727 . 729 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 730 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 731 . 733 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 734 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 735 July 2011. 737 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 738 Security Version 1.2", RFC 6347, January 2012, . 741 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 742 and D. Dutt, "Transparent Interconnection of Lots of Links 743 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 745 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 746 D., and A. Banerjee, "Transparent Interconnection of Lots of 747 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 748 . 750 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 751 Ward, "Transparent Interconnection of Lots of Links (TRILL): 753 RBridge Channel Support", RFC 7178, May 2014. 755 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 756 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 757 . 759 [rfc7180bis] - Eastlake, D., Zhang, M., Perlman, R. Banerjee, A., 760 Ghanwani, A., and S. Gupta, "RILL: Clarifications, Corrections, 761 and Updates", Draft-ietf-trill-rfc7180bis, work in progress. 763 Informative References 765 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 766 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 767 2011. 769 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 770 Interconnection of Lots of Links (TRILL) Protocol Control 771 Protocol", RFC 6361, August 2011 773 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 774 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 775 BCP 141, RFC 7042, October 2013. 777 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 778 "Transparent Interconnection of Lots of Links (TRILL): 779 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 780 May 2014. 782 [RFC7435] - Dukhovni, V., "Opportunistic Security: Some Protection 783 Most of the Time", RFC 7435, December 2014, . 786 [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 787 Known Attacks on Transport Layer Security (TLS) and Datagram 788 TLS (DTLS)", RFC 7457, February 2015, . 791 Appendix Z: Change History 793 From -00 to -01 795 1. Fix references for RFCs published, etc. 797 2. Explicitly mention in the Abstract and Introduction that this 798 document updates [RFC7178]. 800 3. Add this Change History Appendix. 802 From -01 to -02 804 1. Remove section on the "Scope" feature as mentioned in 805 http://www.ietf.org/mail-archive/web/trill/current/msg06531.html 807 2. Editorial changes to IANA Considerations to correspond to draft- 808 leiba-cotton-iana-5226bis-11.txt. 810 3. Improvements to the Ethernet frame payload type. 812 4. Other Editorial changes. 814 From -02 to -03 816 1. Update TRILL Header to correspond to [rfc7180bis]. 818 2. Remove a few remnants of the "Scope" feature that was removed from 819 -01 to -02. 821 3. Substantial changes to and expansion of Section 4 including adding 822 details of DTLS security. 824 4. Updates and additions to the References. 826 5. Other minor editorial changes. 828 Acknowledgements 830 The contributions of the following are hereby acknowledged: 832 TBD 834 The document was prepared in raw nroff. All macros used were defined 835 within the source file. 837 Authors' Addresses 839 Donald E. Eastlake, 3rd 840 Huawei Technologies 841 155 Beaver Street 842 Milford, MA 01757 USA 844 Phone: +1-508-333-2270 845 Email: d3e3e3@gmail.com 847 Yizhou Li 848 Huawei Technologies 849 101 Software Avenue, 850 Nanjing 210012, China 852 Phone: +86-25-56622310 853 Email: liyizhou@huawei.com 855 Copyright, Disclaimer, and Additional IPR Provisions 857 Copyright (c) 2015 IETF Trust and the persons identified as the 858 document authors. All rights reserved. 860 This document is subject to BCP 78 and the IETF Trust's Legal 861 Provisions Relating to IETF Documents 862 (http://trustee.ietf.org/license-info) in effect on the date of 863 publication of this document. Please review these documents 864 carefully, as they describe your rights and restrictions with respect 865 to this document. Code Components extracted from this document must 866 include Simplified BSD License text as described in Section 4.e of 867 the Trust Legal Provisions and are provided without warranty as 868 described in the Simplified BSD License. The definitive version of 869 an IETF Document is that published by, or under the auspices of, the 870 IETF. Versions of IETF Documents that are published by third parties, 871 including those that are translated into other languages, should not 872 be considered to be definitive versions of IETF Documents. The 873 definitive version of these Legal Provisions is that published by, or 874 under the auspices of, the IETF. Versions of these Legal Provisions 875 that are published by third parties, including those that are 876 translated into other languages, should not be considered to be 877 definitive versions of these Legal Provisions. For the avoidance of 878 doubt, each Contributor to the IETF Standards Process licenses each 879 Contribution that he or she makes as part of the IETF Standards 880 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 881 language to the contrary, or terms, conditions or rights that differ 882 from or are inconsistent with the rights and licenses granted under 883 RFC 5378, shall have any effect and shall be null and void, whether 884 published or posted by such Contributor, or included with or in such 885 Contribution.