idnits 2.17.1 draft-ietf-trill-channel-tunnel-02.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 (December 8, 2014) is 3425 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. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 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: June 7, 2015 December 8, 2014 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 protcol: (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............................4 52 3. Tunnel Payload Types....................................7 53 3.1 Null Payload...........................................7 54 3.2 RBridge Channel Message Payload........................7 55 3.3 TRILL Data Packet......................................8 56 3.4 TRILL IS-IS Packet.....................................9 57 3.5 Ethernet Frame........................................10 59 4. Security, Keying, and Algorithms.......................12 60 4.1 Authentication Coverage...............................12 61 4.2 SType None............................................13 62 4.3 RFC 5310 Based Authentication.........................13 63 4.4 xxx Based Security....................................13 65 5. Channel Tunnel Errors..................................14 66 5.1 SubERRs under ERR 6...................................14 67 5.2 Nested RBridge Channel Errors.........................14 69 6. IANA Considerations....................................15 70 7. Security Considerations................................16 72 Normative References......................................17 73 Informative References....................................18 75 Appenxid Z: Change History................................19 77 Acknowledgements..........................................20 78 Authors' Addresses........................................21 80 1. Introduction 82 The IETF TRILL base protocol [RFC6325] has been extended with an 83 optional RBridge Channel [RFC7178] facility to support transmission 84 of typed messages (for example BFD [RFC7175]) between two TRILL 85 switches (RBridges) in the same campus and between RBridges and end 86 stations on the same link. When sent between RBridges in the same 87 campus, a TRILL Data packet with a TRILL header is used and the 88 destination RBridge is indicated by nickname. When sent between a 89 RBridge and an end station on the same link in either direction a 90 native RBridge Channel messages [RFC7178] is used with no TRILL 91 header and the destination port or ports is indicated by a MAC 92 address. (There is no mechanism to stop end stations on the same 93 link, from sending native RBridge Channel messages to each other; 94 however, such use is outside the scope of this document.) 96 This document updates [RFC7178] and specifies extensions to RBridge 97 Channel that provides two additional facilities as listed below. 98 Implementation and use of each of these facilities is optional, 99 except that there are two payload types that MUST be implemented. 100 Both of these facilities can be used in the same packet. 102 (1) A standard method to tunnel a variety of payload types by 103 encapsulating them in an RBridge Channel message. 105 (2) A method to provide security facilities for RBridge Channel 106 messages. 108 1.1 Terminology and Acronyms 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 This document uses the acronyms defined in [RFC6325] and [RFC7178] 115 supplemented by the following additional acronym: 117 Data Label - VLAN or FGL. 119 FGL - Fine Grained Label [RFC7172]. 121 RBridge - An alternative term for a TRILL switch. 123 TRILL switch - A device that implements the TRILL protocol 124 [RFC6325], sometimes referred to as an RBridge. 126 2. Channel Tunnel Packet Format 128 The general structure of an RBridge Channel message on a link between 129 TRILL switches (RBridges) is shown in Figure 1 below. When a native 130 RBridge Channel message is sent between an RBridge and an end station 131 on the same link, in either direction, the TRILL Header, inner 132 Ethernet addresses, and Data Label are omitted as shown in Figure 2. 133 The type of RBridge Channel message is given by a Protocol field in 134 the RBridge Channel Header that indicates how to interpret the 135 Channel Protocol Specific Payload [RFC7178]. 137 +-----------------------------------+ 138 | Link Header | 139 +-----------------------------------+ 140 | TRILL Header | 141 +-----------------------------------+ 142 | Inner Ethernet Addresses | 143 +-----------------------------------+ 144 | Data Label (VLAN or FGL) | 145 +-----------------------------------+ 146 | RBridge Channel Header | 147 +-----------------------------------+ 148 | Channel Protocol Specific Payload | 149 +-----------------------------------+ 150 | Link Trailer (FCS if Ethernet) | 151 +-----------------------------------+ 153 Figure 1. RBridge Channel Packet Structure 155 +-----------------------------------+ 156 | Ethernet Link Header | 157 +-----------------------------------+ 158 | RBridge Channel Header | 159 +-----------------------------------+ 160 | Channel Protocol Specific Payload | 161 +-----------------------------------+ 162 | FCS | 163 +-----------------------------------+ 165 Figure 2. Native RBridge Channel Frame 167 The RBridge Channel Header looks like this: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | 0x8946 | CHV | Channel Protocol | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Flags | ERR | | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Channel Protocol Specific Data+ 176 / / 177 / 179 Figure 3. RBridge Channel Header 181 where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel 182 Header Version, currently zero. 184 The extensions specified herein are in the form of an RBridge Channel 185 protocol, the Channel Tunnel Protocol. Figure 4 below expands the 186 RBridge Channel Header and Protocol Specific Payload above for the 187 case of the Channel Tunnel Protocol. 189 0 1 2 3 190 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 191 RBridge Channel Header: 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | 0x8946 | 0x0 | Tunnel Protocol =tbd1 | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Flags | ERR | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Channel Tunnel Protocol Specific: | SubERR| RESV4 | SType | PType | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Security information, variable length (0 length if SType = 0) 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 202 | Tunneled Data, variable length 203 | ... 205 Figure 4. Channel Tunnel Header Structure 207 The RBridge Channel Header field specific to the RBridge Channel 208 Tunnel Protocol is the Protocol field. Its contents MUST be the value 209 allocated for this purpose (see Section 6). 211 The RBridge Tunnel Channel Protocol Specific fields are as follows: 213 SubERR: This field provides further details when a Tunnel Channel 214 error is indicated in the RBridge Channel ERR field. If ERR is 215 zero, then SubERR MUST be sent as zero and ignored on receipt. 216 See Section 5. 218 RESV4: This field MUST be sent as zero. If non-zero when received, 219 this is an error condition (see Section 4). 221 SType: This field describes the type of security information and 222 features, including keying material, being provided. See 223 Section 4. 225 PType: Payload type. The describes the tunneled data. See Section 226 3 below. 228 The Channel Tunnel protocol is integrated with the RBridge Channel 229 facility. Channel Tunnel errors are reported as if they were RBridge 230 Channel errors, using newly allocated code points in the ERR field of 231 the RBridge Channel Header supplemented by the SubERR field. 232 Additional RBridge Channel Header flags are specified and used by 233 Channel Tunnel (see Section 6). 235 3. Tunnel Payload Types 237 The RBridge Channel Tunnel Protocol can carry a variety of payloads 238 as indicated by the PType field. Values are shown in the table below 239 with further explanation after the table. 241 PType Section Description 242 ----- ------- ----------- 243 0 Reserved 244 1 3.1 Null 245 2 3.2 RBridge Channel message 246 3 3.3 TRILL Data packet 247 4 3.4 TRILL IS-IS packet 248 5 3.5 Ethernet Frame 249 6-14 (Available for assignment by IETF Review) 250 15 Reserved 252 Table 1. Payload Type Values 254 While implementation of the Channel Tunnel protocol is optional, if 255 it is implemented PTypes 1 (Null) and 2 (RBridge Channel message) 256 MUST be implemented. PTypes 3, 4, and 5 MAY be implemented. The 257 processing of any particular Channel Protocol message and its payload 258 depends on meeting local security and other policy at the destination 259 TRILL switch or end station. 261 3.1 Null Payload 263 The Null payload type is intended to be used for testing or messages 264 such as key negotiation or the like. It indicates that there is no 265 payload. Any data after the Security Information fields is ignored. 267 3.2 RBridge Channel Message Payload 269 A PType of 2 indicates that the payload of the Channel Tunnel message 270 is an encapsulated RBridge Channel message without the initial 271 RBridge Channel Ethertype. Typical reasons for sending an RBridge 272 Channel message inside a Channel Tunnel message are to provide 273 security services, such as authentication or encryption, or to 274 forward it through a cooperating border TRILL switch in either 275 direction between an end station and a TRILL switch not on the same 276 link. 278 This payload type looks like the following: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol =tbd1 | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Possible Security information 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | 0x0 | Channel Protocol | Flags | ERR | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Channel Protocol Specific Data ... | 292 | 294 Figure 5. Tunneled Channel Message Channel Tunnel Structure 296 3.3 TRILL Data Packet 298 A PType of 3 indicates that the payload of the Tunnel protocol 299 message is an encapsulated TRILL Data packet as shown in the figure 300 below. (There is no TRILL Ethertype before the inner TRILL Data 301 packet because that is just part of the Ethernet link header for a 302 TRILL Data packet, not part of the TRILL header itself.) If this 303 PType is implemented and the message meets local policy for 304 acceptance, the tunneled TRILL Data packet is handled as if it had 305 been received by the destination TRILL switch on the port where the 306 Channel Tunnel message was received. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol =tbd1 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Flags | ERR | SubERR| RESV4 | SType | 0x3 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Possible Security information 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | V | R |M|Op-Length| Hop Count | Egress Nickname | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Ingress Nickname | Inner.MacDA | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Inner.MacDA continued | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Inner.MacSA | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Inner.MacSA (cont.) | Inner Data Label ... 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 327 | TRILL Data Packet payload 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 330 Figure 6. Nested TRILL Data Packet Channel Tunnel Structure 332 3.4 TRILL IS-IS Packet 334 A PType of 4 indicates that the payload of the Tunnel protocol 335 message is an encapsulated TRILL IS-IS PDU packet without the initial 336 L2-IS-IS Ethertype as shown in the figure below. If this PType is 337 implemented, the tunneled TRILL IS-IS packet is processed by the 338 destination RBridge if it meets local policy. One possible use is to 339 expedite the receipt of a link state PDU by some TRILL switch or 340 switches with an immediate requirement for the enclosed link state 341 PDU. Any link local IS-IS PDU (Hello, CSNP, or PSNP [IS-IS]; MTU- 342 probe, MTU-ack [RFC7176]; or circuit scoped FS-LSP, FS-CSNP or FS- 343 PSNP [RFC7356]) received via this channel tunnel payload type MUST be 344 discarded. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol =tbd1 | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Flags | ERR | SubERR| RESV4 | SType | 0x4 | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Possible Scope Information 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 355 | Possible Security information 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 357 | 0x83 | rest of IS-IS PDU 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 360 Figure 7. Tunneled TRILL IS-IS Packet Structure 362 3.5 Ethernet Frame 364 If PType is 5, the Tunnel Protocol payload is an Ethernet frame as 365 might be received from or sent to an end station except that the 366 tunneled Ethernet frame's FCS is omitted, as shown in Figure 8. 367 (There is still an overall FCS if the RBridge Channel message is 368 being sent on an Ethernet link.) If this PType is implemented and the 369 message meets local policy, the tunneled frame is handled as if it 370 had been received on the port on which the Tunnel Protocol message 371 was received. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol =tbd1 | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Flags | ERR | SubERR| RESV4 | SType | 0x5 | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Possible Security information 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | MacDA | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | MacDA (cont.) | MacSA | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | MacSA (cont.) | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Any Ethernet frame tagging... 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 390 | Ethernet frame payload... 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 393 Figure 8. Ethernet Frame Channel Tunnel Structure 395 In the case of a non-Ethernet link, such as a PPP link [RFC6361], the 396 ports on the link are considered to have link local synthetic 48-bit 397 MAC addresses constructed by concatenating three 16-bit quantities. 398 This constructed address MAY be used as the MacSA and, if the RBridge 399 Channel message is link local, the source TRILL switch will have the 400 information to construct such a MAC address for the destination TRILL 401 switch port and that MAC address MAY be used as the MacDA. 403 These MAC addresses are constructed as follows: 0xFEFF, the nickname 404 of the TRILL switch used in TRILL Hellos on that port, and the Port 405 ID that the TRILL switch has assigned to that port, as shown in 406 Figure 9. Both the nickname and Port ID appear in the Special VLANs 407 and Flags sub-TLV [RFC7176]. The resulting MAC address has the Local 408 bit on and the Group bit off [RFC7042]. Since end stations are 409 connected to TRILL switches over Ethernet, there will be no end 410 stations on a non-Ethernet link in a TRILL campus. Thus such 411 synthetic MAC addresses cannot conflict on the link with an end 412 station address. 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | 0xFEFF | Nickname | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Port ID | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Figure 9. Synthetic MAC Address 424 4. Security, Keying, and Algorithms 426 The following table gives the assigned values of the SType field and 427 their meaning. 429 SType Section Meaning 430 ----- ------- ------- 431 0 4.2 None 432 1 4.3 [RFC5310] Based Authentication 433 2 4.4 xxx Based Security 434 3-14 Available for assignment on IETF Review 435 15 Reserved 437 Table 3. SType Values 439 For all SType values except zero, the Security Information starts 440 with a byte of flag bits and a byte of remaining length as follows: 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 443 |A|E| RESV | Size | Info 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 446 Figure 12. Security Information Format 448 The fields are as follows: 450 A: Zero if authentication is not being provided. One if it is. 452 E: Zero if encryption is not being provided. One if it is. 454 RESV: Six reserved bits that MUST be sent as zero and ignored on 455 receipt. 457 Size: The number of bytes, as an unsigned integer, of Info in the 458 Security Information after the Size byte itself. 460 Info: Variable length Security Information. 462 4.1 Authentication Coverage 464 Authentication is computed across relevant Channel Tunnel header 465 information and payload with the area when their authentication value 466 is to be stored set to zero. To be more precise, the covered area 467 starts just after the first byte of the RBridge Channel header flags 468 and extends to just before the link trailer. Thus RBridge Channel 469 header flags bits 8 through 11 are protected by authentication while 470 flag bits 0 through 7 are not. 472 4.2 SType None 474 No security services are being invoked. The length of the Security 475 Information field (see Figure 6) is zero. 477 4.3 RFC 5310 Based Authentication 479 The Security Information (see Figure 6) is the flags and Size bytes 480 specified above together with the value of the [RFC5310] Key ID and 481 Authentication Data as shown in Figure 13. 483 1 1 1 1 1 1 484 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 |1|0| RESV | Size | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Key ID | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 + 492 | Authentication Data (Variable) 493 + 494 | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-... 497 Figure 13. SType 1 Security Information 499 The Key ID specifies the same keying value and algorithm that Key ID 500 specifies for core TRILL IS-IS LSP Authentication TLVs; however, to 501 avoid using the same key for multiple purposes, the keying value 502 actually used for Tunnel Channel messages with this SType is a value 503 derived from that TRILL IS-IS value as follows: 505 HMAC-SHA256 ( ( "Channel Tunnel" | Data Label ), IS-IS-key ) 507 where "|" indicates concatenation, HMAC-SHA256 is as in [FIPS-180] 508 [RFC6234], "Channel Tunnel" is the 14 character [ASCII] string 509 indicated, and Data Label is the Data Label in which Channel Tunnel 510 message is being sent as either (1) a right justified 12-bit VLAN ID 511 in two bytes with 4 zero high order bits or (2) three bytes of FGL. 513 4.4 xxx Based Security 515 xxx - permits key negotiation, provides both encryption and 516 authentication ... 518 5. Channel Tunnel Errors 520 RBridge Channel Tunnel Protocol errors are reported like RBridge 521 Channel level errors. The ERR field is set to one of the following 522 error codes: 524 ERR Meaning 525 --- --------- 526 6 Unknown or unsupported field value 527 7 Authentication failure 528 8 Error in nested RBridge Channel message 529 (more TBD?) 531 Table 4. Additional ERR Values 533 5.1 SubERRs under ERR 6 535 If the ERR field is 6, the SubERR field indicates the problematic 536 field or value as show in the table below. 538 SubERR Meaning (for ERR = 6) 539 ------ --------------------- 540 0 Non-zero RESV4 nibble 541 1 Unsupported SType 542 2 Unsupported PType 543 3 Unknown or reserved Scope Egress Nickname in an 544 ESRB scope Tunnel Channel message 545 4 Unsupported crypto algorithm 546 5 Unknown Key ID for SType 1 547 (more TBD) 549 Table 5. SubERR values under ERR 6 551 5.2 Nested RBridge Channel Errors 553 If 554 a Channel Tunnel message is sent with security and with a payload 555 type (PType) indicating a nested RBridge Channel message 556 and 557 there is an error in the processing of that nested message that 558 results in a return RBridge Channel message with a non-zero ERR 559 field, 560 then that returned message SHOULD also be nested in an Channel Tunnel 561 message using the same type of security. In this case, the ERR field 562 in the Channel Tunnel envelope is set to 8 indicating that there is a 563 nested error. 565 6. IANA Considerations 567 IANA has assigned tbd1 as the RBridge Channel protocol number the 568 "Channel Tunnel" protocol from the range assinged by Standards 569 Action. 571 The added RBridge Channel protocols registry entry on the TRILL 572 Parameters web page is as follows: 574 Protocol Description Reference 575 -------- -------------- --------- 577 tbd1 Tunnel Channel [this document] 579 7. Security Considerations 581 The RBridge Channel tunnel facility has potentially positive and 582 negative effects on security. 584 On the positive side, it provides optional security that can be used 585 to authenticate and/or encrypt RBridge Channel messages. Some RBridge 586 Channel message payloads provide their own security [RFC7175] but 587 where this is not true, consideration should be give to requiring use 588 of the security features of the Tunnel Protocol. 590 On the negative side, the optional ability to tunnel various payload 591 types and to tunnel them not just between TRILL switches but to and 592 from end stations can increase risk unless precautions are taking. 593 The processing of decapsulated Tunnel Protocol payloads is not a good 594 place to be liberal in what you accept as the tunneling facility 595 makes it easier for unexpected messages to pop up in unexpected 596 places in a TRILL campus due to accidents or the actions of an 597 adversary. Local policies should generally be strict and only process 598 payload types required and then only with adequate authentication for 599 the particular circumstances. 601 See [RFC7178] for general RBridge Channel Security Considerations. 603 See [RFC6325] for general TRILL Security Considerations. 605 Normative References 607 [ASCII] - American National Standards Institute (formerly United 608 States of America Standards Institute), "USA Code for 609 Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 610 has been replaced by newer versions with slight modifications, 611 but the 1968 version remains definitive for the Internet. 613 [FIPS-180] - "Secure Hash Standard (SHS)", United States of American, 614 National Institute of Science and Technology, Federal 615 Information Processing Standard (FIPS) 180-4, March 2012, 616 http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf 618 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology 619 -- Telecommunications and information exchange between systems 620 -- Intermediate System to Intermediate System intra-domain 621 routeing information exchange protocol for use in conjunction 622 with the protocol for providing the connectionless-mode network 623 service (ISO 8473)", 2002. 625 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 629 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 630 5310, February 2009. 632 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 633 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 634 July 2011. 636 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 637 and D. Dutt, "Transparent Interconnection of Lots of Links 638 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 640 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 641 D., and A. Banerjee, "Transparent Interconnection of Lots of 642 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 643 . 645 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 646 Ward, "Transparent Interconnection of Lots of Links (TRILL): 647 RBridge Channel Support", RFC 7178, May 2014. 649 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 650 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 651 . 653 Informative References 655 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 656 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 657 2011. 659 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 660 Interconnection of Lots of Links (TRILL) Protocol Control 661 Protocol", RFC 6361, August 2011 663 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 664 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 665 BCP 141, RFC 7042, October 2013. 667 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 668 "Transparent Interconnection of Lots of Links (TRILL): 669 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 670 May 2014. 672 Appenxid Z: Change History 674 From -00 to -01 676 1. Fix references for RFCs published, etc. 678 2. Explicitly mention in the Abstract and Introduction that this 679 document updates [RFC7178]. 681 3. Add this Change History Appendix. 683 From -01 to -02 685 1. Remove section on the "Scope" feature as mentioned in 686 http://www.ietf.org/mail-archive/web/trill/current/msg06531.html 688 2. Editorial changes to IANA Considerations to correspond to draft- 689 leiba-cotton-iana-5226bis-11.txt. 691 x. Other Editorial changes. 693 Acknowledgements 695 The contributions of the following are hereby acknowledged: 697 TBD 699 The document was prepared in raw nroff. All macros used were defined 700 within the source file. 702 Authors' Addresses 704 Donald E. Eastlake, 3rd 705 Huawei Technologies 706 155 Beaver Street 707 Milford, MA 01757 USA 709 Phone: +1-508-333-2270 710 Email: d3e3e3@gmail.com 712 Yizhou Li 713 Huawei Technologies 714 101 Software Avenue, 715 Nanjing 210012, China 717 Phone: +86-25-56622310 718 Email: liyizhou@huawei.com 720 Copyright, Disclaimer, and Additional IPR Provisions 722 Copyright (c) 2014 IETF Trust and the persons identified as the 723 document authors. All rights reserved. 725 This document is subject to BCP 78 and the IETF Trust's Legal 726 Provisions Relating to IETF Documents 727 (http://trustee.ietf.org/license-info) in effect on the date of 728 publication of this document. Please review these documents 729 carefully, as they describe your rights and restrictions with respect 730 to this document. Code Components extracted from this document must 731 include Simplified BSD License text as described in Section 4.e of 732 the Trust Legal Provisions and are provided without warranty as 733 described in the Simplified BSD License. The definitive version of 734 an IETF Document is that published by, or under the auspices of, the 735 IETF. Versions of IETF Documents that are published by third parties, 736 including those that are translated into other languages, should not 737 be considered to be definitive versions of IETF Documents. The 738 definitive version of these Legal Provisions is that published by, or 739 under the auspices of, the IETF. Versions of these Legal Provisions 740 that are published by third parties, including those that are 741 translated into other languages, should not be considered to be 742 definitive versions of these Legal Provisions. For the avoidance of 743 doubt, each Contributor to the IETF Standards Process licenses each 744 Contribution that he or she makes as part of the IETF Standards 745 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 746 language to the contrary, or terms, conditions or rights that differ 747 from or are inconsistent with the rights and licenses granted under 748 RFC 5378, shall have any effect and shall be null and void, whether 749 published or posted by such Contributor, or included with or in such 750 Contribution.