idnits 2.17.1 draft-ietf-trill-channel-tunnel-10.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 (July 5, 2016) is 2851 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '4' on line 797 -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Updates: 7178 Huawei 3 Intended status: Proposed Standard Mohammed Umair 4 IPinfusion 5 Yizhou Li 6 Huawei 7 Expires: January 4, 2017 July 5, 2016 9 TRILL: RBridge Channel Header Extension 10 12 Abstract 14 The IETF TRILL (Transparent Interconnection of Lots of Links) 15 protocol includes an optional mechanism (specified in RFC 7178) 16 called RBridge Channel for the transmission of typed messages between 17 TRILL switches in the same campus and the transmission of such 18 messages between TRILL switches and end stations on the same link. 19 This document specifies extensions to the RBridge Channel protocol 20 header to support two features as follows: (1) a standard method to 21 tunnel payloads whose type can be indicated by Ethertype through 22 encapsulation in RBridge Channel messages; and (2) a method to 23 support security facilities for RBridge Channel messages. This 24 document updates RFC 7178. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Distribution of this document is unlimited. Comments should be sent 32 to the authors or the TRILL working group mailing list: 33 trill@ietf.org 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 47 Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Table of Contents 52 1. Introduction............................................3 53 1.1 Terminology and Acronyms..............................3 55 2. RBridge Channel Header Extension Format.................5 57 3. Extended RBridge Channel Payload Types..................8 58 3.1 Null Payload...........................................8 59 3.2 Ethertyped Payload.....................................8 60 3.2.1 RBridge Channel Message as the Payload...............9 61 3.2.2 TRILL Data Packet as the Payload.....................9 62 3.2.3 TRILL IS-IS Packet as the Payload...................10 63 3.3 Ethernet Frame........................................11 65 4. Extended RBridge Channel Security......................14 66 4.1 Derived Keying Material...............................14 67 4.2 SType None............................................15 68 4.3 [RFC5310]-Based Authentication........................15 69 4.4 DTLS Pairwise Security................................17 70 4.5 Composite Security....................................18 72 5. Extended RBridge Channel Errors........................19 73 5.1 SubERRs under ERR 6...................................19 74 5.2 Secure Nested RBridge Channel Errors..................19 76 6. IANA Considerations....................................20 77 6.1 Extended RBridge Channel Protocol Number..............20 78 6.2 RBridge Channel Protocol Subregistries................20 79 6.2.1 RBridge Channel Error Codes Subregistry.............20 80 6.2.2 Extended RBridge Channel Payload Types Subregistry..21 81 6.2.3 Extended RBridge Channel Security Types Subregistry.21 83 7. Security Considerations................................22 85 Normative References......................................23 86 Informative References....................................24 88 Appendix Z: Change History................................25 89 Acknowledgements..........................................27 90 Authors' Addresses........................................28 92 1. Introduction 94 The IETF TRILL base protocol [RFC6325] [RFC7780] has been extended 95 with the RBridge Channel [RFC7178] facility to support transmission 96 of typed messages (for example BFD (Bidirectional Forwarding 97 Detection) [RFC7175]) between two TRILL switches (RBridges) in the 98 same campus and the transmission of such messages between RBridges 99 and end stations on the same link. When sent between RBridges in the 100 same campus, a TRILL Data packet with a TRILL Header is used and the 101 destination RBridge is indicated by nickname. When sent between a 102 RBridge and an end station on the same link in either direction, a 103 native RBridge Channel message [RFC7178] is used with no TRILL Header 104 and the destination port or ports are indicated by a MAC address. 105 (There is no mechanism to stop end stations on the same link from 106 sending native RBridge Channel messages to each other; however, such 107 use is outside the scope of this document.) 109 This document updates [RFC7178] and specifies extensions to the 110 RBridge Channel header that provide two additional facilities as 111 follows: 113 (1) A standard method to tunnel payloads whose type may be 114 indicated by Ethertype through encapsulation in RBridge 115 Channel messages. 117 (2) A method to provide security facilities for RBridge Channel 118 messages. 120 Use of each of these facilities is optional, except that, as 121 specified below, if this header extension is implemented there are 122 two payload types that MUST be implemented. Both of the above 123 facilities can be used in the same packet. In case of conflict 124 between this document and [RFC7178], this document takes precedence. 126 1.1 Terminology and Acronyms 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in 131 [RFC2119]. 133 This document uses terminology and acronyms defined in [RFC6325] and 134 [RFC7178]. Some of these are repeated below for convenience along 135 with additional new terms and acronyms. 137 application_data - A DTLS [RFC6347] message type. 139 Data Label - VLAN or FGL. 141 DTLS - Datagram Transport Level Security [RFC6347]. 143 FCS - Frame Check Sequence. 145 FGL - Fine Grained Label [RFC7172]. 147 HKDF - HMAC-based Key Derivation Function [RFC5869]. 149 IS-IS - Intermediate System to Intermediate Systems [IS-IS]. 151 PDU - Protocol Data Unit. 153 MTU - Maximum Transmission Unit. 155 RBridge - An alternative term for a TRILL switch. 157 SHA - Secure Hash Algorithm [RFC6234]. 159 Sz - Campus-wide minimum link MTU [RFC6325] [RFC7780]. 161 TRILL - Transparent Interconnection of Lots of Links or Tunneled 162 Routing in the Link Layer. 164 TRILL switch - A device that implements the TRILL protocol 165 [RFC6325] [RFC7780], sometimes referred to as an RBridge. 167 2. RBridge Channel Header Extension Format 169 The general structure of an RBridge Channel message between two TRILL 170 switches (RBridges) in the same campus is shown in Figure 2.1 below. 171 The structure of a native RBridge Channel message sent between an 172 RBridge and an end station on the same link, in either direction, is 173 shown in Figure 2.2 and, compared with the first case, omits the 174 TRILL Header, inner Ethernet addresses, and Data Label. A Protocol 175 field in the RBridge Channel Header gives the type of RBridge Channel 176 message and indicates how to interpret the Channel Protocol Specific 177 Payload [RFC7178]. 179 +-----------------------------------+ 180 | Link Header | 181 +-----------------------------------+ 182 | TRILL Header | 183 +-----------------------------------+ 184 | Inner Ethernet Addresses | 185 +-----------------------------------+ 186 | Data Label (VLAN or FGL) | 187 +-----------------------------------+ 188 | RBridge Channel Header | 189 +-----------------------------------+ 190 | Channel Protocol Specific Payload | 191 +-----------------------------------+ 192 | Link Trailer (FCS if Ethernet) | 193 +-----------------------------------+ 195 Figure 2.1 RBridge Channel Packet Structure 197 +-----------------------------------+ 198 | Ethernet Link Header | 199 +-----------------------------------+ 200 | RBridge Channel Header | 201 +-----------------------------------+ 202 | Channel Protocol Specific Payload | 203 +-----------------------------------+ 204 | FCS | 205 +-----------------------------------+ 207 Figure 2.2 Native RBridge Channel Frame 209 The RBridge Channel Header looks like this: 211 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | 0x8946 | CHV=0 | Channel Protocol | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Flags | ERR | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 218 / Channel Protocol Specific Data / 219 /-+-+-+-+-+- / 221 Figure 2.3 RBridge Channel Header 223 where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel 224 Header Version. This document is based on RBridge Channel version 225 zero. 227 The header extensions specified herein are in the form of an RBridge 228 Channel protocol, the Extended RBridge Channel Protocol. Figure 2.4 229 below expands the RBridge Channel Header and Protocol Specific 230 Payload above for the case where the header extension is present. 232 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 233 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 234 RBridge Channel Header: 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | 0x8946 | CHV=0 | Channel Protocol=[TBD]| 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Flags | ERR | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Header Extension Specific: | SubERR| RESV4 | SType | PType | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Security Information, variable length (0 length if SType = 0) / 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 245 | Tunneled Data, variable length 246 | ... 248 Figure 2.4 RBridge Channel Header Extension Structure 250 The RBridge Channel Header Protocol field is used to indicate that 251 the header extension is present. Its contents MUST be the value 252 allocated for this purpose (see Section 6). The use of an RBridge 253 Channel protocol to indicate extension makes it easy to determine if 254 a remote RBridge in the campus supports extension since RBridges 255 advertise in their LSP which such protocols they support. 257 The Extended RBridge Channel Protocol Specific Data fields are as 258 follows: 260 SubERR: This field provides further details when an error is 261 indicated in the RBridge Channel ERR field. If ERR is zero, 262 then SubERR MUST be sent as zero and ignored on receipt. See 263 Section 5. 265 RESV4: This field MUST be sent as zero. If non-zero when received, 266 this is an error condition (see Section 5). 268 SType: This field describes the type of security information and 269 features, including keying material, being used or provided by 270 the extended RBridge Channel message. See Section 4. 272 PType: Payload type. This describes the tunneled data. See Section 273 3 below. 275 Security Information: Variable length information. Length is zero 276 if SType is zero. See Section 4. 278 The RBridge Channel Header Extension is integrated with the RBridge 279 Channel facility. Extension errors are reported as if they were 280 RBridge Channel errors, using newly allocated code points in the ERR 281 field of the RBridge Channel Header supplemented by the SubERR field. 283 3. Extended RBridge Channel Payload Types 285 The Extended RBridge Channel Protocol can carry a variety of payloads 286 as indicated by the PType field. Values are shown in the table below 287 with further explanation after the table (see also Section 6.2.2). 289 PType Description Reference 290 ----- ----------- --------- 291 0 Reserved 292 1 Null Section 3.1 of [this doc] 293 2 Ethertyped Payload Section 3.2 of [this doc] 294 3 Ethernet Frame Section 3.3 of [this doc] 295 4-14 Unassigned 296 15 Reserved 298 Table 3.1 Payload Type Values 300 While implementation of the RBridge Channel Header Extension is 301 optional, if it is implemented PType 1 (Null) MUST be implemented and 302 PType 2 (Ethertyped Payload) with the RBridge Channel Ethertype MUST 303 be implemented. PType 2 for any Ethertypes other than the RBridge 304 Channel Ethertype MAY be implemented. PType 3 MAY be implemented. 306 The processing of any particular extended header RBridge Channel 307 message and its payload depends on meeting local security and other 308 policy at the destination TRILL switch or end station. 310 3.1 Null Payload 312 The Null payload type (PType = 1) is intended to be used for testing 313 or for messages such as key negotiation or the like where only 314 security information is present. It indicates that there is no 315 payload. Any tunneled data after the Security Information field is 316 ignored. If the RBridge Channel Header Extension is implemented, the 317 Null Payload MUST be supported in the sense that an "Unsupported 318 PType" error is not returned (see Section 5). Any particular use of 319 the Null Payload should specify what VLAN or FGL and what priority 320 should be used in the inner Data Label of the RBridge Channel message 321 (or in an outer VLAN tag for the native RBridge Channel message case) 322 when those values are relevant. 324 3.2 Ethertyped Payload 326 A PType of 2 indicates that the payload (tunneled data) of the 327 extended RBridge Channel message begins with an Ethertype. A TRILL 328 switch supporting the RBridge Channel Header Extension MUST support a 329 PType of 2 with a payload beginning with the RBridge Channel 330 Ethertype as described in Section 3.2.1. Other Ethertypes, including 331 the TRILL and L2-IS-IS Ethertypes as described in Section 3.2.2 and 332 3.2.3, MAY be supported. 334 3.2.1 RBridge Channel Message as the Payload 336 A PType of 2 whose payload has an initial RBridge Channel Ethertype 337 indicates an encapsulated RBridge Channel message. A typical reason 338 for sending an RBridge Channel message inside an extended RBridge 339 Channel message is to provide security services, such as 340 authentication or encryption, for the encapsulated message. 342 This RBridge Channel message type looks like the following: 344 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=[TBD]| 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 / Security Information, variable length (0 length if SType = 0) / 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol| 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Flags | ERR | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 357 | Nested Channel Protocol Specific Data ... / 358 / / 360 Figure 3.1 Message Structure with RBridge Channel Payload 362 3.2.2 TRILL Data Packet as the Payload 364 A PType of 2 whose payload has an initial TRILL Ethertype indicates 365 an encapsulated TRILL Data packet as shown in the figure below. If 366 this Ethertype is supported for PType = 2 and the message meets local 367 policy for acceptance, the TRILL Data packet is handled as if it had 368 been received by the destination TRILL switch on the port where the 369 Extended RBridge Channel message was received. 371 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=[TBD]| 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 / Security Information, variable length (0 length if SType = 0) / 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Egress Nickname | Ingress Nickname | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 / Optional Flags Word / 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Inner.MacDA | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Inner.MacDA continued | Inner.MacSA | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Inner.MacSA (cont.) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Inner Data Label (2 or 4 bytes) 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 394 | TRILL Data Packet payload 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 397 Figure 3.2 Message Structure with TRILL Data Packet Payload 399 The optional flags word is only present if the F bit in the TRILL 400 Header is one [RFC7780]. 402 3.2.3 TRILL IS-IS Packet as the Payload 404 A PType of 2 and an initial L2-IS-IS Ethertype indicates that the 405 payload of the Extended RBridge Channel protocol message is an 406 encapsulated TRILL IS-IS PDU as shown in Figure 3.3. If this 407 Ethertype is supported for PType = 2, the tunneled TRILL IS-IS packet 408 is processed by the destination RBridge if it meets local policy. One 409 possible use is to expedite the receipt of a link state PDU (LSP) by 410 some TRILL switch or switches with an immediate requirement for the 411 link state information. A link local IS-IS PDU (Hello, CSNP, or PSNP 412 [IS-IS]; MTU-probe or MTU-ack [RFC7176]; or circuit scoped FS-LSP, 413 FS-CSNP or FS-PSNP [RFC7356]) would not normally be sent via this 414 Extended RBridge Channel method except possibly to encrypt it since 415 such PDUs can just be transmitted on the link and do not normally 416 need RBridge Channel handling. 418 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=[TBD]| 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Flags | ERR | SubERR| RESV4 | SType | 0x2 | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 / Security Information, variable length (0 length if SType = 0) / 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 427 | L2-IS-IS (0x22F4) | 0x83 | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | rest of IS-IS PDU 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 432 Figure 3.3 Message Structure with TRILL IS-IS Packet Payload 434 3.3 Ethernet Frame 436 If PType is 3, the extended RBridge Channel payload is an Ethernet 437 frame as might be received from or sent to an end station except that 438 the encapsulated Ethernet frame's FCS is omitted, as shown in Figure 439 3.4. (There is still an overall final FCS if the RBridge Channel 440 message is being sent on an Ethernet link.) If this PType is 441 implemented and the message meets local policy, the encapsulated 442 frame is handled as if it had been received on the port on which the 443 Extended RBridge Channel message was received. 445 The priority of the RBridge Channel message can be copied from the 446 Ethernet frame VLAN tag, if one is present, except that priority 7 447 SHOULD only be used for messages critical to establishing or 448 maintaining adjacency and priority 6 SHOULD only be used for other 449 important control messages. 451 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | RBridge-Channel (0x8946) | 0x0 | Channel Protocol=[TBD]| 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Flags | ERR | SubERR| RESV4 | SType | 0x3 | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 / Security Information, variable length (0 length if SType = 0) / 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | MacDA | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | MacDA (cont.) | MacSA | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | MacSA (cont.) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Any Ethernet frame tagging... 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 468 | Ethernet frame payload... 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 471 Figure 3.4 Message Structure with Ethernet Frame Payload 473 In the case of a non-Ethernet link, such as a PPP (Point-to-Point 474 Protocol) link [RFC6361], the ports on the link are considered to 475 have link-local synthetic 48-bit MAC addresses constructed as 476 described below. Such a constructed address MAY be used as a MacSA. 477 If the RBridge Channel message is individually addressed to a link 478 local port, the source TRILL switch will have the information to 479 construct such a MAC address for the destination TRILL switch port 480 and that MAC address MAY be used as the MacDA. By the use of such a 481 MacSA and either such a unicast MacDA or a group addressed MacDA, an 482 Ethernet frame can be sent between two TRILL switch ports connected 483 by a non-Ethernet link. 485 These synthetic TRILL switch port MAC addresses for non-Ethernet 486 ports are constructed as follows: 0xFEFF, the nickname of the TRILL 487 switch used in TRILL Hellos sent on that port, and the Port ID that 488 the TRILL switch has assigned to that port, as shown in Figure 3.5. 489 (Both the Port ID of the port on which a TRILL Hello is sent and the 490 nickname of the sending TRILL switch appear in the Special VLANs and 491 Flags sub-TLV [RFC7176] in TRILL IS-IS Hellos.) The resulting MAC 492 address has the Local bit on and the Group bit off [RFC7042]. 493 However, since there will be no Ethernet end stations on a non- 494 Ethernet link in a TRILL campus, such synthetic MAC addresses cannot 495 conflict on the link with a real Ethernet port address regardless of 496 their value. 498 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | 0xFEFF | Nickname | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Port ID | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 3.5 Synthetic MAC Address 508 4. Extended RBridge Channel Security 510 Table 4.1 below gives the assigned values of the SType field and 511 their meaning. Use of DTLS Pairwise Security (SType = 2) or Composite 512 Security (SType = 3) is RECOMMENDED. 514 While [RFC5310]-based authentication is also specified and can be 515 used for both pairwise and multi-destination traffic, it provides 516 only authentication and is not considered to meet current security 517 standards. For example, it does not provide for key negotiation; 518 thus, its use is NOT RECOMMENDED. 520 The Extended RBridge Channel DTLS-based security specified in Section 521 4.4 and the Composite Security specified in Section 4.5 below are 522 intended for pairwise (known unicast) use. That is, the case where 523 the M bit in the TRILL Header is zero and any Outer.MacDA is 524 individually addressed. 526 Multi-destination Extended RBridge Channel packets would be those 527 with the M bit in the TRILL Header set to one or, in the native 528 RBridge Channel case, the Outer.MacDA would be group addressed. The 529 DTLS Pairwise Security and Composite Security STypes can also be used 530 in the multi-destination case by serially unicasting the messages to 531 all data-accessible RBridges (or stations in the native RBridge 532 Channel case) in the recipient group. For TRILL Data packets, that 533 group is specified by the Data Label; for native frames, the group is 534 specified by the groupcast destination MAC address. It is intended to 535 specify a true group keyed SType to secure multi-destination packets 536 in a separate document [GroupKey]. 538 SType Description Reference 539 ----- ----------- --------- 540 0 None Section 4.2 of [this doc] 541 1 [RFC5310]-Based Authentication Section 4.3 of [this doc] 542 2 DTLS Pairwise Security Section 4.4 of [this doc] 543 3 Composite Security Section 4.5 of [this doc] 544 4-14 Unassigned 545 15 Reserved 547 Table 4.1 SType Values 549 4.1 Derived Keying Material 551 In some cases, it is possible to use material derived from [RFC5310] 552 IS-IS keying material as an element of Extended RBridge Channel 553 security. It is assumed that the IS-IS keying material is of high 554 quality. The material actually used is derived from the IS-IS keying 555 material as follows: 557 Derived Material = 558 HKDF-Expand-SHA256 ( IS-IS-key, "Extended Channel" | 0x0S, L ) 560 where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is 561 as in [RFC6234], IS-IS-key is the input IS-IS keying material, 562 "Extended Channel" is the 16-character ASCII [RFC20] string indicated 563 without any leading length byte or trailing zero byte, 0x0S is a 564 single byte where S is the SType for which this key derivation is 565 being used and the upper nibble is zero, and L is the length of the 566 output-derived material needed. 568 Whenever IS-IS keying material is being used as above, the underlying 569 [RFC5310] keying material might expire or be invalidated. At the time 570 of or before such expiration or invalidation, the use of the Derived 571 Material from the IS-IS keying material MUST cease. Continued 572 security MAY use new derived material from currently valid [RFC5310] 573 keying material. 575 4.2 SType None 577 No security services are being invoked. The length of the Security 578 Information field (see Figure 2.4) is zero. 580 4.3 [RFC5310]-Based Authentication 582 This SType provides security for Extended RBridge Channel messages 583 similar to that provided for [IS-IS] PDUs by the [IS-IS] 584 Authentication TLV. The Security Information (see Figure 2.4) is as 585 shown in Figure 4.1. 587 1 1 1 1 1 1 588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | RESV | Size | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Key ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | | 595 + 596 | Authentication Data (Variable) 597 + 598 | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-... 601 Figure 4.1 SType 1 Security Information 603 o RESV: Four bits that MUST be sent as zero and ignored on receipt. 605 o Size: Set to 2 + the size of Authentication Data in bytes. 607 o Key ID: specifies the keying value and authentication algorithm 608 that the Key ID specifies for TRILL IS-IS LSP [RFC5310] 609 Authentication TLVs. The keying material actually used is derived 610 as shown in Section 4.1. 612 o Authentication Data: The authentication data produced by the 613 derived key and algorithm associated with the Key ID acting on the 614 part of the TRILL Data packet shown. Length of the authentication 615 data depends on the algorithm. The authentication value is 616 included in the security information field and is treated as zero 617 when authentication is calculated. 619 As show in Figure 4.2, the area covered by this authentication starts 620 with the byte immediately after the TRILL Header optional Flag Word 621 if it is present. If the Flag Word is not present, it starts after 622 the TRILL Header Ingress Nickname. In either case, it extends to just 623 before the TRILL Data packet link trailer. For example, for an 624 Ethernet packet it would extend to just before the FCS. 626 +-----------------------------+ 627 | Link Header | 628 +-----------------------------+ 629 | TRILL Header | 630 | (plus optional flag word) | 631 +-----------------------------+ ^ 632 | Inner Ethernet Addresses | | 633 +-----------------------------+ . 634 | Data Label (VLAN or FGL) | | 635 +-----------------------------+ . 636 | RBridge Channel Header | | <-authentication 637 +-----------------------------+ . 638 | Extended Channel Header | | 639 | (plus Security Information)| . 640 +-----------------------------+ | 641 | Payload | . 642 +-----------------------------+ v 643 | Link Trailer | 644 +-----------------------------+ 646 Figure 4.2. SType 1 Authentication Coverage 648 In the native RBridge Channel case this authentication coverage is as 649 specified in the above paragraph except that it starts with the 650 RBridge Channel Ethertype, since there is no TRILL Header, inner 651 Ethernet addresses, or inner Data Label (see Figure 4.3). 653 +-----------------------------+ 654 | Ethernet Header | 655 +-----------------------------+ ^ 656 | RBridge Channel Header | | 657 +-----------------------------+ . 658 | Extended Channel Header | | <-authentication 659 | (plus Security Information)| . 660 +-----------------------------+ | 661 | Payload | . 662 +-----------------------------+ v 663 | Ethernet Trailer | 664 +-----------------------------+ 666 Figure 4.3. Native SType 1 Authentication Coverage 668 While RBridges, which are IS-IS routers, can reasonably be expected 669 to hold [RFC5310] keying so that this SType can be used for RBridge 670 Channel messages, how end stations might come to hold [RFC5310] 671 keying is beyond the scope of this document. Thus this SType might 672 not be applicable to native RBridge Channel messages. 674 4.4 DTLS Pairwise Security 676 DTLS [RFC6347] supports key negotiation and provides both encryption 677 and authentication. The RBridge Channel Extended Header DTLS Pairwise 678 SType uses a negotiated DTLS version that MUST NOT be less than 1.2. 680 When DTLS pairwise security is used, the entire payload of the 681 Extended RBridge Channel packet, starting just after the null 682 Security Information and ending just before the link trailer, is one 683 or more DTLS records [RFC6347]. As specified in [RFC6347], DTLS 684 records MUST be limited by the path MTU, in this case so each record 685 fits entirely within a single Extended RBridge Channel message. A 686 minimum path MTU can be determined from the TRILL campus minimum MTU 687 Sz, which will not be less than 1470 bytes, by allowing for the TRILL 688 Data packet, extended RBridge Channel, and DTLS framing overhead. 689 With this SType, the security information between the extended 690 RBridge Channel header and the payload is null because all the 691 security information is in the payload area. 693 The DTLS Pairwise keying is set up between a pair of RBridges 694 independent of Data Label using messages of a priority configurable 695 at the RBridge level which defaults to priority 6. DTLS message types 696 other than application_data can be the payload of an extended RBridge 697 Channel message with a TRILL Header using any Data Label. Actual 698 application_data sent within such a message using this SType SHOULD 699 use the Data Label and priority as specified for that 700 application_data. In this case, the PType value in the RBridge 701 Channel Header Extension applies to the decrypted application_data. 703 TRILL switches that implement the extended RBridge Channel DTLS 704 Pairwise SType SHOULD support the use of certificates for DTLS but 705 certificate size may be limited by the DTLS requirement that each 706 record fit within a single message. 708 TRILL switches that support the extended RBridge Channel DTLS 709 Pairwise SType MUST support the use of pre-shared keys. If the 710 psk_identity (see [RFC4279]) is two bytes, it is interpreted as a 711 [RFC5310] Key ID and the value derived as shown in Section 4.1 from 712 that key is used as a pre-shared key for DTLS negotiation. A 713 psk_identity with a length other than two bytes MAY be used to 714 indicate other implementation dependent pre-shared keys. Pre-shared 715 keys used for DTLS negotiation SHOULD be shared only by the pair of 716 end points; otherwise, security could be attacked by diverting 717 messages to another end point holding that pre-shared key. 719 4.5 Composite Security 721 Composite Security (SType = 3) is the combination of DTLS Pairwise 722 Security and [RFC5310]-Based Authentication. On transmission, the 723 DTLS record or records to be sent are secured as specified in Section 724 4.4 then used as the payload for the application of Authentication as 725 specified in Section 4.3. On reception, the [RFC5310]-based 726 authentication is verified first and an error returned if it fails. 727 Then the DTLS record(s) are processed. 729 An advantage of Composite Security is that the payload is 730 authenticated and encrypted with a modern security protocol and, in 731 addition, the RBridge Channel Header and (except in the native case) 732 preceding MAC addresses and Data Label are provided with some 733 authentication. 735 5. Extended RBridge Channel Errors 737 RBridge Channel Header Extension errors are reported like RBridge 738 Channel errors. The ERR field is set to one of the following error 739 codes: 741 ERR Meaning 742 --- --------- 743 6 Unknown or unsupported field value 744 7 Authentication failure 745 8 Error in nested RBridge Channel message 747 Table 5.1 Additional ERR Values 749 5.1 SubERRs under ERR 6 751 If the ERR field is 6, the SubERR field indicates the problematic 752 field or value as shown in the table below. 754 SubERR Meaning (for ERR = 6) 755 ------ --------------------- 756 0 Reserved 757 1 Non-zero RESV4 nibble 758 2 Unsupported SType 759 3 Unsupported PType 760 4 Unknown Key ID 761 5 Unsupported Ethertype with PType = 2 762 6 Unsupported authentication algorithm for SType = 1 764 Table 5.2 SubERR values under ERR 6 766 5.2 Secure Nested RBridge Channel Errors 768 If 769 an extended RBridge Channel message is sent with security and with 770 a payload type (PType) indicating an Ethertyped payload and the 771 Ethertype indicates a nested RBridge Channel message 772 and 773 there is an error in the processing of that nested message that 774 results in a return RBridge Channel message with a non-zero ERR 775 field, 776 then that returned message SHOULD also be nested in an extended 777 RBridge Channel message using the same type of security. In this 778 case, the ERR field in the Extended RBridge Channel envelope is set 779 to 8 indicating that there is a nested error in the message being 780 tunneled back. 782 6. IANA Considerations 784 This section lists IANA Considerations. 786 6.1 Extended RBridge Channel Protocol Number 788 IANA is requested to assign TBD [4 recommended] from the range 789 assigned by Standards Action as the RBridge Channel protocol number 790 to indicate RBridge Channel Header Extension. 792 The added RBridge Channel protocols registry entry on the TRILL 793 Parameters web page is as follows: 795 Protocol Description Reference 796 -------- -------------------------- ---------------- 797 TBD[4] RBridge Channel Extension [this document] 799 6.2 RBridge Channel Protocol Subregistries 801 IANA is requested to create three subregistries under the "RBridge 802 Channel Protocols" registry as in the subsections below. 804 6.2.1 RBridge Channel Error Codes Subregistry 806 IANA is requested to create an "RBridge Channel Error Codes" 807 subregistry under the "RBridge Channel Protocols" registry. The 808 header information is as follows: 810 Registration Procedures: IETF Review 811 References: [RFC7178] [this document] 813 The subregistry is to have columns and entries as follows: 815 Code Meaning Reference 816 ---- ------- --------- 817 [populate rows for codes 0 through 5 from Section 3.2 of 818 [RFC7178] with reference [RFC7178] ] 819 [populate rows for codes 6 through 8 from Table 5.1 of this 820 document with reference [this document] ] 821 9-15 Unassigned 822 16 Reserved 824 6.2.2 Extended RBridge Channel Payload Types Subregistry 826 IANA is requested to create an "Extended RBridge Channel Payload 827 Types" subregistry under the "RBridge Channel Protocols" registry. 828 The header information is as follows: 830 Registration Procedures: IETF Review 831 Reference: [this document] 833 The initial subregistry content is Table 3.1 in this document. 835 6.2.3 Extended RBridge Channel Security Types Subregistry 837 IANA is requested to create an "Extended RBridge Channel Security 838 Types" subregistry under the "RBridge Channel Protocols" registry. 839 The header information is as follows: 841 Registration Procedures: IETF Review 842 Reference: [this document] 844 The initial subregistry content is Table 4.1 in this document. 846 7. Security Considerations 848 The RBridge Channel Header Extension has potentially positive and 849 negative effects on security. 851 On the positive side, it provides optional security that can be used 852 to authenticate and/or encrypt RBridge Channel messages. Some RBridge 853 Channel message payloads, such as BFD [RFC7175], provide their own 854 security but where this is not true, consideration should be given, 855 when specifying an RBridge Channel protocol, to recommending or 856 requiring use of the security features of the RBridge Channel Header 857 Extension. 859 On the negative side, the optional ability to tunnel more payload 860 types and to tunnel them between TRILL switches and to and from end 861 stations can increase risk unless precautions are taken. The 862 processing of decapsulated extended RBridge Channel payloads is not a 863 good place to be liberal in what you accept. This is because the 864 tunneling facility makes it easier for unexpected messages to pop up 865 in unexpected places in a TRILL campus due to accidents or the 866 actions of an adversary. Local policies should generally be strict 867 and only accept payload types required and then only with adequate 868 security for the particular circumstances. 870 See the first paragraph of Section 4 for recommendations on SType 871 usage. 873 See [RFC7457] for Security Considerations of DTLS for security. 875 If IS-IS authentication is not being used, then [RFC5310] keying 876 information would not normally be available but that presumably 877 represents a judgment by the TRILL campus operator that no security 878 is needed. 880 See [RFC7178] for general RBridge Channel Security Considerations and 881 [RFC6325] for general TRILL Security Considerations. 883 Normative References 885 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology 886 -- Telecommunications and information exchange between systems 887 -- Intermediate System to Intermediate System intra-domain 888 routeing information exchange protocol for use in conjunction 889 with the protocol for providing the connectionless-mode network 890 service (ISO 8473)", 2002. 892 [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, 893 RFC 20, DOI 10.17487/RFC0020, October 1969, . 896 [RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 898 March 1997, . 900 [RFC4279] - Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key 901 Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 902 10.17487/RFC4279, December 2005, . 905 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 906 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 907 5310, DOI 10.17487/RFC5310, February 2009, . 910 [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- 911 Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, 912 . 914 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 915 Ghanwani, "Routing Bridges (RBridges): Base Protocol 916 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 917 . 919 [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer 920 Security Version 1.2", RFC 6347, January 2012, . 923 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 924 and D. Dutt, "Transparent Interconnection of Lots of Links 925 (TRILL): Fine-Grained Labeling", RFC 7172, DOI 926 10.17487/RFC7172, May 2014, . 929 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 930 D., and A. Banerjee, "Transparent Interconnection of Lots of 931 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 932 . 934 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 935 Ward, "Transparent Interconnection of Lots of Links (TRILL): 936 RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 937 2014, . 939 [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 940 Scope Link State PDUs (LSPs)", RFC 7356, September 2014, 941 . 943 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 944 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 945 Lots of Links (TRILL): Clarifications, Corrections, and 946 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 947 . 949 Informative References 951 [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash 952 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 953 10.17487/RFC6234, May 2011, . 956 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 957 Interconnection of Lots of Links (TRILL) Protocol Control 958 Protocol", RFC 6361, August 2011 960 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 961 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 962 BCP 141, RFC 7042, October 2013. 964 [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, 965 "Transparent Interconnection of Lots of Links (TRILL): 966 Bidirectional Forwarding Detection (BFD) Support", RFC 7175, 967 May 2014. 969 [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 970 Known Attacks on Transport Layer Security (TLS) and Datagram 971 TLS (DTLS)", RFC 7457, February 2015, . 974 [GroupKey] - D. Eastlake et al, "Group Keying Protocol", draft-ietf- 975 trill-group-keying, work in progress. 977 Appendix Z: Change History 979 RFC Editor: Please delete this Appendix before publication. 981 From -00 to -01 983 1. Fix references for RFCs published, etc. 985 2. Explicitly mention in the Abstract and Introduction that this 986 document updates [RFC7178]. 988 3. Add this Change History Appendix. 990 From -01 to -02 992 1. Remove section on the "Scope" feature as mentioned in 993 http://www.ietf.org/mail-archive/web/trill/current/msg06531.html 995 2. Editorial changes to IANA Considerations to correspond to draft- 996 leiba-cotton-iana-5226bis-11.txt. 998 3. Improvements to the Ethernet frame payload type. 1000 4. Other Editorial changes. 1002 From -02 to -03 1004 1. Update TRILL Header to correspond to [RFC7780]. 1006 2. Remove a few remnants of the "Scope" feature that was removed from 1007 -01 to -02. 1009 3. Substantial changes to and expansion of Section 4 including adding 1010 details of DTLS security. 1012 4. Updates and additions to the References. 1014 5. Other minor editorial changes. 1016 From -03 to -04 1018 1. Add SType for [RFC5310] keying based security that provides 1019 encryption as well as authentication. 1021 2. Editorial improvements and fixes. 1023 From -04 to -05 1025 1. Primary change is collapsing the previous PTypes 2, 3, and 4 for 1026 RBridge Channel message, TRILL Data, and TRILL IS-IS into one by 1027 including the Ethertype. Previous PType 5 is renumbered as 3. 1029 2. Add Channel Tunnel Crypto Suites to IANA Considerations 1031 3. Add some material to Security Considerations, 1033 4. Assorted Editorial changes. 1035 From -05 to -06 1037 Fix editorials found during WG Last Call. 1039 From -06 to -07 1041 Minor editorial changes resulting for Shepherd review. 1043 From -07 to -08 1045 Move group keyed security out of the draft. Simplify and improve 1046 remaining security provisions. 1048 From -08 to -09 1050 1. Updates based on Routing Directorate review. 1052 2. Improvements to specification of pairwise DTLS and significant 1053 other security improvements. 1055 From -09 to -10 1057 Update based on GENART review. 1059 Acknowledgements 1061 The contributions of the following are hereby gratefully 1062 acknowledged: 1064 Jonathan Hardwick, Susan Hares, Gayle Noble, Yaron Sheffer, and 1065 Peter Yee. 1067 The document was prepared in raw nroff. All macros used were defined 1068 within the source file. 1070 Authors' Addresses 1072 Donald E. Eastlake, 3rd 1073 Huawei Technologies 1074 155 Beaver Street 1075 Milford, MA 01757 USA 1077 Phone: +1-508-333-2270 1078 EMail: d3e3e3@gmail.com 1080 Mohammed Umair 1081 IPinfusion 1083 EMail: mohammed.umair2@gmail.com 1085 Yizhou Li 1086 Huawei Technologies 1087 101 Software Avenue, 1088 Nanjing 210012, China 1090 Phone: +86-25-56622310 1091 EMail: liyizhou@huawei.com 1093 Copyright, Disclaimer, and Additional IPR Provisions 1095 Copyright (c) 2016 IETF Trust and the persons identified as the 1096 document authors. All rights reserved. 1098 This document is subject to BCP 78 and the IETF Trust's Legal 1099 Provisions Relating to IETF Documents 1100 (http://trustee.ietf.org/license-info) in effect on the date of 1101 publication of this document. Please review these documents 1102 carefully, as they describe your rights and restrictions with respect 1103 to this document. Code Components extracted from this document must 1104 include Simplified BSD License text as described in Section 4.e of 1105 the Trust Legal Provisions and are provided without warranty as 1106 described in the Simplified BSD License. The definitive version of 1107 an IETF Document is that published by, or under the auspices of, the 1108 IETF. Versions of IETF Documents that are published by third parties, 1109 including those that are translated into other languages, should not 1110 be considered to be definitive versions of IETF Documents. The 1111 definitive version of these Legal Provisions is that published by, or 1112 under the auspices of, the IETF. Versions of these Legal Provisions 1113 that are published by third parties, including those that are 1114 translated into other languages, should not be considered to be 1115 definitive versions of these Legal Provisions. For the avoidance of 1116 doubt, each Contributor to the IETF Standards Process licenses each 1117 Contribution that he or she makes as part of the IETF Standards 1118 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1119 language to the contrary, or terms, conditions or rights that differ 1120 from or are inconsistent with the rights and licenses granted under 1121 RFC 5378, shall have any effect and shall be null and void, whether 1122 published or posted by such Contributor, or included with or in such 1123 Contribution.