idnits 2.17.1 draft-ietf-trill-channel-tunnel-00.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 5, 2013) is 3794 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) == Missing Reference: 'FIPS-180' is mentioned on line 778, but not defined == Unused Reference: 'FIPS180' is defined on line 881, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Updates: RFCchannel Yizhou Li 3 Intended status: Proposed Standard Huawei 4 Expires: June 4, 2014 December 5, 2013 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, for 13 the transmission of typed messages between TRILL switches in the same 14 campus and between TRILL switches and end stations on the same link. 15 This document specifies optional extensions to RBridge Channel that 16 provides three facilities: (1) A mechanism to send such messages 17 between a TRILL switch and an end station in either direction, or 18 between two end stations, when the two devices are in the same campus 19 but not on the same link; (2) A method to support security facilities 20 for RBridge Channel messages; and (3) A method to tunnel a variety of 21 payload types by encapsulating them in an RBridge Channel message. 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Distribution of this document is unlimited. Comments should be sent 29 to the authors or the TRILL working group mailing list: 30 trill@ietf.org 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 44 Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Table of Contents 49 1. Introduction............................................3 50 1.2. Terminology and Acronyms.............................3 52 2. Channel Tunnel Packet Format............................5 54 3. Tunnel Payload Types....................................8 55 3.1 Null Payload...........................................8 56 3.2 RBridge Channel Message Payload........................8 57 3.3 TRILL Data Packet......................................9 58 3.4 TRILL IS-IS Packet....................................10 59 3.5 Ethernet Frame........................................11 61 4. Channel Tunnel Scopes..................................13 62 4.1 End Station to RBridge(s).............................14 63 4.2 RBridge to End Station................................15 64 4.3 End Station to End Station............................16 66 5. Security, Keying, and Algorithms.......................18 67 5.1 Authentication Coverage...............................18 68 5.2 SType None............................................19 69 5.3 RFC 5310 Based Authentication.........................19 70 5.4 DTLS Based Security...................................20 72 6. Channel Tunnel Errors..................................21 73 6.1 SubERRs under ERR 6...................................21 74 6.2 Nested RBridge Channel Errors.........................21 76 7. IANA Considerations....................................22 77 8. Security Considerations................................22 79 Normative References......................................23 80 Informative References....................................23 81 Acknowledgements..........................................25 82 Authors' Addresses........................................26 84 1. Introduction 86 The IETF TRILL protocol [RFC6325] includes an optional RBridge 87 Channel [RFCchannel] facility to support transmission of typed 88 messages (for example BFD [RFCbfd]) between two RBridges in the same 89 campus and between RBridges and end stations on the same link. This 90 document specifies optional extensions to RBridge Channel that 91 provides three facilities: 93 (1) A mechanism to send RBridge Channel messages between a TRILL 94 switch (RBridge) and an end station in either direction, or 95 between two end stations, when the two devices are in the same 96 campus but not on the same link. This mechanism requires the 97 cooperation of a TRILL switch that is on the same link as the 98 end station or stations involved. 100 (2) A method to support security facilities for RBridge Channel 101 messages. 103 (3) A method to tunnel a variety of payload types by encapsulating 104 them in an RBridge Channel message. 106 Any one, two, or all three of these facilities can be use in the same 107 message. 109 There is no mechanism to stop end stations on the same link, from 110 sending native RBridge Channel messages to each other; however, such 111 use is outside the scope of this document. 113 1.2. Terminology and Acronyms 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 This document uses the acronyms defined in [RFC6325] and [RFCchannel] 120 supplemented by the following additional acronym: 122 Data Label - VLAN or FGL. 124 FGL - Fine Grained Label [RFCfgl]. 126 Primary Nickname - If a TRILL switch holds two or more nicknames, 127 the one it holds with the highest priority is the primary 128 nickname. If two or more are held with the same priority, the 129 one with the lowest value, considered as a 16-bit unsigned 130 integer in network byte order, is the primary nickname. 132 RBridge - An alternative term for a TRILL switch. 134 TRILL switch - A device that implements the TRILL protocol 135 [RFC6325], sometimes referred to as an RBridge. 137 2. Channel Tunnel Packet Format 139 The general structure of an RBridge Channel message on a link between 140 TRILL switches (RBridges) is shown in Figure 1 below. When a native 141 RBridge Channel message is sent between an RBridge and an end station 142 on the same link, in either direction, the TRILL Header (including 143 the inner Ethernet addresses and Data Label) is omitted as shown in 144 Figure 2. The type of RBridge Channel message is given by a Protocol 145 field in the RBridge Channel Header that indicates how to interpret 146 the Channel Protocol Specific Payload [RFCchannel]. 148 +-----------------------------------+ 149 | Link Header | 150 +-----------------------------------+ 151 | TRILL Header | 152 +-----------------------------------+ 153 | Inner Ethernet Addresses | 154 +-----------------------------------+ 155 | Data Label (VLAN or FGL) | 156 +-----------------------------------+ 157 | RBridge Channel Header | 158 +-----------------------------------+ 159 | Channel Protocol Specific Payload | 160 +-----------------------------------+ 161 | Link Trailer (FCS if Ethernet) | 162 +-----------------------------------+ 164 Figure 1. RBridge Channel Packet Structure 166 +-----------------------------------+ 167 | Ethernet Link Header | 168 +-----------------------------------+ 169 | RBridge Channel Header | 170 +-----------------------------------+ 171 | Channel Protocol Specific Payload | 172 +-----------------------------------+ 173 | FCS | 174 +-----------------------------------+ 176 Figure 2. Native RBridge Channel Frame 178 The RBridge Channel Header looks like this: 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | 0x8946 | CHV | Channel Protocol | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Flags | ERR | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Channel Protocol Specific Data 187 | 189 Figure 3. RBridge Channel Header 191 where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel 192 Header Version, currently zero. 194 The extensions specified herein are in the form of an RBridge Channel 195 protocol, the Channel Tunnel Protocol. Figure 4 below expands the 196 RBridge Channel Header and Protocol Specific Payload above for the 197 case of the Channel Tunnel Protocol. 199 0 1 2 3 200 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 201 RBridge Channel Header: 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | 0x8946 | 0x0 | Tunnel Protocol(0x00?)| 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Flags | ERR | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Channel Tunnel Protocol Specific: | SubERR| Scope | SType | PType | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Scope Information, variable length (0 length if Scope=0) 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 212 | Security information, variable length (0 length if SType = 0) 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 214 | Tunneled Data, variable length 215 | ... 217 Figure 4. Channel Tunnel Header Structure 219 The RBridge Channel Header field specific to the RBridge Channel 220 Tunnel Protocol is the Protocol field. Its contents MUST be the value 221 allocated for this purpose (see Section 7). 223 The RBridge Tunnel Channel Protocol Specific fields are as follows: 225 SubERR: This field provides further details when a Tunnel Channel 226 error is indicated in the RBridge Channel ERR field. If ERR is 227 zero, then SubERR MUST be sent as zero and ignored on receipt. 228 See Section 6. 230 Scope: This field describes the transport scope of the instance of 231 Channel Tunnel. See Section 4. 233 SType: This field describes the type of security information and 234 features, including keying material, being provided. See 235 Section 5. 237 PType: Payload type. The describes the tunneled data. See Section 238 3 below. 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. 244 Additional RBridge Channel Header flags are specified and used by 245 Channel Tunnel. 247 3. Tunnel Payload Types 249 The RBridge Channel Tunnel Protocol can carry a variety of payloads 250 as indicated by the PType field. Values are shown in the table below 251 with further explanation after the table. 253 PType Section Description 254 ----- ------- ----------- 255 0 Reserved 256 1 3.1 Null 257 2 3.2 RBridge Channel message 258 3 3.3 TRILL Data packet 259 4 3.4 TRILL IS-IS packet 260 5 3.5 Ethernet Frame 261 6-14 (Available for assignment by IETF Review) 262 15 Reserved 264 Table 1. Payload Type Values 266 While implementation of the Channel Tunnel protocol is optional, if 267 it is implemented PTypes 1 (Null) and 2 (RBridge Channel message) 268 MUST be implemented. PTypes 3, 4, and 5 MAY be implemented. The 269 processing of any particular Channel Protocol message and its payload 270 depends on meeting local security and other policy at the destination 271 TRILL switch or end station. 273 3.1 Null Payload 275 The Null payload type is intended to be used for messages such as key 276 negotiation or the like. It indicates that there is no payload. Any 277 data after the possible Scope Information and Security Information 278 fields is ignored. 280 3.2 RBridge Channel Message Payload 282 A PType of 2 indicates that the payload of the Channel Tunnel message 283 is an encapsulated RBridge Channel message without the initial 284 RBridge Channel Ethertype. Typical reasons for sending an RBridge 285 Channel message inside a Channel Tunnel message are to provide 286 security services, such as authentication or encryption, or to 287 forward it through a cooperating border TRILL switch in either 288 direction between an end station and a TRILL switch not on the same 289 link. 291 This looks like the following: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol(tbd) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Flags | ERR | SubERR| Scope | SType | 0x2 | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Possible Scope Information 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 302 | Possible Security information 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | 0x0 | Channel Protocol | Flags | ERR | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Channel Protocol Specific Data ... | 307 | 309 Figure 5. Tunneled Channel Message Channel Tunnel Structure 311 3.3 TRILL Data Packet 313 A PType of 3 indicates that the payload of the Tunnel protocol 314 message is an encapsulated TRILL Data packet without the initial 315 TRILL Ethertype as shown in the figure below. If this PType is 316 implemented, the tunneled TRILL Data packet is handled as if it had 317 been received by the destination TRILL switch on the port where the 318 Channel Tunnel message was received. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol(tbd) | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Flags | ERR | SubERR| Scope | SType | 0x3 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Possible Scope Information 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 329 | Possible Security information 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | V | R |M|Op-Length| Hop Count | Egress Nickname | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Ingress Nickname | Inner.MacDA | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Inner.MacDA continued | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Inner.MacSA | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Inner.MacSA (cont.) | Inner Data Label ... 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 341 | TRILL Data Packet payload 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 344 Figure 6. Nested TRILL Data Packet Channel Tunnel Structure 346 3.4 TRILL IS-IS Packet 348 A PType of 4 indicates that the payload of the Tunnel protocol 349 message is an encapsulated TRILL IS-IS packet without the initial 350 L2-IS-IS Ethertype as shown in the figure below. If this PType is 351 implemented, the tunneled TRILL IS-IS packet is processed by the 352 destination RBridge if it meets local policy. The intended use is to 353 expedite the receipt of a link state PDU by some TRILL switch with an 354 immediate requirement for the enclosed link state data. It is 355 RECOMMENDED that any link local IS-IS PDU (Hello, xSNP, MTU-x) 356 received via this channel tunnel payload type be discarded. 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol(tbd) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Flags | ERR | SubERR|| Scope | SType | 0x4 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Possible Scope Information 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 367 | Possible Security information 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 369 | 0x83 | rest of IS-IS PDU 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 372 Figure 7. Tunneled TRILL IS-IS Packet Structure 374 3.5 Ethernet Frame 376 If PType is 5, the Tunnel Protocol payload is an Ethernet frame as 377 might be received from or sent to an end station except that the 378 tunneled Ethernet frame's FCS is omitted, as shown in Figure 8. 379 (There is still an overall FCS if the RBridge Channel message is 380 being sent on an Ethernet link.) If this PType is implemented, the 381 tunneled frame is handled as if it had been received on the port on 382 which the Tunnel Protocol message was received. 384 In the case of a non-Ethernet link, such as a PPP link [RFC6361], the 385 ports on the link are considered to have link local synthetic 48-bit 386 MAC addresses constructed by concatenating three 16-bit quantities: 387 0xFEFF, the primary nickname of the TRILL switch (see Section 1.2), 388 and the Port ID that the TRILL switch has assigned to that port, as 389 shown in Figure 9. The resulting MAC address has the Local bit on and 390 the Group bit off [RFC7042]. Since end stations are connected to 391 TRILL switches over Ethernet, there will be no end stations on a non- 392 Ethernet link in a TRILL campus. Thus such synthetic MAC addresses 393 cannot conflict on the link with an end station address. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol(tbd) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Flags | ERR | SubERR| Scope | SType | 0x5 | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Possible Scope Information 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 404 | Possible Security information 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | MacDA | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | MacDA (cont.) | MacSA | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | MacSA (cont.) | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Any Ethernet frame tagging... 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 414 | Ethernet frame payload... 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 417 Figure 8. Ethernet Frame Channel Tunnel Structure 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | 0xFEFF | Primary Nickname | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Port ID | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 9. Synthetic MAC Address 429 4. Channel Tunnel Scopes 431 The Channel Tunnel protocol extends the RBridge Channel facility to 432 optionally support typed messages between an end station and a TRILL 433 switch, in either direction, or between two end stations, when these 434 devices are part of the same TRILL campus but not on the same link. 435 The scopes specified in this document are as follows: 437 Scope Symbol Section From-To 438 ----- ------ ------- ------- 439 0 NORM Normal 440 1 ESRB 4.1 End Station to RBridge 441 2 RBES 4.2 RBridge to End Station 442 3 ESES 4.3 End Station to End Station 443 4-14 Available for assignment by IETF Review 444 15 Reserved 446 Table 2. Scope Values 448 If the Channel Tunnel protocol is supported, then the NORM scope MUST 449 be supported. Other scopes MAY be supported. In cases where a 450 sequence of steps is given below, other processing sequences 451 producing the same result are allowed. 453 NORM: This is the normal scope of an RBridge Channel message; thus it 454 is either between two TRILL switches in the same campus or between 455 a TRILL switch and an end station on the same link in either 456 direction. The base RBridge Channel mechanisms apply [RFCchannel]. 457 The scope dependent addressing information is of zero length. This 458 scope is typically used when just the security and/or payload type 459 features of the Tunnel Protocol are desired. If a TRILL switch 460 supports the Channel Tunnel facility, it MUST support NORM scope. 462 ESRB: From end station to RBridge(s) not on the same link. The scope 463 dependent address information is eight bytes long. See Section 4.1 464 for further details. This scope MAY be supported. 466 RBES: From RBridge to end station(s) not on the same link. The scope 467 dependent address information is eight bytes long. See Section 4.2 468 for further details. This scope MAY be supported. 470 ESES: From end station to end station(s) not on the same link. The 471 scope information is twelve bytes long. See Section 4.3 for 472 further details. This scope MAY be supported. 474 It is an implementation option and may depend on local policy whether 475 or not an edge TRILL switch that has been requested to forward a 476 Channel Tunnel protocol message due to a non-NORM Scope examines the 477 SType and, if it does examine the SType, whether it verifies any 478 authentication. 480 4.1 End Station to RBridge(s) 482 The ESRB scope additional information is as follows: 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Scope Destination Nickname | (2 bytes) 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 487 | Scope Source MAC Address | (6 bytes) 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 490 Figure 10. ESRB Scope Information 492 To support the case where an end station originates a multi- 493 destination RBridge Channel message to all the TRILL switches 494 advertising interest in a Data Label, the BR (Broadcast) bit is the 495 RBridge Channel Header Flags field is used (see Section 7). 497 Steps by the source end station: 499 If the RBridge Channel message is intended to a single destination 500 RBridge, the source end station sets the Scope Destination 501 Nickname to a nickname of that RBridge and ensures that the BR bit 502 is zero. If the message is intended to be broadcast to the 503 RBridges indicating interest in a Data Label, the end stations 504 sets the BR bit, uses that Data Label as part of the TRILL Header 505 information, and the contents of the Scope Destination Nickname 506 field is ignored. 508 Steps by the ingress TRILL switch on receiving the native RBridge 509 Channel message from the end station: 511 0. As with any RBridge Channel message, determine, as a matter of 512 local policy, whether the native RBridge Channel message is 513 acceptable and discard it if it is not. This test might take 514 into account, for example, whether the message is authenticated 515 (see Section 5), whether or not the BR flag is set, and whether 516 or not the original native destination MAC address is All-Edge- 517 RBridges. 518 1. Store the native RBridge Channel message's source MAC address 519 into the Scope Source MAC Address field. 520 2. Clear the NA bit and set the MH bit in the RBridge Channel 521 Header flags. 522 3. Set the native RBridge Channel message's MAC destination 523 address to All-Egress-RBridges. 524 4. Set the native RBridge Channel message's MAC source address to 525 the MAC address that the ingress RBridge normally uses as the 526 Inner.MacSA for RBridge Channel messages it originates. 527 5.a. If the BR flag is zero, ingress the modified native frame as 528 a unicast TRILL RBridge Channel message with egress nickname 529 set from the Scope Destination Nickname. If that Scope 530 Destination Nickname is unknown, the appropriate error SHOULD 531 be returned (see Section 6). 532 5.b If the BR flag is one, select a distribution tree and ingress 533 the modified native frame as a multi-destination TRILL RBridge 534 Channel message. 535 5.c Regardless of the BR flag value, the Inner.VLAN is the VLAN ID 536 reported by the ingress port or, if that port is configured for 537 FGL, the Inner.Label is the FGL that VLAN maps to [RFCfgl]. 538 6. Process the resulting RBridge Channel message. Note that if it 539 is unicast to the ingress TRILL switch as egress, it is then 540 immediately egressed. And if it is multi-destination and the 541 ingress RBridge qualifies, a copy is egressed as well as a copy 542 being sent on the selected distribution tree. 544 4.2 RBridge to End Station 546 The RBES scope additional addressing information is as follows: 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 549 | Scope Destination MAC Address | (6 bytes) 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 551 | Scope Source Nickname | (2 bytes) 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Figure 11. RBES Scope Information 556 Steps by the source TRILL switch: 558 The source RBridge must set the Scope Destination MAC Address 559 field. It creates an RBridge Channel message, either unicast or 560 multi-destination, based on that MAC address. (The Inner.MacDA 561 cannot be used for this because it must be the All-Egress-RBridges 562 MAC address.) The created RBridge Channel message is unicast if 563 the Scope Destination MAC address is unicast and the creating 564 RBridge knows the egress by which that MAC address is reachable. 565 The created RBridge Channel message is multi-destination if the 566 Scope Destination MAC Address is broadcast, multicast, or unknown 567 unicast. The source TRILL switch sets the Inner.MacSA to the MAC 568 address it usually uses for RBridge Channel messages and also 569 selects the Inner Data Label. 571 Steps by the egress RBridge(s): 573 An egress RBridge stores the ingress nickname into the Scope 574 Source Nickname and sets the NA bit in the RBridge Channel Header 575 flags. It then egresses the frame as a native RBridge Channel 576 message, setting the native frame's outer destination and source 577 MAC addresses to the Scope Destination MAC Address and the egress 578 RBridge port's MAC address, respectively. 580 If the original RBridge Channel message was multi-destination it 581 might be egressed by more than one RBridge, each of which would 582 perform the above transform. Whether such a multi-destination 583 RBridge Channel Tunnel Protocol message would be accepted by any 584 particular egress TRILL switch is a matter of local policy. 586 4.3 End Station to End Station 588 The ESES scope additional addressing information is as follows: 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 591 | Scope Destination MAC Address | (6 bytes) 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 593 | Scope Source MAC Address | (6 bytes) 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 596 Figure 12. ESES Scope Information 598 Steps by the source end stations: 600 If the RBridge Channel message is intended for a single 601 destination end station, the source end station sets the Scope 602 Destination MAC address to the MAC address of that end station and 603 ensures that the BR bit is zero. If the message is intended to be 604 broadcast to a set of end stations via a multicast MAC address or 605 the broadcast MAC address, the end station sets the Scope 606 Destination MAC address to that multicast or broadcast address and 607 sets the BR bit. All of this is within the VLAN of the native 608 RBridge Channel message or its Fine Grained Label (FGL) if the 609 ingress port is configured to map to an FGL. 611 Steps by the ingress RBridge: 613 0. As with any RBridge Channel message, determine, as a matter of 614 local policy, whether the native RBridge Channel message is 615 acceptable and discard it if it is not. This test might take 616 into account, for example, whether the message is authenticated 617 (see Section 5), whether or not the BR flag is set, and whether 618 or not the original Outer.MacDA is All-Edge-RBridges. 619 1. Store the native RBridge Channel message's source MAC address 620 into the Scope Source MAC Address. 621 2. Clear the NA bit and set the MH bit in the RBridge Channel 622 Header flags. 623 3. Set the native RBridge Channel message's MAC destination 624 address to All-Egress-RBridges. 625 4. Set the native RBridge Channel message's MAC source address to 626 the MAC address that the ingress RBridge normally uses as the 627 Inner.MacSA for RBridge Channel messages it originates. 628 5.a. If the BR flag is zero, lookup the Scope Destination MAC 629 Address and ingress the modified native frame as if it were a 630 unicast native frame with that destination MAC address. This 631 will result in either a unicast TRILL Data packet to the Scope 632 Destination MAC Address or in unknown MAC flooding. 633 5.b If the BR flag is one, select a distribution tree and ingress 634 the modified native frame as a multi-destination TRILL RBridge 635 Channel message. 636 5.c Regardless of the BR flag value, the Inner.VLAN is the VLAN ID 637 reported by the ingress port or, if that port is configured for 638 FGL, the Inner.Lable is the FGL that VLAN maps to. 639 6. Process the resulting RBridge Channel message. Note that if it 640 is unicast to the ingress TRILL switch as egress, it is then 641 immediately egressed. And if it is multi-destination and the 642 ingress TRILL switch qualifies, a copy is egressed as well as a 643 copy being sent on the selected distribution tree. It is 644 possible that the Scope Destination MAC is actually out a 645 different or even the same port of the ingress TRILL switch as 646 the port on which the native RBridge Channel message was 647 received. 649 Steps by the egress RBridge(s): 651 The egress RBridge sets the NA bit in the RBridge Channel Header 652 flags. It then egresses the frame as a native RBridge Channel 653 message, setting the native frame's outer destination and source 654 MAC addresses to the Scope Destination MAC Address and the egress 655 RBridge port's MAC address, respectively. 657 If the original RBridge Channel message was multi-destination it 658 might be egressed by more than one TRILL switch, each of which 659 would perform the above transform. Whether such a multi- 660 destination RBridge Channel Tunnel Protocol message would be 661 accepted by egress TRILL switches is a matter of local policy. 663 5. Security, Keying, and Algorithms 665 The following table gives the assigned values of the SType field and 666 their meaning. 668 SType Section Meaning 669 ----- ------- ------- 670 0 5.2 None 671 1 5.3 [RFC5310] Based Authentication 672 2 5.4 DTLS Based Security 673 3-14 Available for assignment on IETF Review 674 15 Reserved 676 Table 3. SType Values 678 For all SType values except zero, the Security Information starts 679 with a byte of flag bits and a byte of remaining length as follows: 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 682 |A|E| RESV | Size | Info 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 685 Figure 12. Security Information Format 687 The fields are as follows: 689 A: Zero if authentication is not being provided. One if it is. 691 E: Zero if encryption is not being provided. One if it is. 693 RESV: Six reserved bits that MUST be sent as zero and ignored on 694 receipt. 696 Size: The number of bytes, as an unsigned integer, of Info in the 697 Security Information after the Size byte itself. 699 Info: Variable length Security Information. 701 5.1 Authentication Coverage 703 Authentication is computed across relevant Channel Tunnel header 704 information and payload with the area when their authentication value 705 is to be stored set to zero. To be more precise, the covered area 706 starts just after the first byte of the RBridge Channel header flags 707 and extends to just before the link trailer. Thus RBridge Channel 708 header flags bits 8 through 11 are protected by authentication while 709 flag bits 0 through 7 are not. 711 Any Scope Information (see Figure 6) MUST be correctly filled in when 712 the authentication value is computed or verified even when this is 713 not required on the wire for correct routing, as follows: 715 ESRB: (Section 3.1) Authentication value computation at the origin 716 end stations MUST be done with the Source Scope MAC Address filled 717 in (as well as the Scope Destination Nickname which is required 718 for correct routing). Similarly, a TRILL switch ingressing an ESRB 719 packet, which is required to set the Source Scope MAC Address in 720 any case, will not be able to correctly validate the 721 authentication value unless it is correctly set. There should be 722 no problem at the egress TRILL switch as by the time the packet 723 gets there, the Source Scope MAC Address should be correctly set. 725 RBES: (Section 3.2) Authentication value computation at the origin 726 TRILL switch MUST be done with the Source Scope Nickname filled in 727 (as well as the Scope Destination MAC Address which is required 728 for correct routing). Similarly, a TRILL switch egressing an RBES 729 packet, which is required to update the Source Scope Nickname in 730 any case, will not be able to correctly validate the 731 authentication value unless that nickname is correctly set. 733 ESES: (Section 3.3) Authentication value computation at the origin 734 end stations MUST be done with the Source Scope MAC Address filled 735 in (as well as the Scope Destination MAC Address which is required 736 for correct routing). Similarly, a TRILL switch ingressing an ESES 737 packet, which is required to update the Source Scope MAC Address 738 in any case, will not be able to correctly validate the 739 authentication value unless it is correctly set. There should be 740 no problem at the egress TRILL switch as by time the packet gets 741 there, the Source Scope MAC Address should be correctly set. 743 5.2 SType None 745 No security services are being invoked. The length of the Security 746 Information field (see Figure 6) is zero. 748 5.3 RFC 5310 Based Authentication 750 The Security Information (see Figure 6) is the flags and Size bytes 751 specified above together with the value of the [RFC5310] Key ID and 752 Authentication Data as shown in Figure 13. 754 1 1 1 1 1 1 755 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 |1|0| RESV | Size | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Key ID | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | | 762 + 763 | Authentication Data (Variable) 764 + 765 | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-... 768 Figure 13. SType 1 Security Information 770 The Key ID specifies the same keying value and algorithm that Key ID 771 specifies for core TRILL IS-IS LSP Authentication TLVs; however, to 772 avoid using the same key for multiple purposes, the keying value 773 actually used for Tunnel Channel messages with this SType is a value 774 derived from that TRILL IS-IS value as follows: 776 HMAC-SHA256 ( ( "Channel Tunnel" | Data Label ), IS-IS-key ) 778 where "|" indicates concatenation, HMAC-SHA256 is as in [FIPS-180] 779 [RFC6234], "Channel Tunnel" is the 14 character [ASCII] string 780 indicated, and Data Label is the Data Label in which Channel Tunnel 781 message is being sent as either (1) a right justified 12-bit VLAN ID 782 in two bytes with 4 zero high order bits or (2) three bytes of FGL. 784 5.4 DTLS Based Security 786 TBD - permits key negotiation, provides both encryption and 787 authentication [RFC6347]... 789 6. Channel Tunnel Errors 791 RBridge Channel Tunnel Protocol errors are reported like RBridge 792 Channel level errors. The ERR field is set to one of the following 793 error codes: 795 ERR Meaning 796 --- --------- 797 6 Unknown or unsupported field value 798 7 Authentication failure 799 8 Error in nested RBridge Channel message 800 (more TBD?) 802 Table 4. Additional ERR Values 804 6.1 SubERRs under ERR 6 806 If the ERR field is 6, the SubERR field indicates the problematic 807 field or value as show in the table below. 809 SubERR Meaning (for ERR = 6) 810 ------ --------------------- 811 0 Unsupported Scope 812 1 Unsupported SType 813 2 Unsupported PType 814 3 Unknown or reserved Scope Egress Nickname in an 815 ESRB scope Tunnel Channel message 816 4 Unsupported crypto algorithm 817 5 Unknown Key ID for SType 1 818 (more TBD) 820 Table 5. SubERR values under ERR 6 822 6.2 Nested RBridge Channel Errors 824 If 825 a Channel Tunnel message is sent with security and with a payload 826 type (PType) indicating a nested RBridge Channel message 827 and 828 there is an error in the processing of that nested message that 829 results in a return RBridge Channel message with a non-zero ERR 830 field, 831 then that returned message SHOULD also be nested in an Channel Tunnel 832 message using the same type of security. In this case, the ERR field 833 in the Channel Tunnel envelope is set to 8 indicating that there is a 834 nested error. 836 7. IANA Considerations 838 IANA is requested to allocate a new RBridge Channel protocol number 839 from the range based on Standards Action for the "Channel Tunnel" 840 protocol. 842 IANA is requested to allocate a new RBridge Channel Header flag bit 843 for the Broadcast (BR) flag with this document as reference. Bit 8 is 844 suggest. In any case, this bit must be one of the low order 4 bit, 845 that is, bits 8 through 11. 847 8. Security Considerations 849 The RBridge Channel tunnel facility has potentially positive and 850 negative effects on security. 852 On the positive side, it provides optional security that can be used 853 to authenticate and/or encrypt channel messages. Some RBridge Channel 854 message payloads provide their own security [RFCbfd] but where this 855 is not true, careful consideration should be give to requiring use of 856 the security features of the Tunnel Protocol. 858 On the negative side, the ability to tunnel various payload types and 859 to tunnel them not just between TRILL switches but to and from end 860 stations can increase risk unless precautions are taking. The 861 processing of decapsulated Tunnel Protocol payloads is not a good 862 place to be liberal in what you accept as the tunneling facility 863 makes it easier for unexpected messages to pop up in unexpected 864 places in a TRILL campus due to accidents or the actions of an 865 adversary. Local policies should generally be strict and only process 866 payload types required and then only with adequate authentication for 867 the particular circumstances. 869 See [RFCchannel] for general RBridge Channel Security Considerations. 871 See [RFC6325] for general TRILL Security Considerations. 873 Normative References 875 [ASCII] - American National Standards Institute (formerly United 876 States of America Standards Institute), "USA Code for 877 Information Interchange", ANSI X3.4-1968, 1968. ANSI X3.4-1968 878 has been replaced by newer versions with slight modifications, 879 but the 1968 version remains definitive for the Internet. 881 [FIPS180] - "Secure Hash Standard (SHS)", United States of American, 882 National Institute of Science and Technology, Federal 883 Information Processing Standard (FIPS) 180-4, March 2012, 884 http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf 886 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 887 Requirement Levels", BCP 14, RFC 2119, March 1997. 889 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 890 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 891 5310, February 2009. 893 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 894 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 895 July 2011. 897 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 898 Security Version 1.2", RFC 6347, January 2012. 900 [RFCchannel] - D. Eastlake, V. Manral, Y. Li, S. Aldrin, D. Ward, 901 "TRILL: RBridge Channel Support", draft-ietf-trill-rbridge- 902 channel-08.txt, in RFC Editor's queue. 904 [RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R Perlman, D. Dutt, 905 "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine-labeling, 906 in RFC Editor's queue. 908 Informative References 910 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 911 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 912 2011. 914 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 915 Interconnection of Lots of Links (TRILL) Protocol Control 916 Protocol", RFC 6361, August 2011 918 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 919 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 920 BCP 141, RFC 7042, October 2013. 922 [RFCbfd] - Manral, V., D. Eastlake, D. Ward, A. Banerjee, "TRILL 923 (Transparent Interconnetion of Lots of Links): Bidirectional 924 Forwarding Detection (BFD) Support", draft-ietf-trill-rbridge- 925 bfd, in RFC Editor's queue. 927 Acknowledgements 929 The contributions of the following are hereby acknowledged: 931 TBD 933 The document was prepared in raw nroff. All macros used were defined 934 within the source file. 936 Authors' Addresses 938 Donald E. Eastlake, 3rd 939 Huawei Technologies 940 155 Beaver Street 941 Milford, MA 01757 USA 943 Phone: +1-508-333-2270 944 Email: d3e3e3@gmail.com 946 Yizhou Li 947 Huawei Technologies 948 101 Software Avenue, 949 Nanjing 210012, China 951 Phone: +86-25-56622310 952 Email: liyizhou@huawei.com 954 Copyright, Disclaimer, and Additional IPR Provisions 956 Copyright (c) 2013 IETF Trust and the persons identified as the 957 document authors. All rights reserved. 959 This document is subject to BCP 78 and the IETF Trust's Legal 960 Provisions Relating to IETF Documents 961 (http://trustee.ietf.org/license-info) in effect on the date of 962 publication of this document. Please review these documents 963 carefully, as they describe your rights and restrictions with respect 964 to this document. Code Components extracted from this document must 965 include Simplified BSD License text as described in Section 4.e of 966 the Trust Legal Provisions and are provided without warranty as 967 described in the Simplified BSD License. The definitive version of 968 an IETF Document is that published by, or under the auspices of, the 969 IETF. Versions of IETF Documents that are published by third parties, 970 including those that are translated into other languages, should not 971 be considered to be definitive versions of IETF Documents. The 972 definitive version of these Legal Provisions is that published by, or 973 under the auspices of, the IETF. Versions of these Legal Provisions 974 that are published by third parties, including those that are 975 translated into other languages, should not be considered to be 976 definitive versions of these Legal Provisions. For the avoidance of 977 doubt, each Contributor to the IETF Standards Process licenses each 978 Contribution that he or she makes as part of the IETF Standards 979 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 980 language to the contrary, or terms, conditions or rights that differ 981 from or are inconsistent with the rights and licenses granted under 982 RFC 5378, shall have any effect and shall be null and void, whether 983 published or posted by such Contributor, or included with or in such 984 Contribution.