idnits 2.17.1 draft-eastlake-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 (October 21, 2013) is 3812 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) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: April 20, 2014 October 21, 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 3. Channel Tunnel Scopes..................................13 62 3.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 SType None............................................18 68 5.2 RFC 5310 Based Authentication.........................18 69 5.3 DTLS Based Security...................................19 71 6. Channel Tunnel Errors..................................20 72 6.1 SubERRs under ERR 6...................................20 74 7. IANA Considerations....................................21 75 8. Security Considerations................................21 77 Normative References......................................22 78 Informative References....................................22 79 Acknowledgements..........................................23 80 Authors' Addresses........................................24 82 1. Introduction 84 The IETF TRILL protocol [RFC6325] provides efficient least cost 85 transparent frame routing in multi-hop networks with arbitrary 86 topologies and link technologies, using link-state routing and a 87 header with a hop count. End stations are attached to TRILL switches 88 by Ethernet but links between TRILL switches can be arbitrary 89 technology. In general, the TRILL way to address or specify a TRILL 90 switch (RBridge) in a TRILL campus is by the switch's TRILL provided 91 nickname [RFC6325] [ClearCorrect]. 93 The TRILL protocol includes an optional RBridge Channel facility 94 [RFCchannel] to support typed message transmission between two 95 RBridges (for example BFD [RFCbfd]) in the same campus and between 96 RBridges and end stations on the same link. 98 This document specifies optional extensions to RBridge Channel that 99 provides three facilities: 101 (1) A mechanism to send RBridge Channel messages between a TRILL 102 switch and an end station in either direction, or between two 103 end stations, when the two devices are in the same campus but 104 not on the same link. This mechanism requires the cooperation 105 of an RBridge that is on the same link as the end station or 106 stations involved. 108 (2) A method to support security facilities for RBridge Channel 109 messages. 111 (3) A method to tunnel a variety of payload types by encapsulating 112 them in an RBridge Channel message. 114 Any one, two, or all three of these facilities can be use in the same 115 message. 117 There is no mechanism to stop end stations on the same link, from 118 sending native RBridge Channel messages to each other; however, such 119 use is outside the scope of this document. 121 1.2. Terminology and Acronyms 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 This document uses the acronyms defined in [RFC6325] and [RFCchannel] 128 supplemented by the following additional acronym: 130 Data Label - VLAN or Fine Grained Label [RFCfgl]. 132 Primary Nickname - If a TRILL switch holds two or more nicknames, 133 the one it holds with the highest priority is the primary 134 nickname. If two or more are held with the same priority, the 135 one with the lowest value, considered as a 16-bit unsigned 136 integer in network byte order, is the primary nickname. 138 TRILL switch - An alternative term for an RBridge. 140 2. Channel Tunnel Packet Format 142 The general structure of an RBridge Channel message on a link between 143 TRILL switches (RBridges) is shown in Figure 1 below. When a native 144 RBridge Channel message is sent between an RBridge and an end station 145 on the same link, in either direction, the TRILL Header (including 146 the inner Ethernet addresses and Data Label) is omitted as shown in 147 Figure 2. The type of RBridge Channel message is given by a Protocol 148 field in the RBridge Channel Header which indicates how to interpret 149 the Channel Protocol Specific Payload [RFCchannel]. 151 +-----------------------------------+ 152 | Link Header | 153 +-----------------------------------+ 154 | TRILL Header | 155 +-----------------------------------+ 156 | Inner Ethernet Addresses | 157 +-----------------------------------+ 158 | Data Label (VLAN or FGL) | 159 +-----------------------------------+ 160 | RBridge Channel Header | 161 +-----------------------------------+ 162 | Channel Protocol Specific Payload | 163 +-----------------------------------+ 164 | Link Trailer (FCS if Ethernet) | 165 +-----------------------------------+ 167 Figure 1. RBridge Channel Packet Structure 169 +-----------------------------------+ 170 | Ethernet Link Header | 171 +-----------------------------------+ 172 | RBridge Channel Header | 173 +-----------------------------------+ 174 | Channel Protocol Specific Payload | 175 +-----------------------------------+ 176 | FCS | 177 +-----------------------------------+ 179 Figure 2. Native RBridge Channel Frame 181 The RBridge Channel Header looks like this: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | 0x8946 | CHV | Channel Protocol | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Flags | ERR | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Channel Protocol Specific Data 190 | 192 Figure 3. RBridge Channel Header 194 where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel 195 Header Version, currently zero. 197 The extensions specified herein are in the form of an RBridge Channel 198 protocol, the Channel Tunnel Protocol. Figure 4 below expands the 199 RBridge Channel Header and Protocol Specific Payload above for the 200 case of the Channel Tunnel Protocol. 202 0 1 2 3 203 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 204 RBridge Channel Header: 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | 0x8946 | 0x0 | Tunnel Protocol(0x00?)| 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Flags | ERR | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Channel Tunnel Protocol Specific: | SubERR| Scope | SType | PType | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Scope Information, variable length (0 length if Scope=0) 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 215 | Security information, variable length (0 length if SType = 0) 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 217 | Tunneled Data, variable length 218 | ... 220 Figure 4. Channel Tunnel Header Structure 222 The RBridge Channel Header field specific to the RBridge Channel 223 Tunnel Protocol is the Protocol field. Its contents MUST be the value 224 allocated for this purpose (see Section 7). 226 The RBridge Tunnel Channel Protocol Specific fields are as follows: 228 SubERR: This field provides further details when a Tunnel Channel 229 error is indicated in the RBridge Channel ERR field. If ERR is 230 zero, then SubERR MUST be sent as zero and ignored on receipt. 231 See Section 6. 233 Scope: This field describes the transport scope of the instance of 234 Channel Tunnel. See Section 4. 236 SType: This field describes the type of security information and 237 features, including keying material, being provided. See 238 Section 5. 240 PType: Payload type. The describes the tunneled data. See Section 241 3 below. 243 The Channel Tunnel protocol is integrated with the RBridge Channel 244 facility. Channel Tunnel errors are reported as if they were RBridge 245 Channel errors, using newly allocated code points in the ERR field of 246 the RBridge Channel Header supplemented by the SubErr field. 247 Additional RBridge Channel Header flags are specified and used by 248 Channel Tunnel. 250 3. Tunnel Payload Types 252 The RBridge Channel Tunnel Protocol can carry a variety of payloads 253 as indicated by the PType field. Value are shown in the table below 254 with further explanation after the table. 256 PType Section Description 257 ----- ------- ----------- 258 0 Reserved 259 1 3.1 Null 260 2 3.2 RBridge Channel message 261 3 3.3 TRILL Data packet 262 4 3.4 TRILL IS-IS packet 263 5 3.5 Ethernet Frame 264 6-14 (Available for assignment by IETF Review) 265 15 Reserved 267 Table 1. Payload Type Values 269 While implementation of the Channel Tunnel protocol is optional, if 270 it is implemented PTypes 1 (Null) and 2 (RBridge Channel message) 271 MUST be implemented. PTypes 3, 4, and 5 MAY be implemented. The 272 processing of any particular Channel Protocol message and its payload 273 depends on meeting local security and other policy at the destination 274 TRILL switch or end station. 276 3.1 Null Payload 278 The Null payload type is intended to be used for messages such as key 279 negotiation or the like. It indicates that there is no payload. Any 280 data after the possible Scope Information and Security Information 281 fields is ignored. 283 3.2 RBridge Channel Message Payload 285 A PType of 2 indicates that the payload of the Channel Tunnel message 286 is an encapsulated RBridge Channel message without the initial 287 RBridge Channel Ethertype. Typical reasons for sending an RBridge 288 Channel message inside a Channel Tunnel message are to provide 289 security services, such as authentication or encryption, or to 290 forward it through a cooperating border TRILL switch in either 291 direction between an end station and a TRILL switch not on the same 292 link. 294 This looks like the following: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol(tbd) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Flags | ERR | SubERR| Scope | SType | 0x2 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Possible Scope Information 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 305 | Possible Security information 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | 0x0 | Channel Protocol | Flags | ERR | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Channel Protocol Specific Data ... | 310 | 312 Figure 5. Tunneled Channel Message Channel Tunnel Structure 314 3.3 TRILL Data Packet 316 A PType of 3 indicates that the payload of the Tunnel protocol 317 message is an encapsulated TRILL Data packet without the initial 318 TRILL Ethertype as shown in the figure below. If this PType is 319 implemented, the tunneled TRILL Data packet is handled as if it had 320 been received by the destination TRILL switch on the port where the 321 Channel Tunnel message was received. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol(tbd) | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Flags | ERR | SubERR| Scope | SType | 0x3 | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Possible Scope Information 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 332 | Possible Security information 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | V | R |M|Op-Length| Hop Count | Egress Nickname | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Ingress Nickname | Inner.MacDA | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Inner.MacDA continued | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Inner.MacSA | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Inner.MacSA (cont.) | Inner Data Label ... 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 344 | TRILL Data Packet payload 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 347 Figure 6. Nested TRILL Data Packet Channel Tunnel Structure 349 3.4 TRILL IS-IS Packet 351 A PType of 4 indicates that the payload of the Tunnel protocol 352 message is an encapsulated TRILL IS-IS packet without the initial 353 L2-IS-IS Ethertype as shown in the figure below. If this PType is 354 implemented, the tunneled TRILL IS-IS packet is processed by the 355 destination RBridge if it meets local policy. The intended use is to 356 expedite the receipt of a link state PDU by some TRILL switch with an 357 immediate requirement for the enclosed link state data. It is 358 RECOMMENDED that any link local IS-IS PDU (Hello, xSNP, MTU-x) 359 received via this channel tunnel payload type be discarded. 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol(tbd) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Flags | ERR | SubERR|| Scope | SType | 0x4 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Possible Scope Information 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 370 | Possible Security information 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 372 | 0x83 | rest of IS-IS PDU 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 375 Figure 7. Tunneled TRILL IS-IS Packet Structure 377 3.5 Ethernet Frame 379 If PType is 5, the Tunnel Protocol payload is an Ethernet frame as 380 might be received from or sent to an end station except that the 381 tunneled Ethernet frame's FCS is omitted, as shown in Figure 8. 382 (There is still an overall FCS if the RBridge Channel message is 383 being sent on an Ethernet link.) If this PType is implemented, the 384 tunneled frame is handled as if it had been received on the port on 385 which the Tunnel Protocol message was received. 387 In the case of a non-Ethernet link, such as a PPP link [RFC6361], the 388 ports on the link are considered to have link local synthetic 48-bit 389 MAC addresses constructed by concatenating three 16-bit quantities: 390 0xFEFF, the primary nickname of the TRILL switch (see Section 1.2), 391 and the Port ID that the RBridge has assigned to that port, as shown 392 in Figure 9. The resulting MAC address has the Local bit on and the 393 Group bit off [RFC5342bis]. Since end stations are connected to TRILL 394 switches only over Ethernet, there can be no end stations on a non- 395 Ethernet link in a TRILL campus. Thus such synthetic MAC addresses 396 cannot conflict on the link with an end station address. 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol(tbd) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Flags | ERR | SubERR| Scope | SType | 0x5 | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Possible Scope Information 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 407 | Possible Security information 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | MacDA | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | MacDA (cont.) | MacSA | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Inner.MacSA | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | MacSA (cont.) | Any Ethernet frame tagging... 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 417 | Ethernet frame payload 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 420 Figure 8. Ethernet Frame Channel Tunnel Structure 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 | Primary Nickname | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Port ID | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 9. Synthetic MAC Address 432 3. Channel Tunnel Scopes 434 The Channel Tunnel protocol extends the RBridge Channel facility to 435 optionally support typed messages between an end station and a TRILL 436 switch, in either direction, or between two end stations, when these 437 devices are part of the same TRILL campus but not on the same link. 438 The scopes specified in this document are as follows: 440 Scope Symbol Section From-To 441 ----- ------ ------- ------- 442 0 NORM Normal 443 1 ESRB 3.1 End Station to RBridge 444 2 RBES 3.2 RBridge to End Station 445 3 ESES 3.3 End Station to End Station 446 4-14 Available for assignment by IETF Review 447 15 Reserved 449 Table 2. Scope Values 451 If the Channel Tunnel protocol is supported, then the NORM scope MUST 452 be supported. All other scopes MAY be supported. In cases where a 453 sequence of steps is given, other processing sequences producing the 454 same result are, as always, allowed. The detail are given below. 456 NORM: This is the normal scope of an RBridge Channel message. The 457 base RBridge Channel mechanisms apply [RFCchannel]. The scope 458 dependent addressing information is of zero length. This scope is 459 typically used when just the security or payload type features of 460 the Tunnel Protocol are desired. If a TRILL switch supports the 461 Channel Tunnel facility, it MUST support NORM scope. 463 ESRB: From end station to RBridge(s) not on the same link. The scope 464 dependent address information is eight bytes long. See Section 4.1 465 for further details. This scope MAY be supported. 467 RBES: From RBridge to end station not on the same link. The scope 468 dependent address information is eight bytes long. See Section 4.2 469 for further details. This scope MAY be supported. 471 ESES: From end station to en station not on the same link. The scope 472 information is twelve bytes long. See Section 4.3 for further 473 details. This scope MAY be supported. 475 It is an implementation option and may depend on local policy whether 476 or not an edge TRILL switch that has been requested to forward a 477 Channel Tunnel protocol message due to a non-NORM Scope examines the 478 SType and, if it does examine the SType, whether it verifies any 479 authentication. 481 3.1 End Station to RBridge(s) 483 The ESRB scope additional information is as follows: 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Scope Destination Nickname | (2 bytes) 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 488 | Scope Source MAC Address | (6 bytes) 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 491 Figure 10. ESRB Scope Information 493 To support the case where an end station originates a multi- 494 destination RBridge Channel message to all the TRILL switches 495 advertising interest in a Data Label, the BR (Broadcast) bit is the 496 RBridge Channel Header Flags field is used (see Section 7). 498 Steps by the source end station: 500 If the RBridge Channel message is intended to a single destination 501 RBridge, the source end station sets the Scope Destination 502 Nickname to the nickname of that RBridge and ensures that the BR 503 bit is zero. If the message is intended to be broadcast to the 504 RBridges indicating interest in a Data Label, the end stations 505 sets the BR bit, uses that Data Label as part of the TRILL Header 506 information, and the contents of the Scope Destination Nickname 507 field is ignored. 509 Steps by the ingress TRILL switch on receiving the native RBridge 510 Channel message from the end station: 512 0. As with any RBridge Channel message, determine, as a matter of 513 local policy, whether the native RBridge Channel message is 514 acceptable and discard it if it is not. This test might take 515 into account, for example, whether the message is authenticated 516 (see Section 5), whether or not the BR flag is set, and whether 517 or not the original native destination MAC address is All-Edge- 518 RBridges. 519 1. Store the native RBridge Channel message's source MAC address 520 into the Scope Source MAC Address field. 521 2. Clear the NA bit and set the MH bit in the RBridge Channel 522 Header flags. 523 3. Set the native RBridge Channel message's MAC destination 524 address to All-Egress-RBridges. 525 4. Set the native RBridge Channel message's MAC source address to 526 the MAC address that the ingress RBridge normally uses as the 527 Inner.MacSA for RBridge Channel messages it originates. 528 5.a. If the BR flag is zero, ingress the modified native frame as 529 a unicast TRILL RBridge Channel message with egress nickname 530 set from the Scope Destination Nickname. If that Scope 531 Destination Nickname is unknown, the appropriate error SHOULD 532 be returned (see Section 6). 533 5.b If the BR flag is one, select a distribution tree and ingress 534 the modified native frame as a multi-destination TRILL RBridge 535 Channel message. 536 5.c Regardless of the BR flag value, the Inner.VLAN is the VLAN ID 537 reported by the ingress port or, if that port is configured for 538 FGL, the Inner.Lable is the FGL that VLAN maps to. 539 6. Process the resulting RBridge Channel message. Note that if it 540 is unicast to the ingress RBridge as egress, it is then 541 egressed. And if it is multi-destination and the ingress 542 RBridge qualifies, a copy is egressed as well as a copy being 543 sent on the selected distribution tree. 545 4.2 RBridge to End Station 547 The RBES scope additional addressing information is as follows: 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 550 | Scope Destination MAC Address | (6 bytes) 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 552 | Scope Source Nickname | (2 bytes) 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 Figure 11. RBES Scope Information 557 Steps by the source TRILL switch: 559 The source RBridge must set the Scope Destination MAC Address 560 field. It creates an RBridge Channel message, either unicast or 561 multi-destination, based on that MAC address. (The Inner.MacDA 562 cannot be used for this because it must be the All-Egress-RBridges 563 MAC address.) The created RBridge Channel message is unicast if 564 the Scope Destination MAC address is unicast and the creating 565 RBridge knows the egress to which that MAC address is connect. The 566 created RBridge channel message is multi-destination if the Scope 567 Destination MAC Address is broadcast, multicast, or unknown 568 unicast. The source RBridge sets the Inner.MacSA to the MAC 569 address it usually uses for RBridge Channel messages and also 570 selects the Inner VLAN or FGL. 572 Steps by the egress TRILL switch(es): 574 The egress TRILL switch stores the ingress nickname into the Scope 575 Source Nickname and sets the NA bit in the RBridge Channel Header 576 flags. It then egresses the frame as a native RBridge Channel 577 message, setting the native frame's outer destination and source 578 MAC addresses to the Scope Destination MAC Address and the egress 579 RBridge port's MAC address, respectively. 581 If the original RBridge Channel message was multi-destination it 582 might be egressed by more than one TRILL switch, each of which 583 would perform the above transform. Whether such a multi- 584 destination RBridge Channel Tunnel Protocol message would be 585 accepted by any particular egress TRILL switch is a matter of 586 local policy. 588 4.3 End Station to End Station 590 The ESES scope additional addressing information is as follows: 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 593 | Scope Destination MAC Address | (6 bytes) 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 595 | Scope Source MAC Address | (6 bytes) 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 598 Figure 12. ESES Scope Information 600 Steps by the source end stations: 602 If the RBridge Channel message is intended for a single 603 destination end station, the source end station sets the Scope 604 Destination MAC address to the MAC address of that end station and 605 ensures that the BR bit is zero. If the message is intended to be 606 broadcast to a set of end stations via a multicast MAC address or 607 the broadcast MAC address, the end station sets the Scope 608 Destination MAC address to that multicast or broadcast address and 609 sets the BR bit. All of this is within the VLAN of the native 610 RBridge Channel message or its Fine Grained Label (FGL) if the 611 ingress port is configured to map to an FGL. 613 Steps by the ingress TRILL switch: 615 0. As with any RBridge Channel message, determine, as a matter of 616 local policy, whether the native RBridge Channel message is 617 acceptable and discard it if it is not. This test might take 618 into account, for example, whether the message is authenticated 619 (see Section 5), whether or not the BR flag is set, and whether 620 or not the original Outer.MacDA is All-Edge-RBridges. 621 1. Store the native RBridge Channel message's source MAC address 622 into the Scope Source MAC Address. 623 2. Clear the NA bit and set the MH bit in the RBridge Channel 624 Header flags. 625 3. Set the native RBridge Channel message's MAC destination 626 address to All-Egress-RBridges. 628 4. Set the native RBridge Channel message's MAC source address to 629 the MAC address that the ingress RBridge normally uses as the 630 Inner.MacSA for RBridge Channel messages it originates. 631 5.a. If the BR flag is zero, lookup the Scope Destination MAC 632 Address and ingress the modified native frame as if it were a 633 unicast native frame with that destination MAC address. This 634 will result in either a unicast TRILL Data packet to the Scope 635 Destination MAC Address or in unknown MAC flooding. 636 5.b If the BR flag is one, select a distribution tree and ingress 637 the modified native frame as a multi-destination TRILL RBridge 638 Channel message. 639 5.c Regardless of the BR flag value, the Inner.VLAN is the VLAN ID 640 reported by the ingress port or, if that port is configured for 641 FGL, the Inner.Lable is the FGL that VLAN maps to. 642 6. Process the resulting RBridge Channel message. Note that if it 643 is unicast to the ingress RBridge as egress, it is then 644 egressed. And if it is multi-destination and the ingress 645 RBridge qualifies, a copy is egressed as well as a copy being 646 sent on the selected distribution tree. It is possible that the 647 Scope Destination MAC is actually out a different or even the 648 same port of the ingress TRILL switch as the port on which the 649 native RBridge Channel message was received. 651 Steps by the egress TRILL switch(es): 653 The egress RBridge sets the NA bit in the RBridge Channel Header 654 flags. It then egresses the frame as a native RBridge Channel 655 message, setting the native frame's outer destination and source 656 MAC addresses to the Scope Destination MAC Address and the egress 657 RBridge port's MAC address, respectively. 659 If the original RBridge Channel message was multi-destination it 660 might be egressed by more than one RBridge, each of which would 661 perform the above transform. Whether such a multi-destination 662 RBridge Channel Tunnel Protocol message would be accepted by 663 egress RBridges is a matter of local policy. 665 5. Security, Keying, and Algorithms 667 The following table gives the assigned values of the SType field and 668 their meaning. 670 SType Section Meaning 671 ----- ------- ------- 672 0 5.1 None 673 1 5.2 RFC 5310 Based Authentication 674 2 5.3 DTLS Based Security 675 3-14 Available for assignment on IETF Review 676 15 Reserved 678 Table 3. SType Values 680 For all SType values except zero, the Security Information starts 681 with a byte of flag bits and a byte of remaining length as follows: 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 684 |A|E| RESV | Size | Info 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 687 Figure 12. Security Information Format 689 The fields are as follows: 691 A: Zero if authentication is not being provided. One if it is. 693 E: Zero if encryption is not being provided. One if it is. 695 RESV: Six reserved bits that MUST be sent as zero and ignored on 696 receipt. 698 Size: The number of byte of Info as an unsigned byte. 700 Info: Variable length Security Information. 702 5.1 SType None 704 No security services are being invoked. The length of the Security 705 Information field (see Figure 6) is zero. 707 5.2 RFC 5310 Based Authentication 709 The security information is the same as the value of the 710 Authentication TLV as specified in [RFC5310]. See figure below. 712 1 1 1 1 1 1 713 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 |1|0| RESV | Size | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Key ID | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | | 720 + + 721 | Authentication Data (Variable)| 722 + + 723 | | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Figure 13. SType 1 Security Information 728 The Key ID normally specifies a keying value and algorithm. 730 5.3 DTLS Based Security 732 TBD - permits key negotiation, provides both encryption and 733 authentication [RFC6347]... 735 6. Channel Tunnel Errors 737 RBridge Channel Tunnel Protocol errors are reported like RBridge 738 Channel level errors. The ERR field is set to one of the following 739 error codes: 741 ERR Meaning 742 --- --------- 743 6 Unknown or unsupported field value 744 7 Authentication failure 745 (more TBD) 747 Table 4. Additional ERR Values 749 6.1 SubERRs under ERR 6 751 If the ERR field is 6, the SubERR field indicates 752 SubERR Meaning (for ERR = 6) 753 ------ --------------------- 754 0 Unsupported Scope 755 1 Unsupported SType 756 2 Unsupported PType 757 3 Unknown or reserved Scope Egress Nickname in an 758 ESRB scope Tunnel Channel message. 759 4 Unsupported crypto algorithm 760 (more TBD) 762 Table 5. SubERR values under ERR 6 764 7. IANA Considerations 766 IANA is requested to allocate a new RBridge Channel protocol number 767 from the range based on Standards Action for the "Channel Tunnel" 768 protocol. 770 IANA is requested to allocate a new RBridge Channel Header flag bit 771 for the Broadcast (BR) flag with this document as reference. 773 8. Security Considerations 775 The RBridge Channel tunnel facility has potentially positive and 776 negative effects on security. 778 On the positive side, it provides optional security that can be used 779 to authenticate and/or encrypt channel messages. Some RBridge Channel 780 message payloads provide their own security [RFCbfd] but where this 781 is not true, careful consideration should be give to requiring use of 782 the security features of the Tunnel Protocol. 784 On the negative side, the ability to tunnel various payload types and 785 to tunnel them not just between TRILL switches but to and from end 786 stations can increase risk unless precautions are taking. The 787 processing of decapsulated Tunnel Protocol payloads is not a good 788 place to be liberal in what you accept as the tunneling facility 789 makes it easier for unexpected messages to pop up in unexpected 790 places in a TRILL campus due to accidents or the actions of an 791 adversary. Local policies should generally be strict and only process 792 payload types required and then only with adequate authentication for 793 the particular circumstances. 795 See [RFCchannel] for general RBridge Channel Security Considerations. 797 See [RFC6325] for general TRILL Security Considerations. 799 Normative References 801 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 802 Requirement Levels", BCP 14, RFC 2119, March 1997. 804 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 805 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 806 5310, February 2009. 808 [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 809 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, 810 July 2011. 812 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 813 Security Version 1.2", RFC 6347, January 2012. 815 [ClearCorrect] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, A. 816 Banerjee, "TRILL: Clarifications, Corrections, and Updates", 817 draft-ietf-trill-clear-correct, in RFC Editor's queue. 819 [RFCchannel] - D. Eastlake, V. Manral, Y. Li, S. Aldrin, D. Ward, 820 "TRILL: RBridge Channel Support", draft-ietf-trill-rbridge- 821 channel-08.txt, in RFC Editor's queue. 823 [RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R Perlman, D. Dutt, 824 "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine-labeling, 825 in RFC Editor's queue. 827 Informative References 829 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 830 Interconnection of Lots of Links (TRILL) Protocol Control 831 Protocol", RFC 6361, August 2011 833 [RFC5342bis] - D. Eastlake, J. Abley, " IANA Considerations and IETF 834 Protocol and Documentation Usage for IEEE 802 Parameters", 835 draft-eastlake-rfc5342bis, work in progress. 837 [RFCbfd] - Manral, V., D. Eastlake, D. Ward, A. Banerjee, "TRILL 838 (Transparent Interconnetion of Lots of Links): Bidirectional 839 Forwarding Detection (BFD) Support", draft-ietf-trill-rbridge- 840 bfd, in RFC Editor's queue. 842 Acknowledgements 844 The contributions of the following are hereby acknowledged: 846 TBD 848 The document was prepared in raw nroff. All macros used were defined 849 within the source file. 851 Authors' Addresses 853 Donald E. Eastlake, 3rd 854 Huawei Technologies 855 155 Beaver Street 856 Milford, MA 01757 USA 858 Phone: +1-508-333-2270 859 EMail: d3e3e3@gmail.com 861 Yizhou Li 862 Huawei Technologies 863 101 Software Avenue, 864 Nanjing 210012, China 866 Phone: +86-25-56622310 867 Email: liyizhou@huawei.com 869 Copyright, Disclaimer, and Additional IPR Provisions 871 Copyright (c) 2013 IETF Trust and the persons identified as the 872 document authors. All rights reserved. 874 This document is subject to BCP 78 and the IETF Trust's Legal 875 Provisions Relating to IETF Documents 876 (http://trustee.ietf.org/license-info) in effect on the date of 877 publication of this document. Please review these documents 878 carefully, as they describe your rights and restrictions with respect 879 to this document. Code Components extracted from this document must 880 include Simplified BSD License text as described in Section 4.e of 881 the Trust Legal Provisions and are provided without warranty as 882 described in the Simplified BSD License. The definitive version of 883 an IETF Document is that published by, or under the auspices of, the 884 IETF. Versions of IETF Documents that are published by third parties, 885 including those that are translated into other languages, should not 886 be considered to be definitive versions of IETF Documents. The 887 definitive version of these Legal Provisions is that published by, or 888 under the auspices of, the IETF. Versions of these Legal Provisions 889 that are published by third parties, including those that are 890 translated into other languages, should not be considered to be 891 definitive versions of these Legal Provisions. For the avoidance of 892 doubt, each Contributor to the IETF Standards Process licenses each 893 Contribution that he or she makes as part of the IETF Standards 894 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 895 language to the contrary, or terms, conditions or rights that differ 896 from or are inconsistent with the rights and licenses granted under 897 RFC 5378, shall have any effect and shall be null and void, whether 898 published or posted by such Contributor, or included with or in such 899 Contribution.