| < draft-ietf-trill-channel-tunnel-07.txt | draft-ietf-trill-channel-tunnel-11.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT Donald Eastlake | INTERNET-DRAFT Donald Eastlake | |||
| Updates: 7178 Huawei | Updates: 7178 Huawei | |||
| Intended status: Proposed Standard Mohammed Umair | Intended status: Proposed Standard Mohammed Umair | |||
| IPinfusion | IPinfusion | |||
| Yizhou Li | Yizhou Li | |||
| Huawei | Huawei | |||
| Expires: February 12, 2016 August 13, 2015 | Expires: February 4, 2017 August 5, 2016 | |||
| TRILL: RBridge Channel Tunnel Protocol | TRILL: RBridge Channel Header Extension | |||
| <draft-ietf-trill-channel-tunnel-07.txt> | <draft-ietf-trill-channel-tunnel-11.txt> | |||
| Abstract | Abstract | |||
| The IETF TRILL (Transparent Interconnection of Lots of Links) | The IETF TRILL (Transparent Interconnection of Lots of Links) | |||
| protocol includes an optional mechanism, called RBridge Channel, that | protocol includes an optional mechanism (specified in RFC 7178) | |||
| is specified in RFC 7178, for the transmission of typed messages | called RBridge Channel for the transmission of typed messages between | |||
| between TRILL switches in the same campus and between TRILL switches | TRILL switches in the same campus and the transmission of such | |||
| and end stations on the same link. This document specifies two | messages between TRILL switches and end stations on the same link. | |||
| optional extensions to the RBridge Channel protocol: (1) A standard | This document specifies extensions to the RBridge Channel protocol | |||
| method to tunnel a variety of payload types by encapsulating them in | header to support two features as follows: (1) a standard method to | |||
| an RBridge Channel message; and (2) A method to support security | tunnel payloads whose type can be indicated by Ethertype through | |||
| facilities for RBridge Channel messages. This document updates RFC | encapsulation in RBridge Channel messages; and (2) a method to | |||
| 7178. | support security facilities for RBridge Channel messages. This | |||
| document updates RFC 7178. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Distribution of this document is unlimited. Comments should be sent | Distribution of this document is unlimited. Comments should be sent | |||
| to the authors or the TRILL working group mailing list: | to the authors or the TRILL working group mailing list: | |||
| trill@ietf.org | trill@ietf.org | |||
| skipping to change at page 2, line 5 ¶ | skipping to change at page 2, line 5 ¶ | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft | http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft | |||
| Shadow Directories can be accessed at | Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction............................................3 | 1. Introduction............................................3 | |||
| 1.1 Terminology and Acronyms..............................3 | 1.1 Terminology and Acronyms..............................3 | |||
| 2. Channel Tunnel Packet Format............................5 | 2. RBridge Channel Header Extension Format.................5 | |||
| 3. Channel Tunnel Payload Types............................8 | 3. Extended RBridge Channel Payload Types..................8 | |||
| 3.1 Null Payload...........................................8 | 3.1 Null Payload...........................................8 | |||
| 3.2 Ethertype Without Addresses............................8 | 3.2 Ethertyped Payload.....................................8 | |||
| 3.2.1 Tunneled RBridge Channel Message.....................9 | 3.2.1 RBridge Channel Message as the Payload...............9 | |||
| 3.2.2 Tunneled TRILL Data Packet...........................9 | 3.2.2 TRILL Data Packet as the Payload.....................9 | |||
| 3.2.3 Tunneled TRILL IS-IS Packet.........................10 | 3.2.3 TRILL IS-IS Packet as the Payload...................10 | |||
| 3.3 Ethertype With Addresses..............................11 | 3.3 Ethernet Frame........................................11 | |||
| 4. Security, Keying, and Algorithms.......................14 | 4. Extended RBridge Channel Security......................14 | |||
| 4.1 Basic Security Format.................................14 | 4.1 Derived Keying Material...............................14 | |||
| 4.2 Authentication and Encryption Coverage................15 | 4.2 SType None............................................15 | |||
| 4.3 Derived Keying Material...............................16 | 4.3 [RFC5310]-Based Authentication........................15 | |||
| 4.4 SType None............................................16 | 4.4 DTLS Pairwise Security................................17 | |||
| 4.5 RFC 5310 Based Authentication.........................16 | 4.5 Composite Security....................................18 | |||
| 4.6 DTLS Based Security...................................17 | ||||
| 4.7 RFC 5310 Based Encryption and Authentication..........18 | ||||
| 5. Channel Tunnel Errors..................................20 | 5. Extended RBridge Channel Errors........................19 | |||
| 5.1 SubERRs under ERR 6...................................20 | 5.1 SubERRs...............................................19 | |||
| 5.2 Nested RBridge Channel Errors.........................20 | 5.2 Secure Nested RBridge Channel Errors..................19 | |||
| 6. IANA Considerations....................................21 | 6. IANA Considerations....................................21 | |||
| 6.1 RBridge Channel Protocol Number.......................21 | 6.1 Extended RBridge Channel Protocol Number..............21 | |||
| 6.2 Channel Tunnel Crypto Suites..........................21 | 6.2 RBridge Channel Protocol Subregistries................21 | |||
| 6.2.1 RBridge Channel Error Codes.........................21 | ||||
| 6.2.2 RBridge Channel SubError Codes......................21 | ||||
| 6.2.3 Extended RBridge Channel Payload Types Subregistry..22 | ||||
| 6.2.4 Extended RBridge Channel Security Types Subregistry.22 | ||||
| 7. Security Considerations................................22 | 7. Security Considerations................................23 | |||
| Normative References......................................23 | Normative References......................................24 | |||
| Informative References....................................24 | Informative References....................................25 | |||
| Appendix Z: Change History................................25 | ||||
| Acknowledgements..........................................27 | Appendix Z: Change History................................27 | |||
| Authors' Addresses........................................28 | Acknowledgements..........................................29 | |||
| Authors' Addresses........................................30 | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 1. Introduction | 1. Introduction | |||
| The IETF TRILL base protocol [RFC6325] has been extended with an | The IETF TRILL base protocol [RFC6325] [RFC7780] has been extended | |||
| optional RBridge Channel [RFC7178] facility to support transmission | with the RBridge Channel [RFC7178] facility to support transmission | |||
| of typed messages (for example BFD (Bidirectional Forwarding | of typed messages (for example BFD (Bidirectional Forwarding | |||
| Detection) [RFC7175]) between two TRILL switches (RBridges) in the | Detection) [RFC7175]) between two TRILL switches (RBridges) in the | |||
| same campus and between RBridges and end stations on the same link. | same campus and the transmission of such messages between RBridges | |||
| When sent between RBridges in the same campus, a TRILL Data packet | and end stations on the same link. When sent between RBridges in the | |||
| with a TRILL header is used and the destination RBridge is indicated | same campus, a TRILL Data packet with a TRILL Header is used and the | |||
| by nickname. When sent between a RBridge and an end station on the | destination RBridge is indicated by nickname. When sent between a | |||
| same link in either direction a native RBridge Channel messages | RBridge and an end station on the same link in either direction, a | |||
| [RFC7178] is used with no TRILL header and with the destination port | native RBridge Channel message [RFC7178] is used with no TRILL Header | |||
| or ports indicated by a MAC address. (There is no mechanism to stop | and the destination port or ports are indicated by a MAC address. | |||
| end stations on the same link, from sending native RBridge Channel | (There is no mechanism to stop end stations on the same link from | |||
| messages to each other; however, such use is outside the scope of | sending native RBridge Channel messages to each other; however, such | |||
| this document.) | use is outside the scope of this document.) | |||
| This document updates [RFC7178] and specifies extensions to RBridge | This document updates [RFC7178] and specifies extensions to the | |||
| Channel that provide two additional facilities as listed below. Use | RBridge Channel header that provide two additional facilities as | |||
| of each of these facilities is optional, except that if Channel | follows: | |||
| Tunnel is implemented there are two payload types that MUST be | ||||
| implemented. | ||||
| (1) A standard method to tunnel a variety of payload types by | (1) A standard method to tunnel payloads whose type may be | |||
| encapsulating them in an RBridge Channel message. | indicated by Ethertype through encapsulation in RBridge | |||
| Channel messages. | ||||
| (2) A method to provide security facilities for RBridge Channel | (2) A method to provide security facilities for RBridge Channel | |||
| messages. | messages. Example uses requiring such facilities are the | |||
| security of Pull Directory messages [RFC7067], address flush | ||||
| messages [AddrFlush], and port shutdown messages [rfc6439bis]. | ||||
| Both of the above facilities can be used in the same packet. In case | Use of each of these facilities is optional, except that, as | |||
| of conflict between this document and [RFC7178], this document takes | specified below, if this header extension is implemented there are | |||
| precedence. | two payload types that MUST be implemented. Both of the above | |||
| facilities can be used in the same packet. In case of conflict | ||||
| between this document and [RFC7178], this document takes precedence. | ||||
| 1.1 Terminology and Acronyms | 1.1 Terminology and Acronyms | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| document are to be interpreted as described in [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in | |||
| [RFC2119]. | ||||
| This document uses terminology and acronyms defined in [RFC6325] and | This document uses terminology and acronyms defined in [RFC6325] and | |||
| [RFC7178]. Some of these are repeated below for convenience along | [RFC7178]. Some of these are repeated below for convenience along | |||
| with additional terms and acronyms. | with additional new terms and acronyms. | |||
| AES - Advanced Encryption Standard. | ||||
| CCM - Counter with CBC-MAC (Cypher Block Chaining - Message | ||||
| Authentication Code). | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | application_data - A DTLS [RFC6347] message type. | |||
| CT-CCM - Channel Tunnel CCM. | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Data Label - VLAN or FGL. | Data Label - VLAN or FGL. | |||
| DTLS - Datagram Transport Level Security [RFC6347]. | DTLS - Datagram Transport Level Security [RFC6347]. | |||
| FCS - Frame Check Sequence. | FCS - Frame Check Sequence. | |||
| FGL - Fine Grained Label [RFC7172]. | FGL - Fine Grained Label [RFC7172]. | |||
| HKDF - Hash based Key Derivation Function [RFC5869]. | HKDF - HMAC-based Key Derivation Function [RFC5869]. | |||
| IS-IS - Intermediate System to Intermediate Systems [IS-IS]. | IS-IS - Intermediate System to Intermediate Systems [IS-IS]. | |||
| PDU - Protocol Data Unit. | PDU - Protocol Data Unit. | |||
| MTU - Maximum Transmission Unit. | ||||
| RBridge - An alternative term for a TRILL switch. | RBridge - An alternative term for a TRILL switch. | |||
| SHA - Secure Hash Algorithm [RFC6234]. | SHA - Secure Hash Algorithm [RFC6234]. | |||
| Sz - Campus-wide minimum link MTU [RFC6325] [RFC7780]. | ||||
| TRILL - Transparent Interconnection of Lots of Links or Tunneled | TRILL - Transparent Interconnection of Lots of Links or Tunneled | |||
| Routing in the Link Layer. | Routing in the Link Layer. | |||
| TRILL switch - A device that implements the TRILL protocol | TRILL switch - A device that implements the TRILL protocol | |||
| [RFC6325], sometimes referred to as an RBridge. | [RFC6325] [RFC7780], sometimes referred to as an RBridge. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 2. Channel Tunnel Packet Format | 2. RBridge Channel Header Extension Format | |||
| The general structure of an RBridge Channel message between two TRILL | The general structure of an RBridge Channel message between two TRILL | |||
| switches (RBridges) in the same campus is shown in Figure 2.1 below. | switches (RBridges) in the same campus is shown in Figure 2.1 below. | |||
| The structure of a native RBridge Channel message sent between an | The structure of a native RBridge Channel message sent between an | |||
| RBridge and an end station on the same link, in either direction, is | RBridge and an end station on the same link, in either direction, is | |||
| shown in Figure 2.2 and, compared with the first case, omits the | shown in Figure 2.2 and, compared with the first case, omits the | |||
| TRILL Header, inner Ethernet addresses, and Data Label. A Protocol | TRILL Header, inner Ethernet addresses, and Data Label. A Protocol | |||
| field in the RBridge Channel Header gives the type of RBridge Channel | field in the RBridge Channel Header gives the type of RBridge Channel | |||
| message and indicates how to interpret the Channel Protocol Specific | message and indicates how to interpret the Channel Protocol Specific | |||
| Payload [RFC7178]. | Payload [RFC7178]. | |||
| skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 5 ¶ | |||
| +-----------------------------------+ | +-----------------------------------+ | |||
| | Channel Protocol Specific Payload | | | Channel Protocol Specific Payload | | |||
| +-----------------------------------+ | +-----------------------------------+ | |||
| | FCS | | | FCS | | |||
| +-----------------------------------+ | +-----------------------------------+ | |||
| Figure 2.2 Native RBridge Channel Frame | Figure 2.2 Native RBridge Channel Frame | |||
| The RBridge Channel Header looks like this: | The RBridge Channel Header looks like this: | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | 0x8946 | CHV=0 | Channel Protocol | | | 0x8946 | CHV=0 | Channel Protocol | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | | | | Flags | ERR | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | |||
| / Channel Protocol Specific Data / | / Channel Protocol Specific Data / | |||
| /-+-+-+-+-+- / | /-+-+-+-+-+- / | |||
| Figure 2.3 RBridge Channel Header | Figure 2.3 RBridge Channel Header | |||
| where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel | where 0x8946 is the RBridge Channel Ethertype and CHV is the Channel | |||
| Header Version. This document is based on RBridge Channel version | Header Version. This document is based on RBridge Channel version | |||
| zero. | zero. | |||
| The extensions specified herein are in the form of an RBridge Channel | The header extensions specified herein are in the form of an RBridge | |||
| protocol, the Channel Tunnel Protocol. Figure 2.4 below expands the | Channel protocol, the Extended RBridge Channel Protocol. Figure 2.4 | |||
| RBridge Channel Header and Protocol Specific Payload above for the | below expands the RBridge Channel Header and Protocol Specific | |||
| case of the Channel Tunnel Protocol. | Payload above for the case where the header extension is present. | |||
| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
| 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 | 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 | |||
| RBridge Channel Header: | RBridge Channel Header: | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | 0x8946 | CHV=0 | Tunnel Protocol =TBD | | | 0x8946 | CHV=0 | Channel Protocol=[TBD]| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | | | Flags | ERR | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Channel Tunnel Protocol Specific: | SubERR| RESV4 | SType | PType | | Header Extension Specific: | SubERR| RESV4 | SType | PType | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Security Information, variable length (0 length if SType = 0) / | | Security Information, variable length (0 length if SType = 0) / | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | |||
| | Tunneled Data, variable length | | Tunneled Data, variable length | |||
| | ... | | ... | |||
| Figure 2.4 Channel Tunnel Header Structure | Figure 2.4 RBridge Channel Header Extension Structure | |||
| The RBridge Channel Header field specific to the RBridge Channel | The RBridge Channel Header Protocol field is used to indicate that | |||
| Tunnel Protocol is the Protocol field. Its contents MUST be the value | the header extension is present. Its contents MUST be the value | |||
| allocated for this purpose (see Section 6). | allocated for this purpose (see Section 6). The use of an RBridge | |||
| Channel protocol to indicate extension makes it easy to determine if | ||||
| a remote RBridge in the campus supports extension since RBridges | ||||
| advertise in their LSP which such protocols they support. | ||||
| The RBridge Channel Tunnel Protocol Specific Data fields are as | The Extended RBridge Channel Protocol Specific Data fields are as | |||
| follows: | follows: | |||
| SubERR: This field provides further details when a Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| error is indicated in the RBridge Channel ERR field. If ERR is | ||||
| zero, then SubERR MUST be sent as zero and ignored on receipt. | ||||
| See Section 5. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | SubERR: This field provides further details when an error is | |||
| indicated in the RBridge Channel ERR field. If ERR is zero, | ||||
| then SubERR MUST be sent as zero and ignored on receipt. See | ||||
| Section 5. | ||||
| RESV4: This field MUST be sent as zero. If non-zero when received, | RESV4: This field MUST be sent as zero. If non-zero when received, | |||
| this is an error condition (see Section 5). | this is an error condition (see Section 5). | |||
| SType: This field describes the type of security information and | SType: This field describes the type of security information and | |||
| features, including keying material, being used or provided by | features, including keying material, being used or provided by | |||
| the Channel Tunnel packet. See Section 4. | the extended RBridge Channel message. See Section 4. | |||
| PType: Payload type. This describes the tunneled data. See Section | PType: Payload type. This describes the tunneled data. See Section | |||
| 3 below. | 3 below. | |||
| Security Information: Variable length information. Length is zero | Security Information: Variable length information. Length is zero | |||
| if SType is zero. See Section 4. | if SType is zero. See Section 4. | |||
| The Channel Tunnel protocol is integrated with the RBridge Channel | The RBridge Channel Header Extension is integrated with the RBridge | |||
| facility. Channel Tunnel errors are reported as if they were RBridge | Channel facility. Extension errors are reported as if they were | |||
| Channel errors, using newly allocated code points in the ERR field of | RBridge Channel errors, using newly allocated code points in the ERR | |||
| the RBridge Channel Header supplemented by the SubERR field. | field of the RBridge Channel Header supplemented by the SubERR field. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 3. Channel Tunnel Payload Types | 3. Extended RBridge Channel Payload Types | |||
| The Channel Tunnel Protocol can carry a variety of payloads as | The Extended RBridge Channel Protocol can carry a variety of payloads | |||
| indicated by the PType field. Values are shown in the table below | as indicated by the PType (Payload Type) field. Values are shown in | |||
| with further explanation after the table. | the table below with further explanation after the table (see also | |||
| Section 6.2.2). | ||||
| PType Section Description | PType Description Reference | |||
| ----- ------- ----------- | ----- ----------- --------- | |||
| 0 Reserved | 0 Reserved | |||
| 1 3.1 Null | 1 Null Section 3.1 of [this doc] | |||
| 2 3.2 Ethertype Without Addresses | 2 Ethertyped Payload Section 3.2 of [this doc] | |||
| 3 3.3 Ethertype With Addresses | 3 Ethernet Frame Section 3.3 of [this doc] | |||
| 4-14 (Available for assignment by IETF Review) | 4-14 Unassigned | |||
| 15 Reserved | 15 Reserved | |||
| Table 1. Payload Type Values | Table 3.1 Payload Type Values | |||
| While implementation of the Channel Tunnel protocol is optional, if | While implementation of the RBridge Channel Header Extension is | |||
| it is implemented PType 1 (Null) and PType 2 (Ethertype without | optional, if it is implemented PType 1 (Null) MUST be implemented and | |||
| addresses) with the RBridge Channel Ethertype MUST be implemented. | PType 2 (Ethertyped Payload) with the RBridge Channel Ethertype MUST | |||
| PType 2 for any Ethertypes other than the RBridge Channel Ethertype | be implemented. PType 2 for any Ethertypes other than the RBridge | |||
| MAY be implemented. PType 3 MAY be implemented. | Channel Ethertype MAY be implemented. PType 3 MAY be implemented. | |||
| The processing of any particular Channel Protocol message and its | The processing of any particular extended header RBridge Channel | |||
| payload depends on meeting local security and other policy at the | message and its payload depends on meeting local security and other | |||
| destination TRILL switch or end station. | policy at the destination TRILL switch or end station. | |||
| 3.1 Null Payload | 3.1 Null Payload | |||
| The Null payload type (PType = 1) is intended to be used for testing | The Null payload type (PType = 1) is intended to be used for testing | |||
| or for messages such as key negotiation or the like. It indicates | or for messages such as key negotiation or the like where only | |||
| that there is no payload. Any data after the Security Information | security information is present. It indicates that there is no user | |||
| field is ignored. If the Channel Tunnel feature is implemented, Null | data payload. Any tunneled user data after the Security Information | |||
| Payload MUST be supported. Any particular use of the Null Payload | field is ignored. If the RBridge Channel Header Extension is | |||
| should specify what VLAN or priority should be used when relevant. | implemented, the Null Payload MUST be supported in the sense that an | |||
| "Unsupported PType" error is not returned (see Section 5). Any | ||||
| particular use of the Null Payload should specify what VLAN or FGL | ||||
| and what priority should be used in the inner Data Label of the | ||||
| RBridge Channel message (or in an outer VLAN tag for the native | ||||
| RBridge Channel message case) when those values are relevant. | ||||
| 3.2 Ethertype Without Addresses | 3.2 Ethertyped Payload | |||
| A PType of 2 indicates that the payload of the Channel Tunnel message | A PType of 2 indicates that the payload (tunneled data) of the | |||
| begins with an Ethertype. A TRILL switch supporting the Channel | extended RBridge Channel message begins with an Ethertype. A TRILL | |||
| Tunnel RBridge Channel protocol MUST support a PType of 2 with a | ||||
| payload beginning with the RBridge Channel Ethertype as describe in | ||||
| Section 3.2.1. Other Ethertypes, including the TRILL and L2-IS-IS | ||||
| Ethertype as described in Section 3.2.2 and 3.2.3, MAY be supported. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 3.2.1 Tunneled RBridge Channel Message | switch supporting the RBridge Channel Header Extension MUST support a | |||
| PType of 2 with a payload beginning with the RBridge Channel | ||||
| Ethertype as described in Section 3.2.1. Other Ethertypes, including | ||||
| the TRILL and L2-IS-IS Ethertypes as described in Section 3.2.2 and | ||||
| 3.2.3, MAY be supported. | ||||
| A PType of 2 with an initial RBridge Channel Ethertype indicates an | 3.2.1 RBridge Channel Message as the Payload | |||
| encapsulated RBridge Channel message payload. A typical reason for | ||||
| sending an RBridge Channel message inside a Channel Tunnel message is | ||||
| to provide security services, such as authentication or encryption. | ||||
| This payload type looks like the following: | A PType of 2 whose payload has an initial RBridge Channel Ethertype | |||
| indicates an encapsulated RBridge Channel message. A typical reason | ||||
| for sending an RBridge Channel message inside an extended RBridge | ||||
| Channel message is to provide security services, such as | ||||
| authentication or encryption, for the encapsulated message. | ||||
| This RBridge Channel message type looks like the following: | ||||
| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | | | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=[TBD]| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | SubERR| RESV4 | SType | 0x2 | | | Flags | ERR | SubERR| RESV4 | SType | 0x2 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Security Information, variable length (0 length if SType = 0) / | / Security Information, variable length (0 length if SType = 0) / | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol| | | RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | | | | Flags | ERR | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |||
| | Nested Channel Protocol Specific Data ... / | | Nested Channel Protocol Specific Data ... / | |||
| / / | / / | |||
| Figure 3.1 Tunneled RBridge Channel Message Structure | Figure 3.1 Message Structure with RBridge Channel Payload | |||
| 3.2.2 Tunneled TRILL Data Packet | 3.2.2 TRILL Data Packet as the Payload | |||
| A PType of 2 and an initial TRILL Ethertype indicates that the | A PType of 2 whose payload has an initial TRILL Ethertype indicates | |||
| payload of the Tunnel protocol message is an encapsulated TRILL Data | an encapsulated TRILL Data packet as shown in the figure below. If | |||
| packet as shown in the figure below. If this Ethertype is supported | this Ethertype is supported for PType = 2 and the message meets local | |||
| for PType = 2 and the message meets local policy for acceptance, the | policy for acceptance, the TRILL Data packet is handled as if it had | |||
| tunneled TRILL Data packet is handled as if it had been received by | been received by the destination TRILL switch on the port where the | |||
| the destination TRILL switch on the port where the Channel Tunnel | Extended RBridge Channel message was received. | |||
| message was received. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | | | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=[TBD]| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | SubERR| RESV4 | SType | 0x2 | | | Flags | ERR | SubERR| RESV4 | SType | 0x2 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Security Information, variable length (0 length if SType = 0) / | / Security Information, variable length (0 length if SType = 0) / | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count | | | TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Egress Nickname | Ingress Nickname | | | Egress Nickname | Ingress Nickname | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Optional Flags Word | | / Optional Flags Word / | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Inner.MacDA | | | Inner.MacDA | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Inner.MacDA continued | Inner.MacSA | | | Inner.MacDA continued | Inner.MacSA | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Inner.MacSA (cont.) | | | Inner.MacSA (cont.) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Inner Data Label (2 or 4 bytes) | | Inner Data Label (2 or 4 bytes) | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | |||
| | TRILL Data Packet payload | | TRILL Data Packet payload | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | |||
| Figure 3.2 Nested TRILL Data Packet Channel Tunnel Structure | Figure 3.2 Message Structure with TRILL Data Packet Payload | |||
| The optional flags word is only present if the F bit in the TRILL | The optional flags word is only present if the F bit in the TRILL | |||
| Header is one [rfc7180bis]. | Header is one [RFC7780]. | |||
| 3.2.3 Tunneled TRILL IS-IS Packet | 3.2.3 TRILL IS-IS Packet as the Payload | |||
| A PType of 2 and an initial L2-IS-IS Ethertype indicates that the | A PType of 2 and an initial L2-IS-IS Ethertype indicates that the | |||
| payload of the Tunnel protocol message is an encapsulated TRILL IS-IS | payload of the Extended RBridge Channel protocol message is an | |||
| PDU packet as shown in figure 3.3. If this Ethertype is supported, | encapsulated TRILL IS-IS PDU as shown in Figure 3.3. If this | |||
| the tunneled TRILL IS-IS packet is processed by the destination | Ethertype is supported for PType = 2, the tunneled TRILL IS-IS packet | |||
| RBridge if it meets local policy. One possible use is to expedite the | is processed by the destination RBridge if it meets local policy. One | |||
| receipt of a link state PDU (LSP) by some TRILL switch or switches | possible use is to expedite the receipt of a link state PDU (LSP) by | |||
| with an immediate requirement for the link state information. Since | some TRILL switch or switches with an immediate requirement for the | |||
| they can be transmitted directly on the link, a link local IS-IS PDU | link state information. A link local IS-IS PDU (Hello, CSNP, or PSNP | |||
| (Hello, CSNP, or PSNP [IS-IS]; MTU-probe or MTU-ack [RFC7176]; or | [IS-IS]; MTU-probe or MTU-ack [RFC7176]; or circuit scoped FS-LSP, | |||
| circuit scoped FS-LSP, FS-CSNP or FS-PSNP [RFC7356]) would not | FS-CSNP or FS-PSNP [RFC7356]) would not normally be sent via this | |||
| normally be sent via this Channel Tunnel method except possibly to | Extended RBridge Channel method except possibly to encrypt it since | |||
| encrypt it. | such PDUs can just be transmitted on the link and do not normally | |||
| need RBridge Channel handling. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RBridge-Channel (0x8946) | CHV=0 | Tunnel Protocol = TBD | | | RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=[TBD]| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | SubERR| RESV4 | SType | 0x2 | | | Flags | ERR | SubERR| RESV4 | SType | 0x2 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Security Information, variable length (0 length if SType = 0) / | / Security Information, variable length (0 length if SType = 0) / | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | |||
| | L2-IS-IS (0x22F4) | 0x83 | | | L2-IS-IS (0x22F4) | 0x83 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | rest of IS-IS PDU | | rest of IS-IS PDU | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-... | |||
| Figure 3.3 Tunneled TRILL IS-IS Packet Structure | Figure 3.3 Message Structure with TRILL IS-IS Packet Payload | |||
| 3.3 Ethertype With Addresses | 3.3 Ethernet Frame | |||
| If PType is 3, the Tunnel Protocol payload is an Ethernet frame as | If PType is 3, the extended RBridge Channel payload is an Ethernet | |||
| might be received from or sent to an end station except that the | frame as might be received from or sent to an end station except that | |||
| tunneled Ethernet frame's FCS is omitted, as shown in Figure 3.4. | the encapsulated Ethernet frame's FCS is omitted, as shown in Figure | |||
| (There is still an overall FCS if the RBridge Channel message is | 3.4. (There is still an overall final FCS if the RBridge Channel | |||
| being sent on an Ethernet link.) If this PType is implemented and the | message is being sent on an Ethernet link.) If this PType is | |||
| message meets local policy, the tunneled frame is handled as if it | implemented and the message meets local policy, the encapsulated | |||
| had been received on the port on which the Channel Tunnel message was | frame is handled as if it had been received on the port on which the | |||
| received. | Extended RBridge Channel message was received. | |||
| The priority of the RBridge Channel message can be copied from the | The priority of the RBridge Channel message can be copied from the | |||
| Ethernet frame VLAN tag, if one is present, except that priority 7 | Ethernet frame VLAN tag, if one is present, except that priority 7 | |||
| SHOULD only be used for messages critical to adjacency and priority 6 | SHOULD only be used for messages critical to establishing or | |||
| SHOULD only be used for other important control messages. | maintaining adjacency and priority 6 SHOULD only be used for other | |||
| important control messages. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RBridge-Channel (0x8946) | 0x0 | Tunnel Protocol = TBD | | | RBridge-Channel (0x8946) | 0x0 | Channel Protocol=[TBD]| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | SubERR| RESV4 | SType | 0x2 | | | Flags | ERR | SubERR| RESV4 | SType | 0x3 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Security Information, variable length (0 length if SType = 0) / | / Security Information, variable length (0 length if SType = 0) / | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | MacDA | | | MacDA | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | MacDA (cont.) | MacSA | | | MacDA (cont.) | MacSA | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | MacSA (cont.) | | | MacSA (cont.) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Any Ethernet frame tagging... | | Any Ethernet frame tagging... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=+-+-... | ||||
| | Ethernet frame payload... | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | |||
| | Ethernet frame payload... | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | ||||
| Figure 3.4 Ethernet Frame Channel Tunnel Structure | Figure 3.4 Message Structure with Ethernet Frame Payload | |||
| In the case of a non-Ethernet link, such as a PPP (Point-to-Point | In the case of a non-Ethernet link, such as a PPP (Point-to-Point | |||
| Protocol) link [RFC6361], the ports on the link are considered to | Protocol) link [RFC6361], the ports on the link are considered to | |||
| have link local synthetic 48-bit MAC addresses constructed as | have link-local synthetic 48-bit MAC addresses constructed as | |||
| described below. These constructed addresses MAY be used as a MacSA. | described below. Such a constructed address MAY be used as a MacSA. | |||
| If the RBridge Channel message is link local, the source TRILL switch | If the RBridge Channel message is individually addressed to a link | |||
| will have the information to construct such a MAC address for the | local port, the source TRILL switch will have the information to | |||
| destination TRILL switch port and that MAC address MAY be used as the | construct such a MAC address for the destination TRILL switch port | |||
| MacDA. By the use of such a MacSA and either such a unicast MacDA or | and that MAC address MAY be used as the MacDA. By the use of such a | |||
| a group addressed MacDA, an Ethernet frame can be sent between two | MacSA and either such a unicast MacDA or a group addressed MacDA, an | |||
| TRILL switch ports connected by a non-Ethernet link. | Ethernet frame can be sent between two TRILL switch ports connected | |||
| by a non-Ethernet link. | ||||
| These synthetic TRILL switch port MAC addresses for non-Ethernet | These synthetic TRILL switch port MAC addresses for non-Ethernet | |||
| ports are constructed as follows: 0xFEFF, the nickname of the TRILL | ports are constructed as follows: 0xFEFF, the nickname of the TRILL | |||
| switch used in TRILL Hellos sent on that port, and the Port ID that | switch used in TRILL Hellos sent on that port, and the Port ID that | |||
| the TRILL switch has assigned to that port, as shown in Figure 3.5. | the TRILL switch has assigned to that port, as shown in Figure 3.5. | |||
| (Both the nickname and Port ID of the port on which a TRILL Hello is | (Both the Port ID of the port on which a TRILL Hello is sent and the | |||
| sent appear in the Special VLANs and Flags sub-TLV [RFC7176] in that | nickname of the sending TRILL switch appear in the Special VLANs and | |||
| Hello.) The resulting MAC address has the Local bit on and the Group | Flags sub-TLV [RFC7176] in TRILL IS-IS Hellos.) The resulting MAC | |||
| bit off [RFC7042]. Since end stations are connected to TRILL switches | address has the Local bit on and the Group bit off [RFC7042]. | |||
| over Ethernet, there will be no end stations on a non-Ethernet link | However, since there will be no Ethernet end stations on a non- | |||
| in a TRILL campus. Thus such synthetic MAC addresses cannot conflict | Ethernet link in a TRILL campus, such synthetic MAC addresses cannot | |||
| on the link with a real Ethernet port address. | conflict on the link with a real Ethernet port address regardless of | |||
| their value. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | 0xFEFF | Nickname | | | 0xFEFF | Nickname | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Port ID | | | Port ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 3.5 Synthetic MAC Address | Figure 3.5 Synthetic MAC Address | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 4. Security, Keying, and Algorithms | ||||
| The following table gives the initial assigned values of the SType | ||||
| field and their meaning. | ||||
| SType Section Meaning | ||||
| ----- ------- ------- | ||||
| 0 4.4 None | ||||
| 1 4.5 [RFC5310] Based Authentication | ||||
| 2 4.6 DTLS Based Security | ||||
| 3 4.7 [RFC5310] Based Encryption and Authentication | ||||
| 4-14 Available for assignment by IETF Review | ||||
| 15 Reserved | ||||
| Table 3. SType Values | ||||
| 4.1 Basic Security Format | ||||
| When SType is zero, there is no Security Information after the | ||||
| Channel Tunnel header and before the payload. For all SType values | ||||
| except zero, the Security Information starts with a byte of flag bits | ||||
| and a byte of remaining length as follows: | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | ||||
| |A|E| RESV | Size | More Info | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | ||||
| Figure 4.1 Security Information Format | ||||
| The fields are as follows: | ||||
| A: Zero if authentication is not being provided. One if it is. | ||||
| E: Zero if encryption is not being provided. One if it is. | 4. Extended RBridge Channel Security | |||
| RESV: Six reserved bits that MUST be sent as zero and ignored on | Table 4.1 below gives the assigned values of the SType (Security | |||
| receipt. In the future, meanings may be assigned to these bits and | Type) field and their meaning. Use of DTLS Pairwise Security (SType = | |||
| those meanings may differ for different STypes. | 2) or Composite Security (SType = 3) is RECOMMENDED. | |||
| Size: The number of bytes, as an unsigned integer, of More Info in | While [RFC5310]-based authentication is also specified and can be | |||
| the Security Information after the Size byte itself. Thus the | used for both pairwise and multi-destination traffic, it provides | |||
| maximum possible length of Security Information is 257 bytes for a | only authentication and is not considered to meet current security | |||
| Size of 255 plus the flags and Size bytes. | standards. For example, it does not provide for key negotiation; | |||
| thus, its use is NOT RECOMMENDED. | ||||
| More Info: Additional Security Information of length Size. Contents | The Extended RBridge Channel DTLS-based security specified in Section | |||
| depends on the SType. | 4.4 and the Composite Security specified in Section 4.5 below are | |||
| intended for pairwise (known unicast) use. That is, the case where | ||||
| the M bit in the TRILL Header is zero and any Outer.MacDA is | ||||
| individually addressed. | ||||
| The A and E bits are intended as hints and to assist in debugging. | Multi-destination Extended RBridge Channel packets would be those | |||
| with the M bit in the TRILL Header set to one or, in the native | ||||
| RBridge Channel case, the Outer.MacDA would be group addressed. The | ||||
| DTLS Pairwise Security and Composite Security STypes can also be used | ||||
| in the multi-destination case by serially unicasting the messages to | ||||
| all data-accessible RBridges (or stations in the native RBridge | ||||
| Channel case) in the recipient group. For TRILL Data packets, that | ||||
| group is specified by the Data Label; for native frames, the group is | ||||
| specified by the groupcast destination MAC address. It is intended to | ||||
| specify a true group keyed SType to secure multi-destination packets | ||||
| in a separate document [GroupKey]. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | SType Description Reference | |||
| ----- ----------- --------- | ||||
| 0 None Section 4.2 of [this doc] | ||||
| 1 [RFC5310]-Based Authentication Section 4.3 of [this doc] | ||||
| 2 DTLS Pairwise Security Section 4.4 of [this doc] | ||||
| 3 Composite Security Section 4.5 of [this doc] | ||||
| 4-14 Unassigned | ||||
| 15 Reserved | ||||
| They are not guaranteed to be correct. They can be interpreted as | Table 4.1 SType Values | |||
| follows: | ||||
| A E Comments | 4.1 Derived Keying Material | |||
| ----- ---------- | ||||
| 0 0 Neither authentication nor encryption is being provided. | In some cases, it is possible to use material derived from [RFC5310] | |||
| IS-IS keying material as an element of Extended RBridge Channel | ||||
| security. It is assumed that the IS-IS keying material is of high | ||||
| quality. The material actually used is derived from the IS-IS keying | ||||
| material as follows: | ||||
| 1 0 Authentication only. The payload should be parsable by a | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| security ignorant receiver if it understands the payload | ||||
| format. The Size field permits skipping the More Info | ||||
| field. | ||||
| 0 1 Encryption only, perhaps some form of opportunistic | Derived Material = | |||
| security [RFC7435]. | HKDF-Expand-SHA256 ( IS-IS-key, "Extended Channel" | 0x0S, L ) | |||
| 1 1 Authentication and Encryption. | where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is | |||
| as in [RFC6234], IS-IS-key is the input IS-IS keying material, | ||||
| "Extended Channel" is the 16-character ASCII [RFC20] string indicated | ||||
| without any leading length byte or trailing zero byte, 0x0S is a | ||||
| single byte where S is the SType for which this key derivation is | ||||
| being used and the upper nibble is zero, and L is the length of the | ||||
| output-derived material needed. | ||||
| 4.2 Authentication and Encryption Coverage | Whenever IS-IS keying material is being used as above, the underlying | |||
| [RFC5310] keying material might expire or be invalidated. At the time | ||||
| of or before such expiration or invalidation, the use of the Derived | ||||
| Material from the IS-IS keying material MUST cease. Continued | ||||
| security MAY use new derived material from currently valid [RFC5310] | ||||
| keying material. | ||||
| Authentication in the RBridge Channel case (see Figure 2.1) is | 4.2 SType None | |||
| computed across the inner Ethernet Addresses, Data Label, relevant | ||||
| Channel Tunnel header information, and the payload. | ||||
| To be more precise, the covered area starts with the byte immediately | No security services are being invoked. The length of the Security | |||
| after the TRILL Header ingress nickname unless the optional flag word | Information field (see Figure 2.4) is zero. | |||
| [rfc7180bis] is present. If the optional flag word is present, then | ||||
| the covered area starts after that flag word. In either case, it | ||||
| extends to just before the TRILL Data packet link trailer. For | ||||
| example, for an Ethernet packet it would extend to just before the | ||||
| FCS. If an authentication value is included in the More Info field | ||||
| shown in Section 4.1, it is treated as zero when authentication is | ||||
| calculated. If an authentication value is included in a payload after | ||||
| the security information, it is calculated as provided by the SType | ||||
| and security algorithms in use. | ||||
| Authentication in the native RBridge Channel case (see Figure 2.2), | 4.3 [RFC5310]-Based Authentication | |||
| is as specified in the above paragraph except that it starts with the | ||||
| RBridge Channel Ethertype, since there are no TRILL Header, inner | ||||
| Ethernet address, or inner Data Label. | ||||
| If encryption is provided, it covers the payload from right after the | This SType provides security for Extended RBridge Channel messages | |||
| Channel Tunnel header Security Information through to just before the | similar to that provided for [IS-IS] PDUs by the [IS-IS] | |||
| TRILL Data packet link trailer. | Authentication TLV. The Security Information (see Figure 2.4) is as | |||
| shown in Figure 4.1. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | 1 1 1 1 1 1 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | RESV | Size | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Key ID | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | | | ||||
| + | ||||
| | Authentication Data (Variable) | ||||
| + | ||||
| | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-... | ||||
| 4.3 Derived Keying Material | Figure 4.1 SType 1 Security Information | |||
| In some cases, it is possible to use keying material derived from | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| [RFC5310] IS-IS keying material. In such cases, the More Info field | ||||
| shown in Figure 4.1 includes a two byte Key ID to identify the IS-IS | ||||
| keying material. The keying material actually used in Channel Tunnel | ||||
| security is derived from the IS-IS keying material as follows: | ||||
| HKDF-Expand-SHA256 ( IS-IS-key, "Channel Tunnel" | 0x0S, L ) | o RESV: Four bits that MUST be sent as zero and ignored on receipt. | |||
| where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is | o Size: Set to 2 + the size of Authentication Data in bytes. | |||
| as in [RFC6234], IS-IS-key is the input keying material, "Channel | ||||
| Tunnel" is the 14-character [RFC20] string indicated, 0x0S is a | ||||
| single byte where S is the SType for which this key derivation is | ||||
| being used, and L is the length of output keying material needed. | ||||
| 4.4 SType None | o Key ID: specifies the keying value and authentication algorithm | |||
| that the Key ID specifies for TRILL IS-IS LSP [RFC5310] | ||||
| Authentication TLVs. The keying material actually used is always | ||||
| derived as shown in Section 4.1. | ||||
| No security services are being invoked. The length of the Security | o Authentication Data: The authentication data produced by the | |||
| Information field (see Figure 2.4) is zero. | derived key and algorithm associated with the Key ID acting on the | |||
| part of the TRILL Data packet shown. Length of the authentication | ||||
| data depends on the algorithm. The authentication value is | ||||
| included in the security information field and is treated as zero | ||||
| when authentication is calculated. | ||||
| 4.5 RFC 5310 Based Authentication | As show in Figure 4.2, the area covered by this authentication starts | |||
| with the byte immediately after the TRILL Header optional Flag Word | ||||
| if it is present. If the Flag Word is not present, it starts after | ||||
| the TRILL Header Ingress Nickname. In either case, it extends to just | ||||
| before the TRILL Data packet link trailer. For example, for an | ||||
| Ethernet packet it would extend to just before the FCS. | ||||
| The Security Information (see Figure 2.4) is the flags and Size bytes | +-----------------------------+ | |||
| specified in Section 4.1 with the value of the [RFC5310] Key ID and | | Link Header | | |||
| Authentication Data as shown in Figure 4.2. | +-----------------------------+ | |||
| | TRILL Header | | ||||
| | (plus optional flag word) | | ||||
| +-----------------------------+ ^ | ||||
| | Inner Ethernet Addresses | | | ||||
| +-----------------------------+ . | ||||
| | Data Label (VLAN or FGL) | | | ||||
| +-----------------------------+ . | ||||
| | RBridge Channel Header | | <-authentication | ||||
| +-----------------------------+ . | ||||
| | Extended Channel Header | | | ||||
| | (plus Security Information)| . | ||||
| +-----------------------------+ | | ||||
| | Payload | . | ||||
| +-----------------------------+ v | ||||
| | Link Trailer | | ||||
| +-----------------------------+ | ||||
| 1 1 1 1 1 1 | Figure 4.2. SType 1 Authentication Coverage | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |1|0| RESV | Size | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Key ID | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | | | ||||
| + | ||||
| | Authentication Data (Variable) | ||||
| + | ||||
| | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-... | ||||
| Figure 4.2 SType 1 Security Information | In the native RBridge Channel case this authentication coverage is as | |||
| specified in the above paragraph except that it starts with the | ||||
| RBridge Channel Ethertype, since there is no TRILL Header, inner | ||||
| Ethernet addresses, or inner Data Label (see Figure 4.3). | ||||
| o RESV: Six bits that MUST be sent as zero and ignored or receipt. | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| o Size: Set to 2 + the size of Authentication Data in bytes. | +-----------------------------+ | |||
| | Ethernet Header | | ||||
| +-----------------------------+ ^ | ||||
| | RBridge Channel Header | | | ||||
| +-----------------------------+ . | ||||
| | Extended Channel Header | | <-authentication | ||||
| | (plus Security Information)| . | ||||
| +-----------------------------+ | | ||||
| | Payload | . | ||||
| +-----------------------------+ v | ||||
| | Ethernet Trailer | | ||||
| +-----------------------------+ | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | Figure 4.3. Native SType 1 Authentication Coverage | |||
| o Key ID: specifies the same keying value and authentication | While RBridges, which are IS-IS routers, can reasonably be expected | |||
| algorithm that the Key ID specifies for TRILL IS-IS LSP [RFC5310] | to hold [RFC5310] keying so that this SType can be used for RBridge | |||
| Authentication TLVs. The keying material actually used is derived | Channel messages, how end stations might come to hold [RFC5310] | |||
| as shown in Section 4.3. | keying is beyond the scope of this document. Thus this SType might | |||
| not be applicable to native RBridge Channel messages. | ||||
| o Authentication Data: The authentication data produced by the key | 4.4 DTLS Pairwise Security | |||
| and algorithm associated with the Key ID acting on the packet as | ||||
| specified in Section 4.2. Length of the authentication data | ||||
| depends on the algorithm. | ||||
| 4.6 DTLS Based Security | DTLS [RFC6347] supports key negotiation and provides both encryption | |||
| and authentication. The RBridge Channel Extended Header DTLS Pairwise | ||||
| SType uses a negotiated DTLS version that MUST NOT be less than 1.2. | ||||
| DTLS supports key negotiation and provides both encryption and | When DTLS pairwise security is used, the entire payload of the | |||
| authentication. This optional SType in Channel Tunnel uses DTLS 1.2 | Extended RBridge Channel packet, starting just after the null | |||
| [RFC6347]. It is intended for pairwise use. The presumption is that | Security Information and ending just before the link trailer, is one | |||
| in the RBridge Channel case (Figure 2.1) the M bit in the TRILL | or more DTLS records [RFC6347]. As specified in [RFC6347], DTLS | |||
| Header would be zero and in the native RBridge Channel case (Figure | records MUST be limited by the path MTU, in this case so each record | |||
| 2.2), the Outer.MacDA would be individually addressed. | fits entirely within a single Extended RBridge Channel message. A | |||
| minimum path MTU can be determined from the TRILL campus minimum MTU | ||||
| Sz, which will not be less than 1470 bytes, by allowing for the TRILL | ||||
| Data packet, extended RBridge Channel, and DTLS framing overhead. | ||||
| With this SType, the security information between the extended | ||||
| RBridge Channel header and the payload is null because all the | ||||
| security information is in the payload area. | ||||
| TRILL switches that implement the Channel Tunnel DTLS SType SHOULD | The DTLS Pairwise keying is set up between a pair of RBridges | |||
| support the use of certificates for DTLS. In this case the Size field | independent of Data Label using messages of a priority configurable | |||
| shown in Section 4.1 MUST be zero and the Security Information is as | at the RBridge level which defaults to priority 6. DTLS message types | |||
| shown in Figure 4.3. | other than application_data can be the payload of an extended RBridge | |||
| Channel message with a TRILL Header using any Data Label and, for | ||||
| such DTLS message types, the PType in the RBridge Channel Header | ||||
| Extension is ignored. | ||||
| Also, if they support certificates, they MUST support the following | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| algorithm: | ||||
| o TLS_RSA_WITH_AES_128_CBC_SHA256 [RFC5246] | Actual application_data sent within such a message using this SType | |||
| SHOULD use the Data Label and priority as specified for that | ||||
| application_data. In this case, the PType value in the RBridge | ||||
| Channel Header Extension applies to the decrypted application_data. | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TRILL switches that implement the extended RBridge Channel DTLS | |||
| |1|1| RESV | 0 | | Pairwise SType SHOULD support the use of certificates for DTLS but | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | certificate size may be limited by the DTLS requirement that each | |||
| record fit within a single message. Appropriate certificate contents | ||||
| is out of scope for this document. | ||||
| Figure 4.3 DTLS Cert or Special Pre-shared Key Security Information | TRILL switches that support the extended RBridge Channel DTLS | |||
| Pairwise SType MUST support the use of pre-shared keys. If the | ||||
| psk_identity (see [RFC4279]) is two bytes, it is interpreted as a | ||||
| [RFC5310] Key ID and the value derived as shown in Section 4.1 from | ||||
| that key is used as a pre-shared key for DTLS negotiation. A | ||||
| psk_identity with a length other than two bytes MAY be used to | ||||
| indicate other implementation dependent pre-shared keys. Pre-shared | ||||
| keys used for DTLS negotiation SHOULD be shared only by the pair of | ||||
| end points; otherwise, security could be attacked by diverting | ||||
| messages to another end point holding that pre-shared key. | ||||
| TRILL switches that support the Channel Tunnel DTLS SType MUST | 4.5 Composite Security | |||
| support the use of pre-shared keys for DTLS. The Size field as shown | ||||
| in Section 4.1 MUST be either zero or 2. If Size is zero as shown in | ||||
| Figure 4.3, a pre-shared key specifically associated with Channel | ||||
| Tunnel DTLS is used. If Size is 2 as shown in Figure 4.4, a two byte | ||||
| [RFC5310] Key ID is present and the pre-shared key is derived from | ||||
| the secret key associated with that Key ID as shown in Section 4.3. | ||||
| The following cryptographic algorithms MUST be supported for use with | Composite Security (SType = 3) is the combination of DTLS Pairwise | |||
| pre-shared keys: | Security and [RFC5310]-Based Authentication. On transmission, the | |||
| DTLS record or records to be sent are secured as specified in Section | ||||
| 4.4 then used as the payload for the application of Authentication as | ||||
| specified in Section 4.3. On reception, the [RFC5310]-based | ||||
| authentication is verified first and an error returned if it fails. | ||||
| If the [RFC5310]-based authentication succeeds, then the DTLS | ||||
| record(s) are processed. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | An advantage of Composite Security is that the payload is | |||
| authenticated and encrypted with a modern security protocol and, in | ||||
| addition, the RBridge Channel Header and (except in the native case) | ||||
| preceding MAC addresses and Data Label are provided with some | ||||
| authentication. | ||||
| o TLS_PSK_WITH_AES_128_CBC_SHA256 [RFC5487] | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5. Extended RBridge Channel Errors | |||
| |1|1| RESV | 2 | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Key ID | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 4.4 DTLS Derived Pre-shared Key Security Information | RBridge Channel Header Extension errors are reported like RBridge | |||
| Channel errors. The ERR field is set to one of the following error | ||||
| codes: | ||||
| When DTLS security is used, the entire payload of the Channel Tunnel | Value RBridge Channel Error Code Meaning | |||
| packet, starting just after the Security Information and ending just | ----- ------------------------------------ | |||
| before the link trailer, is a DTLS record [RFC6347]. | 6 Unknown or unsupported field value | |||
| 7 Authentication failure | ||||
| 8 Error in nested RBridge Channel message | ||||
| 4.7 RFC 5310 Based Encryption and Authentication | Table 5.1 Additional ERR Values | |||
| This SType is based on pre-existing [RFC5310] keying material but | 5.1 SubERRs | |||
| does not use any algorithm that may be associated with a Key ID under | ||||
| [RFC5310]. Instead it uses the derived key as specified in Section | ||||
| 4.3 with the algorithm specified by a Crypto Suite ID as shown in | ||||
| Figure 4.5. Key negotiation is not provided and this SType is | ||||
| intended for use in securing multi-destination packets. The | ||||
| presumption is that in the RBridge Channel case (Figure 2.1) the M | ||||
| bit in the TRILL Header would be one and in the native RBridge | ||||
| Channel case (Figure 2.2), the Outer.MacDA would be group addressed. | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | If the ERR field is 6, the SubERR field indicates the problematic | |||
| |1|1| RESV | 4 | | field or value as shown in the table below. At this time no suberrror | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | codes are assigned under any other ERR field value. | |||
| | Key ID | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Crypto Suite ID | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 4.5 DTLS Derived Pre-shared Key Security Information | Err SubERR Meaning (for ERR = 6) | |||
| --- ------ ----------------------- | ||||
| 0 No Error, suberrors not allowed | ||||
| 1-5 (no suberrors assigned) | ||||
| 6 0 Reserved | ||||
| 6 1 Non-zero RESV4 nibble | ||||
| 6 2 Unsupported SType | ||||
| 6 3 Unsupported PType | ||||
| 6 4 Unknown Key ID | ||||
| 6 5 Unsupported Ethertype with PType = 2 | ||||
| 6 6 Unsupported authentication algorithm for SType = 1 | ||||
| 6 7 Non-zero SubERR with zero ERR field | ||||
| 7-14 (no suberrors assigned) | ||||
| 15 (Reserved) | ||||
| 4.7.1 Channel-Tunnel-CCM | Table 5.2 SubERR values | |||
| The initially specified Crypto Suites is called CT-CCM-128 (Channel | 5.2 Secure Nested RBridge Channel Errors | |||
| Tunnel Counter with CBC-MAC using AES-128), and is designed by Crypto | ||||
| Suite ID 0x0001. | ||||
| CT-CCM is based on [RFC3610] using AES-128 as the encryption | If | |||
| function. The minimum authentication field size permitted is 8 | an extended RBridge Channel message is sent with security and with | |||
| octets. There is additional authenticated data which is the | a payload type (PType) indicating an Ethertyped payload and the | |||
| Ethertype indicates a nested RBridge Channel message | ||||
| and | ||||
| there is an error in the processing of that nested message that | ||||
| results in a return RBridge Channel message with a non-zero ERR | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| authenticated data indicated in Section 4.2 up to but not including | field, | |||
| any of the Tunneled Data (Figure 2.4). The message size is limited to | then that returned message SHOULD also be nested in an extended | |||
| 2**16 - 2**8 bytes so 2 bytes are used for the length of message | RBridge Channel message using the same type of security. In this | |||
| field. There are thus 13 bytes available for nonce [RFC3610]. Since | case, the ERR field in the Extended RBridge Channel envelope is set | |||
| it is possible that the same Key ID could be used by different TRILL | to 8 indicating that there is a nested error in the message being | |||
| switches, the nonce MUST include an identifier for the originating | tunneled back. | |||
| TRILL switch. It is RECOMMENDED that this be the first 6 bytes of its | ||||
| IS-IS System ID as these will be unique across the campus. The | ||||
| remaining 7 bytes (56 bits) need to be such that the nonce is always | ||||
| unique for a particular key, for example a counter for which care is | ||||
| taken that it is always incremented after each use and its value is | ||||
| preserved over TRILL switch crashes, re-starts, and the like. Should | ||||
| there be a danger of exhausting such a counter, the TRILL switch MUST | ||||
| take steps such as causing re-keying of the [RFC5310] key ID it is | ||||
| using and/or changing to use a different Key ID. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 5. Channel Tunnel Errors | 6. IANA Considerations | |||
| RBridge Channel Tunnel Protocol errors are reported like RBridge | This section lists IANA Considerations. | |||
| Channel level errors. The ERR field is set to one of the following | ||||
| error codes: | ||||
| ERR Meaning | 6.1 Extended RBridge Channel Protocol Number | |||
| --- --------- | ||||
| 6 Unknown or unsupported field value | ||||
| 7 Authentication failure | ||||
| 8 Error in nested RBridge Channel message | ||||
| Table 4. Additional ERR Values | IANA is requested to assign TBD [4 recommended] from the range | |||
| assigned by Standards Action as the RBridge Channel protocol number | ||||
| to indicate RBridge Channel Header Extension. | ||||
| 5.1 SubERRs under ERR 6 | The added RBridge Channel protocols registry entry on the TRILL | |||
| Parameters web page is as follows: | ||||
| If the ERR field is 6, the SubERR field indicates the problematic | Protocol Description Reference | |||
| field or value as show in the table below. | -------- -------------------------- ---------------- | |||
| TBD[4] RBridge Channel Extension [this document] | ||||
| SubERR Meaning (for ERR = 6) | 6.2 RBridge Channel Protocol Subregistries | |||
| ------ --------------------- | ||||
| 0 Reserved | ||||
| 1 Non-zero RESV4 nibble | ||||
| 2 Unsupported SType | ||||
| 3 Unsupported PType | ||||
| 4 Unsupported Crypto Suite ID | ||||
| 5 Unknown Key ID | ||||
| 6 Unknown Ethertype with PType = 2 | ||||
| Table 5. SubERR values under ERR 6 | IANA is requested to create three subregistries under the "RBridge | |||
| Channel Protocols" registry as in the subsections below. | ||||
| 5.2 Nested RBridge Channel Errors | 6.2.1 RBridge Channel Error Codes | |||
| If | IANA is requested to assign three additional code points in the | |||
| a Channel Tunnel message is sent with security and with a payload | "RBridge Channel Error Codes" registry on the TRILL Parameters web | |||
| type (PType) indicating a nested RBridge Channel message | page. The additional entries are as show in Table 5.1 in Section 5 | |||
| and | and the "Reference" column value is "[this document]". | |||
| there is an error in the processing of that nested message that | ||||
| results in a return RBridge Channel message with a non-zero ERR | ||||
| field, | ||||
| then that returned message SHOULD also be nested in an Channel Tunnel | ||||
| message using the same type of security. In this case, the ERR field | ||||
| in the Channel Tunnel envelope is set to 8 indicating that there is a | ||||
| nested error in the message being tunneled back. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | 6.2.2 RBridge Channel SubError Codes | |||
| 6. IANA Considerations | IANA is request to create a subregistry indented under the RBridge | |||
| Channel Error Codes registry, for RBridge Chanel SubError Code. The | ||||
| initial contents of this subregistry is as show in Table 5.2 in | ||||
| Section 5.1 except that a fourth column "Reference" is added with | ||||
| value "[this document]" for all rows. The header information is as | ||||
| follows: | ||||
| This section list IANA Considerations. | Registry Name: RBridge Channel SubError Codes | |||
| Registration Procedures: IETF Review | ||||
| Reference: [this document] | ||||
| 6.1 RBridge Channel Protocol Number | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| IANA is requested to assign TBD as the RBridge Channel protocol | 6.2.3 Extended RBridge Channel Payload Types Subregistry | |||
| number for the "Channel Tunnel" protocol from the range assigned by | ||||
| Standards Action. | ||||
| The added RBridge Channel protocols registry entry on the TRILL | IANA is requested to create an "Extended RBridge Channel Payload | |||
| Parameters web page is as follows: | Types" registry after the "RBridge Channel Protocols" registry on the | |||
| TRILL Parameters web page. The header information is as follows: | ||||
| Protocol Description Reference | Registration Procedures: IETF Review | |||
| -------- -------------- ------------------ | Reference: [this document] | |||
| TBD Channel Tunnel [this document] | The initial registry content is Table 3.1 in Section 3 of this | |||
| document. | ||||
| 6.2 Channel Tunnel Crypto Suites | 6.2.4 Extended RBridge Channel Security Types Subregistry | |||
| IANA is requested to create a subregistry in the TRILL Parameters | IANA is requested to create an "Extended RBridge Channel Security | |||
| registry as follows: | Types" registry after the "Extended RBridge Channel Payload Types" | |||
| registry on the TRILL Parameters web page. The header information is | ||||
| as follows: | ||||
| Name: RBridge Channel Tunnel Crypto Suites | Registration Procedures: IETF Review | |||
| Registration Procedures: Expert Review | Reference: [this document] | |||
| Reference: [this document] | ||||
| Value Description Reference | The initial registry content is Table 4.1 in Section 4 of this | |||
| ------- ------------- ----------- | document. | |||
| 0 Reserved | ||||
| 1 CT-CCM [this document] | ||||
| 2-65534 available for assignment | ||||
| 65535 Reserved | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 7. Security Considerations | 7. Security Considerations | |||
| The RBridge Channel tunnel facility has potentially positive and | The RBridge Channel Header Extension has potentially positive and | |||
| negative effects on security. | negative effects on security. | |||
| On the positive side, it provides optional security that can be used | On the positive side, it provides optional security that can be used | |||
| to authenticate and/or encrypt RBridge Channel messages. Some RBridge | to authenticate and/or encrypt RBridge Channel messages. Some RBridge | |||
| Channel message payloads, such as BFD [RFC7175], provide their own | Channel message payloads, such as BFD [RFC7175], provide their own | |||
| security but where this is not true, consideration should be given, | security but where this is not true, consideration should be given, | |||
| when specifying an RBridge Channel protocol, to recommending or | when specifying an RBridge Channel protocol, to recommending or | |||
| requiring use of the security features of the Tunnel Protocol. | requiring use of the security features of the RBridge Channel Header | |||
| Extension. | ||||
| On the negative side, the optional ability to tunnel various payload | On the negative side, the optional ability to tunnel more payload | |||
| types and to tunnel them between TRILL switches and to and from end | types and to tunnel them between TRILL switches and to and from end | |||
| stations can increase risk unless precautions are taken. The | stations can increase risk unless precautions are taken. The | |||
| processing of decapsulating Tunnel Protocol payloads is not a good | processing of decapsulated extended RBridge Channel payloads is a | |||
| place to be liberal in what you accept. This is because the tunneling | place where you SHOULD NOT be liberal in what you accept. This is | |||
| facility makes it easier for unexpected messages to pop up in | because the tunneling facility makes it easier for unexpected | |||
| unexpected places in a TRILL campus due to accidents or the actions | messages to pop up in unexpected places in a TRILL campus due to | |||
| of an adversary. Local policies should generally be strict and only | accidents or the actions of an adversary. Local policies SHOULD | |||
| process payload types required and then only with adequate | generally be strict and only accept payload types required and then | |||
| authentication for the particular circumstances. | only with adequate security for the particular circumstances. | |||
| While simple [RFC5310] based authentication as specified in Section | See the first paragraph of Section 4 for recommendations on SType | |||
| 4.5 is better than nothing, in general it is RECOMMENDED that DTLS | usage. | |||
| based security, as specified in Section 4.6, be used for all point- | ||||
| to-point Channel Tunnel messages and [RFC5310] based encryption and | ||||
| authentication, as specified in Section 4.7, be used for all multi- | ||||
| destination Channel Tunnel messages. If IS-IS authentication is not | ||||
| being used, then [RFC5310] keying information would not normally be | ||||
| available but that presumably represents a judgment by the TRILL | ||||
| campus operator that security is not needed. | ||||
| In connection with the use of DTLS for security as specified in | See [RFC7457] for Security Considerations of DTLS for security. | |||
| Section 4.5, see [RFC7457]. | ||||
| If IS-IS authentication is not being used, then [RFC5310] keying | ||||
| information would not normally be available but that presumably | ||||
| represents a judgment by the TRILL campus operator that no security | ||||
| is needed. | ||||
| See [RFC7178] for general RBridge Channel Security Considerations and | See [RFC7178] for general RBridge Channel Security Considerations and | |||
| [RFC6325] for general TRILL Security Considerations. | [RFC6325] for general TRILL Security Considerations. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Normative References | Normative References | |||
| [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology | [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Information technology | |||
| -- Telecommunications and information exchange between systems | -- Telecommunications and information exchange between systems | |||
| -- Intermediate System to Intermediate System intra-domain | -- Intermediate System to Intermediate System intra-domain | |||
| routeing information exchange protocol for use in conjunction | routeing information exchange protocol for use in conjunction | |||
| with the protocol for providing the connectionless-mode network | with the protocol for providing the connectionless-mode network | |||
| service (ISO 8473)", 2002. | service (ISO 8473)", 2002. | |||
| [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, | [RFC20] - Cerf, V., "ASCII format for network interchange", STD 80, | |||
| RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>. | RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc- | |||
| editor.org/info/rfc20>. | ||||
| [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
| [RFC3610] - Whiting, D., Housley, R., and N. Ferguson, "Counter with | [RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate | |||
| CBC-MAC (CCM)", RFC 3610, September 2003, <http://www.rfc- | Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, | |||
| editor.org/info/rfc3610>. | March 1997, <http://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC5246] - Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC4279] - Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key | |||
| (TLS) Protocol Version 1.2", RFC 5246, August 2008, | Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI | |||
| <http://www.rfc-editor.org/info/rfc5246>. | 10.17487/RFC4279, December 2005, <http://www.rfc- | |||
| editor.org/info/rfc4279>. | ||||
| [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., | [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., | |||
| and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC | and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC | |||
| 5310, February 2009. | 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc- | |||
| editor.org/info/rfc5310>. | ||||
| [RFC5487] - Badra, M., "Pre-Shared Key Cipher Suites for TLS with | ||||
| SHA-256/384 and AES Galois Counter Mode", RFC 5487, March 2009, | ||||
| <http://www.rfc-editor.org/info/rfc5487>. | ||||
| [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- | [RFC5869] - Krawczyk, H. and P. Eronen, "HMAC-based Extract-and- | |||
| Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, | Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, | |||
| <http://www.rfc-editor.org/info/rfc5869>. | <http://www.rfc-editor.org/info/rfc5869>. | |||
| [RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. | [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. | |||
| Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, | Ghanwani, "Routing Bridges (RBridges): Base Protocol | |||
| July 2011. | Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, | |||
| <http://www.rfc-editor.org/info/rfc6325>. | ||||
| [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer | [RFC6347] - Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
| Security Version 1.2", RFC 6347, January 2012, <http://www.rfc- | Security Version 1.2", RFC 6347, January 2012, <http://www.rfc- | |||
| editor.org/info/rfc6347>. | editor.org/info/rfc6347>. | |||
| [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., | [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., | |||
| and D. Dutt, "Transparent Interconnection of Lots of Links | and D. Dutt, "Transparent Interconnection of Lots of Links | |||
| (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. | (TRILL): Fine-Grained Labeling", RFC 7172, DOI | |||
| 10.17487/RFC7172, May 2014, <http://www.rfc- | ||||
| editor.org/info/rfc7172>. | ||||
| [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, | [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, | |||
| D., and A. Banerjee, "Transparent Interconnection of Lots of | D., and A. Banerjee, "Transparent Interconnection of Lots of | |||
| Links (TRILL) Use of IS-IS", RFC 7176, May 2014, | Links (TRILL) Use of IS-IS", RFC 7176, May 2014, | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | ||||
| <http://www.rfc-editor.org/info/rfc7176>. | <http://www.rfc-editor.org/info/rfc7176>. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | ||||
| [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. | [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. | |||
| Ward, "Transparent Interconnection of Lots of Links (TRILL): | Ward, "Transparent Interconnection of Lots of Links (TRILL): | |||
| RBridge Channel Support", RFC 7178, May 2014. | RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May | |||
| 2014, <http://www.rfc-editor.org/info/rfc7178>. | ||||
| [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding | [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding | |||
| Scope Link State PDUs (LSPs)", RFC 7356, September 2014, | Scope Link State PDUs (LSPs)", RFC 7356, September 2014, | |||
| <http://www.rfc-editor.org/info/rfc7356>. | <http://www.rfc-editor.org/info/rfc7356>. | |||
| [rfc7180bis] - Eastlake, D., Zhang, M., Perlman, R. Banerjee, A., | [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., | |||
| Ghanwani, A., and S. Gupta, "TRILL: Clarifications, | Ghanwani, A., and S. Gupta, "Transparent Interconnection of | |||
| Corrections, and Updates", Draft-ietf-trill-rfc7180bis, work in | Lots of Links (TRILL): Clarifications, Corrections, and | |||
| progress. | Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, | |||
| <http://www.rfc-editor.org/info/rfc7780>. | ||||
| Informative References | Informative References | |||
| [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash | [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash | |||
| Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May | Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI | |||
| 2011. | 10.17487/RFC6234, May 2011, <http://www.rfc- | |||
| editor.org/info/rfc6234>. | ||||
| [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent | [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent | |||
| Interconnection of Lots of Links (TRILL) Protocol Control | Interconnection of Lots of Links (TRILL) Protocol Control | |||
| Protocol", RFC 6361, August 2011 | Protocol", RFC 6361, August 2011 | |||
| [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and | [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and | |||
| IETF Protocol and Documentation Usage for IEEE 802 Parameters", | IETF Protocol and Documentation Usage for IEEE 802 Parameters", | |||
| BCP 141, RFC 7042, October 2013. | BCP 141, RFC 7042, October 2013. | |||
| [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. | ||||
| Gashinsky, "Directory Assistance Problem and High-Level Design | ||||
| Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, | ||||
| <http://www.rfc-editor.org/info/rfc7067>. | ||||
| [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, | [RFC7175] - Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, | |||
| "Transparent Interconnection of Lots of Links (TRILL): | "Transparent Interconnection of Lots of Links (TRILL): | |||
| Bidirectional Forwarding Detection (BFD) Support", RFC 7175, | Bidirectional Forwarding Detection (BFD) Support", RFC 7175, | |||
| May 2014. | May 2014. | |||
| [RFC7435] - Dukhovni, V., "Opportunistic Security: Some Protection | ||||
| Most of the Time", RFC 7435, December 2014, <http://www.rfc- | ||||
| editor.org/info/rfc7435>. | ||||
| [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing | [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing | |||
| Known Attacks on Transport Layer Security (TLS) and Datagram | Known Attacks on Transport Layer Security (TLS) and Datagram | |||
| TLS (DTLS)", RFC 7457, February 2015, <http://www.rfc- | TLS (DTLS)", RFC 7457, February 2015, <http://www.rfc- | |||
| editor.org/info/rfc7457>. | editor.org/info/rfc7457>. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | [AddrFlush] - W. Hao, D. Eastlake, Y. Li, "TRILL: Address Flush | |||
| Message", draft-ietf-trill-address-flush, work in progress. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | ||||
| [GroupKey] - D. Eastlake et al, "Group Keying Protocol", draft- | ||||
| eastlake-trill-group-keying, work in progress. | ||||
| [rfc6439bis] - D. Eastlake, Y. Li, M. Umair, A. Banerjee, H. Fangwei, | ||||
| "TRILL: Appointed Forwarders", draft-ietf-trill-rfc6439bis, | ||||
| work in progress. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | ||||
| Appendix Z: Change History | Appendix Z: Change History | |||
| RFC Editor: Please delete this Appendix before publication. | ||||
| From -00 to -01 | From -00 to -01 | |||
| 1. Fix references for RFCs published, etc. | 1. Fix references for RFCs published, etc. | |||
| 2. Explicitly mention in the Abstract and Introduction that this | 2. Explicitly mention in the Abstract and Introduction that this | |||
| document updates [RFC7178]. | document updates [RFC7178]. | |||
| 3. Add this Change History Appendix. | 3. Add this Change History Appendix. | |||
| From -01 to -02 | From -01 to -02 | |||
| skipping to change at page 25, line 32 ¶ | skipping to change at page 27, line 34 ¶ | |||
| 2. Editorial changes to IANA Considerations to correspond to draft- | 2. Editorial changes to IANA Considerations to correspond to draft- | |||
| leiba-cotton-iana-5226bis-11.txt. | leiba-cotton-iana-5226bis-11.txt. | |||
| 3. Improvements to the Ethernet frame payload type. | 3. Improvements to the Ethernet frame payload type. | |||
| 4. Other Editorial changes. | 4. Other Editorial changes. | |||
| From -02 to -03 | From -02 to -03 | |||
| 1. Update TRILL Header to correspond to [rfc7180bis]. | 1. Update TRILL Header to correspond to [RFC7780]. | |||
| 2. Remove a few remnants of the "Scope" feature that was removed from | 2. Remove a few remnants of the "Scope" feature that was removed from | |||
| -01 to -02. | -01 to -02. | |||
| 3. Substantial changes to and expansion of Section 4 including adding | 3. Substantial changes to and expansion of Section 4 including adding | |||
| details of DTLS security. | details of DTLS security. | |||
| 4. Updates and additions to the References. | 4. Updates and additions to the References. | |||
| 5. Other minor editorial changes. | 5. Other minor editorial changes. | |||
| From -03 to -04 | From -03 to -04 | |||
| 1. Add SType for [RFC5310] keying based security that provides | 1. Add SType for [RFC5310] keying based security that provides | |||
| encryption as well as authentication. | encryption as well as authentication. | |||
| 2. Editorial improvements and fixes. | 2. Editorial improvements and fixes. | |||
| From -04 to -05 | From -04 to -05 | |||
| 1. Primary change is collapsing the previous PTypes 2, 3, and 4 for | 1. Primary change is collapsing the previous PTypes 2, 3, and 4 for | |||
| RBridge Channel message, TRILL Data, and TRILL IS-IS into one by | RBridge Channel message, TRILL Data, and TRILL IS-IS into one by | |||
| including the Ethertype. Previous PType 5 is renumbered as 3. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| including the Ethertype. Previous PType 5 is renumbered as 3. | ||||
| 2. Add Channel Tunnel Crypto Suites to IANA Considerations | 2. Add Channel Tunnel Crypto Suites to IANA Considerations | |||
| 3. Add some material to Security Considerations, | 3. Add some material to Security Considerations, | |||
| 4. Assorted Editorial changes. | 4. Assorted Editorial changes. | |||
| From -05 to -06 | From -05 to -06 | |||
| Fix editorials found during WG Last Call. | Fix editorials found during WG Last Call. | |||
| From -06 to -07 | From -06 to -07 | |||
| Minor editorial changes resulting for Shepherd review. | Minor editorial changes resulting for Shepherd review. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | From -07 to -08 | |||
| Move group keyed security out of the draft. Simplify and improve | ||||
| remaining security provisions. | ||||
| From -08 to -09 | ||||
| 1. Updates based on Routing Directorate review. | ||||
| 2. Improvements to specification of pairwise DTLS and significant | ||||
| other security improvements. | ||||
| From -09 to -10 | ||||
| Update based on GENART review. | ||||
| From -10 to -11 | ||||
| 1. Add IANA registry for suberror codes and make other minor IANA | ||||
| Considerations changes. | ||||
| 2. Add informational references to [RFC7067], address flush, and | ||||
| rfc6439bis. | ||||
| 3. Add RFC 2119 keyword emphasis to Security Considerations caution | ||||
| in handling decapsulated extended RBridge Channel payloads. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | ||||
| Acknowledgements | Acknowledgements | |||
| The contributions of the following are hereby acknowledged: | The contributions of the following are hereby gratefully | |||
| acknowledged: | ||||
| Susan Hares, Gayle Noble | Stephen Farrell, Jonathan Hardwick, Susan Hares, Gayle Noble, | |||
| Alvaro Retana, Yaron Sheffer, and Peter Yee. | ||||
| The document was prepared in raw nroff. All macros used were defined | The document was prepared in raw nroff. All macros used were defined | |||
| within the source file. | within the source file. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Authors' Addresses | Authors' Addresses | |||
| Donald E. Eastlake, 3rd | Donald E. Eastlake, 3rd | |||
| Huawei Technologies | Huawei Technologies | |||
| 155 Beaver Street | 155 Beaver Street | |||
| Milford, MA 01757 USA | Milford, MA 01757 USA | |||
| Phone: +1-508-333-2270 | Phone: +1-508-333-2270 | |||
| EMail: d3e3e3@gmail.com | EMail: d3e3e3@gmail.com | |||
| skipping to change at page 29, line 5 ¶ | skipping to change at page 31, line 5 ¶ | |||
| EMail: mohammed.umair2@gmail.com | EMail: mohammed.umair2@gmail.com | |||
| Yizhou Li | Yizhou Li | |||
| Huawei Technologies | Huawei Technologies | |||
| 101 Software Avenue, | 101 Software Avenue, | |||
| Nanjing 210012, China | Nanjing 210012, China | |||
| Phone: +86-25-56622310 | Phone: +86-25-56622310 | |||
| EMail: liyizhou@huawei.com | EMail: liyizhou@huawei.com | |||
| INTERNET-DRAFT TRILL: RBridge Channel Tunnel | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Copyright, Disclaimer, and Additional IPR Provisions | Copyright, Disclaimer, and Additional IPR Provisions | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| End of changes. 199 change blocks. | ||||
| 539 lines changed or deleted | 631 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||