| < draft-ietf-trill-channel-tunnel-09.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: December 11, 2016 June 12, 2016 | Expires: February 4, 2017 August 5, 2016 | |||
| TRILL: RBridge Channel Header Extension | TRILL: RBridge Channel Header Extension | |||
| <draft-ietf-trill-channel-tunnel-09.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 (specified in RFC 7178) | protocol includes an optional mechanism (specified in RFC 7178) | |||
| called RBridge Channel for the transmission of typed messages between | called RBridge Channel for the transmission of typed messages between | |||
| TRILL switches in the same campus and the transmission of such | TRILL switches in the same campus and the transmission of such | |||
| messages between TRILL switches and end stations on the same link. | messages between TRILL switches and end stations on the same link. | |||
| This document specifies extensions to the RBridge Channel protocol | This document specifies extensions to the RBridge Channel protocol | |||
| header to support two features as follows: (1) a standard method to | header to support two features as follows: (1) a standard method to | |||
| skipping to change at page 2, line 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
| 3.1 Null Payload...........................................8 | 3.1 Null Payload...........................................8 | |||
| 3.2 Ethertyped Payload.....................................8 | 3.2 Ethertyped Payload.....................................8 | |||
| 3.2.1 RBridge Channel Message as the Payload...............9 | 3.2.1 RBridge Channel Message as the Payload...............9 | |||
| 3.2.2 TRILL Data Packet as the Payload.....................9 | 3.2.2 TRILL Data Packet as the Payload.....................9 | |||
| 3.2.3 TRILL IS-IS Packet as the Payload...................10 | 3.2.3 TRILL IS-IS Packet as the Payload...................10 | |||
| 3.3 Ethernet Frame........................................11 | 3.3 Ethernet Frame........................................11 | |||
| 4. Extended RBridge Channel Security......................14 | 4. Extended RBridge Channel Security......................14 | |||
| 4.1 Derived Keying Material...............................14 | 4.1 Derived Keying Material...............................14 | |||
| 4.2 SType None............................................15 | 4.2 SType None............................................15 | |||
| 4.3 RFC 5310 Based Authentication.........................15 | 4.3 [RFC5310]-Based Authentication........................15 | |||
| 4.4 DTLS Pairwise Security................................17 | 4.4 DTLS Pairwise Security................................17 | |||
| 4.5 Composite Security....................................18 | 4.5 Composite Security....................................18 | |||
| 5. Extended RBridge Channel Errors........................19 | 5. Extended RBridge Channel Errors........................19 | |||
| 5.1 SubERRs under ERR 6...................................19 | 5.1 SubERRs...............................................19 | |||
| 5.2 Secure Nested RBridge Channel Errors..................19 | 5.2 Secure Nested RBridge Channel Errors..................19 | |||
| 6. IANA Considerations....................................20 | 6. IANA Considerations....................................21 | |||
| 6.1 Extended RBridge Channel Protocol Number..............20 | 6.1 Extended RBridge Channel Protocol Number..............21 | |||
| 6.2 RBridge Channel Error Codes Subregistry...............20 | 6.2 RBridge Channel Protocol Subregistries................21 | |||
| 6.2.1 RBridge Channel Error Codes.........................21 | ||||
| 7. Security Considerations................................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 | ||||
| Normative References......................................22 | 7. Security Considerations................................23 | |||
| Informative References....................................23 | ||||
| Appendix Z: Change History................................24 | Normative References......................................24 | |||
| Informative References....................................25 | ||||
| Acknowledgements..........................................26 | Appendix Z: Change History................................27 | |||
| Authors' Addresses........................................27 | Acknowledgements..........................................29 | |||
| Authors' Addresses........................................30 | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 1. Introduction | 1. Introduction | |||
| The IETF TRILL base protocol [RFC6325] [RFC7780] has been extended | The IETF TRILL base protocol [RFC6325] [RFC7780] has been extended | |||
| with the 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 the transmission of such messages between RBridges | same campus and the transmission of such messages between RBridges | |||
| and end stations on the same link. When sent between RBridges in the | and end stations on the same link. When sent between RBridges in the | |||
| same campus, a TRILL Data packet with a TRILL Header is used and the | same campus, a TRILL Data packet with a TRILL Header is used and the | |||
| destination RBridge is indicated by nickname. When sent between a | destination RBridge is indicated by nickname. When sent between a | |||
| RBridge and an end station on the same link in either direction, a | RBridge and an end station on the same link in either direction, a | |||
| native RBridge Channel message [RFC7178] is used with no TRILL Header | native RBridge Channel message [RFC7178] is used with no TRILL Header | |||
| and the destination port or ports are indicated by a MAC address. | and the destination port or ports are indicated by a MAC address. | |||
| (There is no mechanism to stop end stations on the same link, from | (There is no mechanism to stop end stations on the same link from | |||
| sending native RBridge Channel messages to each other; however, such | sending native RBridge Channel messages to each other; however, such | |||
| use is outside the scope of this document.) | use is outside the scope of this document.) | |||
| This document updates [RFC7178] and specifies extensions to the | This document updates [RFC7178] and specifies extensions to the | |||
| RBridge Channel header that provide two additional facilities as | RBridge Channel header that provide two additional facilities as | |||
| follows: | follows: | |||
| (1) A standard method to tunnel payloads whose type may be | (1) A standard method to tunnel payloads whose type may be | |||
| indicated by Ethertype through encapsulation in RBridge | indicated by Ethertype through encapsulation in RBridge | |||
| Channel messages. | 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]. | ||||
| Use of each of these facilities is optional, except that, as | Use of each of these facilities is optional, except that, as | |||
| specified below, if this header extension is implemented there are | specified below, if this header extension is implemented there are | |||
| two payload types that MUST be implemented. Both of the above | two payload types that MUST be implemented. Both of the above | |||
| facilities can be used in the same packet. In case of conflict | facilities can be used in the same packet. In case of conflict | |||
| between this document and [RFC7178], this document takes precedence. | 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", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| [RFC2119]. | [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 new terms and acronyms. | with additional new terms and acronyms. | |||
| application_data - A DTLS [RFC6347] message type. | application_data - A DTLS [RFC6347] message type. | |||
| Data Label - VLAN or FGL. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 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 | 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]. | 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] [RFC7780], sometimes referred to as an RBridge. | [RFC6325] [RFC7780], sometimes referred to as an RBridge. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 2. RBridge Channel Header Extension Format | 2. RBridge Channel Header Extension Format | |||
| skipping to change at page 6, line 24 ¶ | skipping to change at page 6, line 24 ¶ | |||
| / 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 header extensions specified herein are in the form of an RBridge | The header extensions specified herein are in the form of an RBridge | |||
| Channel protocol, the RBridge Channel Extension Protocol. Figure 2.4 | Channel protocol, the Extended RBridge Channel Protocol. Figure 2.4 | |||
| below expands the RBridge Channel Header and Protocol Specific | below expands the RBridge Channel Header and Protocol Specific | |||
| Payload above for the case where the header extension is present. | 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 | Channel Protocol=[TBD]| | | 0x8946 | CHV=0 | Channel Protocol=[TBD]| | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags | ERR | | | Flags | ERR | | |||
| skipping to change at page 8, line 10 ¶ | skipping to change at page 8, line 10 ¶ | |||
| The RBridge Channel Header Extension is integrated with the RBridge | The RBridge Channel Header Extension is integrated with the RBridge | |||
| Channel facility. Extension errors are reported as if they were | Channel facility. Extension errors are reported as if they were | |||
| RBridge Channel errors, using newly allocated code points in the ERR | RBridge Channel errors, using newly allocated code points in the ERR | |||
| field of 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 Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 3. Extended RBridge Channel Payload Types | 3. Extended RBridge Channel Payload Types | |||
| The Extended RBridge Channel Protocol can carry a variety of payloads | The Extended RBridge Channel Protocol can carry a variety of payloads | |||
| as 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 Ethertyped Payload | 2 Ethertyped Payload Section 3.2 of [this doc] | |||
| 3 3.3 Ethernet Frame | 3 Ethernet Frame Section 3.3 of [this doc] | |||
| 4-14 Unassigned | 4-14 Unassigned | |||
| 15 Reserved | 15 Reserved | |||
| Table 3.1 Payload Type Values | Table 3.1 Payload Type Values | |||
| While implementation of the RBridge Channel Header Extension is | While implementation of the RBridge Channel Header Extension is | |||
| optional, if it is implemented PType 1 (Null) MUST be implemented and | optional, if it is implemented PType 1 (Null) MUST be implemented and | |||
| PType 2 (Ethertyped Payload) with the RBridge Channel Ethertype MUST | PType 2 (Ethertyped Payload) with the RBridge Channel Ethertype MUST | |||
| be implemented. PType 2 for any Ethertypes other than the RBridge | be implemented. PType 2 for any Ethertypes other than the RBridge | |||
| Channel Ethertype MAY be implemented. PType 3 MAY be implemented. | Channel Ethertype MAY be implemented. PType 3 MAY be implemented. | |||
| The processing of any particular extended header RBridge Channel | The processing of any particular extended header RBridge Channel | |||
| message and its payload depends on meeting local security and other | message and its payload depends on meeting local security and other | |||
| policy at the 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 where only | or for messages such as key negotiation or the like where only | |||
| security information is present. It indicates that there is no | security information is present. It indicates that there is no user | |||
| payload. Any data after the Security Information field is ignored. If | data payload. Any tunneled user data after the Security Information | |||
| the RBridge Channel Header Extension is implemented, the Null Payload | field is ignored. If the RBridge Channel Header Extension is | |||
| MUST be supported in the sense that an "Unsupported PType" error is | implemented, the Null Payload MUST be supported in the sense that an | |||
| not returned (see Section 5). Any particular use of the Null Payload | "Unsupported PType" error is not returned (see Section 5). Any | |||
| should specify what VLAN or FGL and what priority should be used in | particular use of the Null Payload should specify what VLAN or FGL | |||
| the inner Data Label of the RBridge Channel message (or in an outer | and what priority should be used in the inner Data Label of the | |||
| VLAN tag for the native RBridge Channel message case) when those | RBridge Channel message (or in an outer VLAN tag for the native | |||
| values are relevant. | RBridge Channel message case) when those values are relevant. | |||
| 3.2 Ethertyped Payload | 3.2 Ethertyped Payload | |||
| A PType of 2 indicates that the payload of the extended RBridge | A PType of 2 indicates that the payload (tunneled data) of the | |||
| Channel message begins with an Ethertype. A TRILL switch supporting | extended RBridge Channel message begins with an Ethertype. A TRILL | |||
| the RBridge Channel Header Extension MUST support a PType of 2 with a | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| payload beginning with the RBridge Channel Ethertype as described in | switch supporting the RBridge Channel Header Extension MUST support a | |||
| Section 3.2.1. Other Ethertypes, including the TRILL and L2-IS-IS | PType of 2 with a payload beginning with the RBridge Channel | |||
| Ethertypes as described in Section 3.2.2 and 3.2.3, MAY be supported. | 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. | ||||
| 3.2.1 RBridge Channel Message as the Payload | 3.2.1 RBridge Channel Message as the Payload | |||
| A PType of 2 whose payload has an initial RBridge Channel Ethertype | A PType of 2 whose payload has an initial RBridge Channel Ethertype | |||
| indicates an encapsulated RBridge Channel message. A typical reason | indicates an encapsulated RBridge Channel message. A typical reason | |||
| for sending an RBridge Channel message inside an extended RBridge | for sending an RBridge Channel message inside an extended RBridge | |||
| Channel message is to provide security services, such as | Channel message is to provide security services, such as | |||
| authentication or encryption, for the encapsulated message. | authentication or encryption, for the encapsulated message. | |||
| This RBridge Channel message type looks like the following: | This RBridge Channel message type looks like the following: | |||
| skipping to change at page 12, line 31 ¶ | skipping to change at page 12, line 31 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Any Ethernet frame tagging... | | Any Ethernet frame tagging... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | |||
| | Ethernet frame payload... | | Ethernet frame payload... | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | |||
| Figure 3.4 Message Structure with Ethernet Frame Payload | 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 individually addressed to a link | If the RBridge Channel message is individually addressed to a link | |||
| local port, the source TRILL switch will have the information to | local port, the source TRILL switch will have the information to | |||
| construct such a MAC address for the destination TRILL switch port | construct such a MAC address for the destination TRILL switch port | |||
| and that MAC address MAY be used as the MacDA. By the use of such a | and that MAC address MAY be used as the MacDA. By the use of such a | |||
| MacSA and either such a unicast MacDA or a group addressed MacDA, an | MacSA and either such a unicast MacDA or a group addressed MacDA, an | |||
| Ethernet frame can be sent between two TRILL switch ports connected | Ethernet frame can be sent between two TRILL switch ports connected | |||
| by a non-Ethernet link. | 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 | |||
| skipping to change at page 14, line 9 ¶ | skipping to change at page 14, line 9 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Port ID | | | Port ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 3.5 Synthetic MAC Address | Figure 3.5 Synthetic MAC Address | |||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 4. Extended RBridge Channel Security | 4. Extended RBridge Channel Security | |||
| Table 4.1 below gives the assigned values of the SType field and | Table 4.1 below gives the assigned values of the SType (Security | |||
| their meaning. Use of DTLS Pairwise Security (SType = 2) or Composite | Type) field and their meaning. Use of DTLS Pairwise Security (SType = | |||
| Security (SType = 3) is RECOMMENDED. | 2) or Composite Security (SType = 3) is RECOMMENDED. | |||
| While [RFC5310] based authentication is also specified and can be use | While [RFC5310]-based authentication is also specified and can be | |||
| for both pairwise and multi-destination traffic, it provides only | used for both pairwise and multi-destination traffic, it provides | |||
| authentication and is not considered to meet current security | only authentication and is not considered to meet current security | |||
| standards. For example, it does not provide for key negotiation; | standards. For example, it does not provide for key negotiation; | |||
| thus, its use is NOT RECOMMENDED. | thus, its use is NOT RECOMMENDED. | |||
| The Extended RBridge Channel DTLS based security specified in Section | The Extended RBridge Channel DTLS-based security specified in Section | |||
| 4.4 and the Composite Security specified in Section 4.5 below are | 4.4 and the Composite Security specified in Section 4.5 below are | |||
| intended for pairwise (known unicast) use. That is, the case where | 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 | the M bit in the TRILL Header is zero and any Outer.MacDA is | |||
| individually addressed. | individually addressed. | |||
| Multi-destination Extended RBridge Channel packets would be those | Multi-destination Extended RBridge Channel packets would be those | |||
| with the M bit in the TRILL Header set to one or, in the native | 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 | RBridge Channel case, the Outer.MacDA would be group addressed. The | |||
| DTLS Pairwise Security and Composite Security STypes can also be used | DTLS Pairwise Security and Composite Security STypes can also be used | |||
| in the multi-destination case by serially unicasting the messages to | in the multi-destination case by serially unicasting the messages to | |||
| all data accessible RBridges (or stations in the native RBridge | all data-accessible RBridges (or stations in the native RBridge | |||
| Channel case) in the recipient group. For TRILL Data packets, that | Channel case) in the recipient group. For TRILL Data packets, that | |||
| group is specified by the Data Label; for native frames, the group is | group is specified by the Data Label; for native frames, the group is | |||
| specified by the groupcast destination MAC address. It is intended to | specified by the groupcast destination MAC address. It is intended to | |||
| specify a true group keyed SType to secure multi-destination packets | specify a true group keyed SType to secure multi-destination packets | |||
| in a separate document [GroupKey]. | in a separate document [GroupKey]. | |||
| SType Section Meaning | SType Description Reference | |||
| ----- ------- ------- | ----- ----------- --------- | |||
| 0 4.2 None | 0 None Section 4.2 of [this doc] | |||
| 1 4.3 [RFC5310] Based Authentication | 1 [RFC5310]-Based Authentication Section 4.3 of [this doc] | |||
| 2 4.4 DTLS Pairwise Security | 2 DTLS Pairwise Security Section 4.4 of [this doc] | |||
| 3 4.5 Composite Security | 3 Composite Security Section 4.5 of [this doc] | |||
| 4-14 Available for assignment by IETF Review | 4-14 Unassigned | |||
| 15 Reserved | 15 Reserved | |||
| Table 4.1 SType Values | Table 4.1 SType Values | |||
| 4.1 Derived Keying Material | 4.1 Derived Keying Material | |||
| In some cases, it is possible to use material derived from [RFC5310] | In some cases, it is possible to use material derived from [RFC5310] | |||
| IS-IS keying material as an element of Extended RBridge Channel | IS-IS keying material as an element of Extended RBridge Channel | |||
| security. It is assumed that the IS-IS keying material is of high | 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 | quality. The material actually used is derived from the IS-IS keying | |||
| material as follows: | material as follows: | |||
| skipping to change at page 15, line 15 ¶ | skipping to change at page 15, line 15 ¶ | |||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Derived Material = | Derived Material = | |||
| HKDF-Expand-SHA256 ( IS-IS-key, "Extended Channel" | 0x0S, L ) | HKDF-Expand-SHA256 ( IS-IS-key, "Extended Channel" | 0x0S, L ) | |||
| where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is | where "|" indicates concatenation, HKDF is as in [RFC5869], SHA256 is | |||
| as in [RFC6234], IS-IS-key is the input IS-IS keying material, | as in [RFC6234], IS-IS-key is the input IS-IS keying material, | |||
| "Extended Channel" is the 16-character ASCII [RFC20] string indicated | "Extended Channel" is the 16-character ASCII [RFC20] string indicated | |||
| without any leading length byte or trailing zero byte, 0x0S is a | 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 | 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 | being used and the upper nibble is zero, and L is the length of the | |||
| output-derived material needed. | output-derived material needed. | |||
| Whenever IS-IS keying material is being used as above, the underlying | Whenever IS-IS keying material is being used as above, the underlying | |||
| [RFC5310] keying material might expire or be invalidated. At the time | [RFC5310] keying material might expire or be invalidated. At the time | |||
| of or before such expiration or invalidation, the use of the Derived | of or before such expiration or invalidation, the use of the Derived | |||
| Material from the IS-IS keying material MUST cease. Continued | Material from the IS-IS keying material MUST cease. Continued | |||
| security MAY use new derived material from currently valid [RFC5310] | security MAY use new derived material from currently valid [RFC5310] | |||
| keying material. | keying material. | |||
| 4.2 SType None | 4.2 SType None | |||
| No security services are being invoked. The length of the Security | No security services are being invoked. The length of the Security | |||
| Information field (see Figure 2.4) is zero. | Information field (see Figure 2.4) is zero. | |||
| 4.3 RFC 5310 Based Authentication | 4.3 [RFC5310]-Based Authentication | |||
| This SType provides security for Extended RBridge Channel messages | This SType provides security for Extended RBridge Channel messages | |||
| similar to that provided for [IS-IS] PDUs by the [IS-IS] | similar to that provided for [IS-IS] PDUs by the [IS-IS] | |||
| Authentication TLV. The Security Information (see Figure 2.4) is as | Authentication TLV. The Security Information (see Figure 2.4) is as | |||
| shown in Figure 4.1. | shown in Figure 4.1. | |||
| 1 1 1 1 1 1 | 1 1 1 1 1 1 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | RESV | Size | | | RESV | Size | | |||
| skipping to change at page 16, line 7 ¶ | skipping to change at page 16, line 7 ¶ | |||
| + | + | |||
| | Authentication Data (Variable) | | Authentication Data (Variable) | |||
| + | + | |||
| | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-... | +-+-+-+-+-+-+-+-+-+-+-+-+-... | |||
| Figure 4.1 SType 1 Security Information | Figure 4.1 SType 1 Security Information | |||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| o RESV: Four bits that MUST be sent as zero and ignored or receipt. | o RESV: Four bits that MUST be sent as zero and ignored on receipt. | |||
| o Size: Set to 2 + the size of Authentication Data in bytes. | o Size: Set to 2 + the size of Authentication Data in bytes. | |||
| o Key ID: specifies the keying value and authentication algorithm | o Key ID: specifies the keying value and authentication algorithm | |||
| that the Key ID specifies for TRILL IS-IS LSP [RFC5310] | that the Key ID specifies for TRILL IS-IS LSP [RFC5310] | |||
| Authentication TLVs. The keying material actually used is derived | Authentication TLVs. The keying material actually used is always | |||
| as shown in Section 4.1. | derived as shown in Section 4.1. | |||
| o Authentication Data: The authentication data produced by the | o Authentication Data: The authentication data produced by the | |||
| derived key and algorithm associated with the Key ID acting on the | derived key and algorithm associated with the Key ID acting on the | |||
| part of the TRILL Data packet shown. Length of the authentication | part of the TRILL Data packet shown. Length of the authentication | |||
| data depends on the algorithm. The authentication value is | data depends on the algorithm. The authentication value is | |||
| included in the security information field and is treated as zero | included in the security information field and is treated as zero | |||
| when authentication is calculated. | when authentication is calculated. | |||
| As show in Figure 4.2, the area covered by this authentication starts | As show in Figure 4.2, the area covered by this authentication starts | |||
| with the byte immediately after the TRILL Header optional Flag Word | with the byte immediately after the TRILL Header optional Flag Word | |||
| skipping to change at page 17, line 23 ¶ | skipping to change at page 17, line 23 ¶ | |||
| | (plus Security Information)| . | | (plus Security Information)| . | |||
| +-----------------------------+ | | +-----------------------------+ | | |||
| | Payload | . | | Payload | . | |||
| +-----------------------------+ v | +-----------------------------+ v | |||
| | Ethernet Trailer | | | Ethernet Trailer | | |||
| +-----------------------------+ | +-----------------------------+ | |||
| Figure 4.3. Native SType 1 Authentication Coverage | Figure 4.3. Native SType 1 Authentication Coverage | |||
| While RBridges, which are IS-IS routers, can reasonably be expected | While RBridges, which are IS-IS routers, can reasonably be expected | |||
| to hold [RFC5310] keying, so that this SType can be used for RBridge | to hold [RFC5310] keying so that this SType can be used for RBridge | |||
| Channel messages, how end stations might come to hold [RFC5310] | Channel messages, how end stations might come to hold [RFC5310] | |||
| keying is beyond the scope of this document. Thus this SType might | keying is beyond the scope of this document. Thus this SType might | |||
| not be applicable to native RBridge Channel messages. | not be applicable to native RBridge Channel messages. | |||
| 4.4 DTLS Pairwise Security | 4.4 DTLS Pairwise Security | |||
| DTLS [RFC6347] supports key negotiation and provides both encryption | DTLS [RFC6347] supports key negotiation and provides both encryption | |||
| and authentication. The RBridge Channel Extended Header DTLS Pairwise | and authentication. The RBridge Channel Extended Header DTLS Pairwise | |||
| SType uses a negotiated DTLS version that MUST NOT be less than 1.2. | SType uses a negotiated DTLS version that MUST NOT be less than 1.2. | |||
| skipping to change at page 17, line 51 ¶ | skipping to change at page 17, line 51 ¶ | |||
| Sz, which will not be less than 1470 bytes, by allowing for the TRILL | Sz, which will not be less than 1470 bytes, by allowing for the TRILL | |||
| Data packet, extended RBridge Channel, and DTLS framing overhead. | Data packet, extended RBridge Channel, and DTLS framing overhead. | |||
| With this SType, the security information between the extended | With this SType, the security information between the extended | |||
| RBridge Channel header and the payload is null because all the | RBridge Channel header and the payload is null because all the | |||
| security information is in the payload area. | security information is in the payload area. | |||
| The DTLS Pairwise keying is set up between a pair of RBridges | The DTLS Pairwise keying is set up between a pair of RBridges | |||
| independent of Data Label using messages of a priority configurable | independent of Data Label using messages of a priority configurable | |||
| at the RBridge level which defaults to priority 6. DTLS message types | at the RBridge level which defaults to priority 6. DTLS message types | |||
| other than application_data can be the payload of an extended RBridge | other than application_data can be the payload of an extended RBridge | |||
| Channel message with a TRILL Header using any Data Label. Actual | Channel message with a TRILL Header using any Data Label and, for | |||
| application_data sent within such a message using this SType SHOULD | such DTLS message types, the PType in the RBridge Channel Header | |||
| use the Data Label and priority as specified for that | Extension is ignored. | |||
| application_data. In this case, the PType value in the RBridge | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 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. | Channel Header Extension applies to the decrypted application_data. | |||
| TRILL switches that implement the extended RBridge Channel DTLS | TRILL switches that implement the extended RBridge Channel DTLS | |||
| Pairwise SType SHOULD support the use of certificates for DTLS but | Pairwise SType SHOULD support the use of certificates for DTLS but | |||
| certificate size may be limited by the DTLS requirement that each | certificate size may be limited by the DTLS requirement that each | |||
| record fit within a single message. | record fit within a single message. Appropriate certificate contents | |||
| is out of scope for this document. | ||||
| TRILL switches that support the extended RBridge Channel DTLS | TRILL switches that support the extended RBridge Channel DTLS | |||
| Pairwise SType MUST support the use of pre-shared keys. If the | Pairwise SType MUST support the use of pre-shared keys. If the | |||
| psk_identity (see [RFC4279]) is two bytes, it is interpreted as a | 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 | [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 | 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 | psk_identity with a length other than two bytes MAY be used to | |||
| indicate other implementation dependent pre-shared keys. Pre-shared | indicate other implementation dependent pre-shared keys. Pre-shared | |||
| keys used for DTLS negotiation SHOULD be shared only by the pair of | keys used for DTLS negotiation SHOULD be shared only by the pair of | |||
| end points; otherwise, secuirty could be attacked by diverting | end points; otherwise, security could be attacked by diverting | |||
| messages to another end point holding that pre-shared key. | messages to another end point holding that pre-shared key. | |||
| 4.5 Composite Security | 4.5 Composite Security | |||
| Composite Security (SType = 3) is the combination of DTLS Pairwise | Composite Security (SType = 3) is the combination of DTLS Pairwise | |||
| Security and [RFC5310] Based Authentication. On transmission, the | Security and [RFC5310]-Based Authentication. On transmission, the | |||
| DTLS record or records to be sent are secured as specified in Section | 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 | 4.4 then used as the payload for the application of Authentication as | |||
| specified in Section 4.3. On reception, the [RFC5310] based | specified in Section 4.3. On reception, the [RFC5310]-based | |||
| authentication is verified first and an error returned if it fails. | authentication is verified first and an error returned if it fails. | |||
| Then the DTLS record(s) are processed. | If the [RFC5310]-based authentication succeeds, then the DTLS | |||
| record(s) are processed. | ||||
| An advantage of Composite Security is that the payload is | An advantage of Composite Security is that the payload is | |||
| authenticated and encrypted with a modern security protocol and, in | authenticated and encrypted with a modern security protocol and, in | |||
| addition, the RBridge Channel Header and (except in the native case) | addition, the RBridge Channel Header and (except in the native case) | |||
| preceding MAC addresses and Data Label are provided with some | preceding MAC addresses and Data Label are provided with some | |||
| authentication. | authentication. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 5. Extended RBridge Channel Errors | 5. Extended RBridge Channel Errors | |||
| RBridge Channel Header Extension errors are reported like RBridge | RBridge Channel Header Extension errors are reported like RBridge | |||
| Channel errors. The ERR field is set to one of the following error | Channel errors. The ERR field is set to one of the following error | |||
| codes: | codes: | |||
| ERR Meaning | Value RBridge Channel Error Code Meaning | |||
| --- --------- | ----- ------------------------------------ | |||
| 6 Unknown or unsupported field value | 6 Unknown or unsupported field value | |||
| 7 Authentication failure | 7 Authentication failure | |||
| 8 Error in nested RBridge Channel message | 8 Error in nested RBridge Channel message | |||
| Table 5.1 Additional ERR Values | Table 5.1 Additional ERR Values | |||
| 5.1 SubERRs under ERR 6 | 5.1 SubERRs | |||
| If the ERR field is 6, the SubERR field indicates the problematic | If the ERR field is 6, the SubERR field indicates the problematic | |||
| field or value as shown in the table below. | field or value as shown in the table below. At this time no suberrror | |||
| codes are assigned under any other ERR field value. | ||||
| SubERR Meaning (for ERR = 6) | Err SubERR Meaning (for ERR = 6) | |||
| ------ --------------------- | --- ------ ----------------------- | |||
| 0 Reserved | 0 No Error, suberrors not allowed | |||
| 1 Non-zero RESV4 nibble | 1-5 (no suberrors assigned) | |||
| 2 Unsupported SType | 6 0 Reserved | |||
| 3 Unsupported PType | 6 1 Non-zero RESV4 nibble | |||
| 4 Unknown Key ID | 6 2 Unsupported SType | |||
| 5 Unsupported Ethertype with PType = 2 | 6 3 Unsupported PType | |||
| 6 Unsupported authentication algorithm for SType = 1 | 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) | ||||
| Table 5.2 SubERR values under ERR 6 | Table 5.2 SubERR values | |||
| 5.2 Secure Nested RBridge Channel Errors | 5.2 Secure Nested RBridge Channel Errors | |||
| If | If | |||
| an extended RBridge Channel message is sent with security and with | an extended RBridge Channel message is sent with security and with | |||
| a payload type (PType) indicating an Ethertyped payload and the | a payload type (PType) indicating an Ethertyped payload and the | |||
| Ethertype indicates a nested RBridge Channel message | Ethertype indicates a nested RBridge Channel message | |||
| and | and | |||
| there is an error in the processing of that nested message that | there is an error in the processing of that nested message that | |||
| results in a return RBridge Channel message with a non-zero ERR | results in a return RBridge Channel message with a non-zero ERR | |||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | ||||
| field, | field, | |||
| then that returned message SHOULD also be nested in an extended | then that returned message SHOULD also be nested in an extended | |||
| RBridge Channel message using the same type of security. In this | RBridge Channel message using the same type of security. In this | |||
| case, the ERR field in the Extended RBridge Channel envelope is set | case, the ERR field in the Extended RBridge Channel envelope is set | |||
| to 8 indicating that there is a nested error in the message being | to 8 indicating that there is a nested error in the message being | |||
| tunneled back. | tunneled back. | |||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| skipping to change at page 20, line 24 ¶ | skipping to change at page 21, line 24 ¶ | |||
| assigned by Standards Action as the RBridge Channel protocol number | assigned by Standards Action as the RBridge Channel protocol number | |||
| to indicate RBridge Channel Header Extension. | to indicate RBridge Channel Header Extension. | |||
| The added RBridge Channel protocols registry entry on the TRILL | The added RBridge Channel protocols registry entry on the TRILL | |||
| Parameters web page is as follows: | Parameters web page is as follows: | |||
| Protocol Description Reference | Protocol Description Reference | |||
| -------- -------------------------- ---------------- | -------- -------------------------- ---------------- | |||
| TBD[4] RBridge Channel Extension [this document] | TBD[4] RBridge Channel Extension [this document] | |||
| 6.2 RBridge Channel Error Codes Subregistry | 6.2 RBridge Channel Protocol Subregistries | |||
| IANA is requested to create a "RBridge Channel Error Codes" | IANA is requested to create three subregistries under the "RBridge | |||
| subregistry under the "RBridge Channel Protocols" registry. The | Channel Protocols" registry as in the subsections below. | |||
| header information is as follows: | ||||
| 6.2.1 RBridge Channel Error Codes | ||||
| IANA is requested to assign three additional code points in the | ||||
| "RBridge Channel Error Codes" registry on the TRILL Parameters web | ||||
| page. The additional entries are as show in Table 5.1 in Section 5 | ||||
| and the "Reference" column value is "[this document]". | ||||
| 6.2.2 RBridge Channel SubError Codes | ||||
| 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: | ||||
| Registry Name: RBridge Channel SubError Codes | ||||
| Registration Procedures: IETF Review | Registration Procedures: IETF Review | |||
| References: [RFC7178] [this document] | Reference: [this document] | |||
| The subregistry is to have columns and entries as follows: | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Code Meaning Reference | 6.2.3 Extended RBridge Channel Payload Types Subregistry | |||
| ---- ------- --------- | ||||
| [populate rows for codes 0 through 5 from Section 3.2 of | IANA is requested to create an "Extended RBridge Channel Payload | |||
| [RFC7178] with reference [RFC7178] ] | Types" registry after the "RBridge Channel Protocols" registry on the | |||
| [populate rows for codes 6 through 8 from Table 5.1 of this | TRILL Parameters web page. The header information is as follows: | |||
| document with reference [this document] ] | ||||
| 9-15 Unassigned | Registration Procedures: IETF Review | |||
| 16 Reserved | Reference: [this document] | |||
| The initial registry content is Table 3.1 in Section 3 of this | ||||
| document. | ||||
| 6.2.4 Extended RBridge Channel Security Types Subregistry | ||||
| IANA is requested to create an "Extended RBridge Channel Security | ||||
| Types" registry after the "Extended RBridge Channel Payload Types" | ||||
| registry on the TRILL Parameters web page. The header information is | ||||
| as follows: | ||||
| Registration Procedures: IETF Review | ||||
| Reference: [this document] | ||||
| The initial registry content is Table 4.1 in Section 4 of this | ||||
| document. | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 7. Security Considerations | 7. Security Considerations | |||
| The RBridge Channel Header Extension 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 RBridge Channel Header | requiring use of the security features of the RBridge Channel Header | |||
| Extension. | Extension. | |||
| On the negative side, the optional ability to tunnel more 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 extended RBridge Channel payloads is not | processing of decapsulated extended RBridge Channel payloads is a | |||
| a good place to be liberal in what you accept. This is because the | place where you SHOULD NOT be liberal in what you accept. This is | |||
| tunneling facility makes it easier for unexpected messages to pop up | because the tunneling facility makes it easier for unexpected | |||
| in unexpected places in a TRILL campus due to accidents or the | messages to pop up in unexpected places in a TRILL campus due to | |||
| actions of an adversary. Local policies should generally be strict | accidents or the actions of an adversary. Local policies SHOULD | |||
| and only accept payload types required and then only with adequate | generally be strict and only accept payload types required and then | |||
| security for the particular circumstances. | only with adequate security for the particular circumstances. | |||
| See the first paragraph of Section 4 for recommendations on SType | See the first paragraph of Section 4 for recommendations on SType | |||
| usage. | usage. | |||
| See [RFC7457] for Security Considerations of DTLS for security. | See [RFC7457] for Security Considerations of DTLS for security. | |||
| If IS-IS authentication is not being used, then [RFC5310] keying | If IS-IS authentication is not being used, then [RFC5310] keying | |||
| information would not normally be available but that presumably | information would not normally be available but that presumably | |||
| represents a judgment by the TRILL campus operator that no security | represents a judgment by the TRILL campus operator that no security | |||
| is needed. | is needed. | |||
| skipping to change at page 23, line 37 ¶ | skipping to change at page 25, line 37 ¶ | |||
| editor.org/info/rfc6234>. | 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. | |||
| [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>. | |||
| [GroupKey] - D. Eastlake et al, "Group Keying Protocol", draft-ietf- | [AddrFlush] - W. Hao, D. Eastlake, Y. Li, "TRILL: Address Flush | |||
| trill-group-keying, work in progress. | 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 | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Appendix Z: Change History | Appendix Z: Change History | |||
| RFC Editor: Please delete this Appendix before publication. | 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. | |||
| skipping to change at page 26, line 5 ¶ | skipping to change at page 28, line 35 ¶ | |||
| Move group keyed security out of the draft. Simplify and improve | Move group keyed security out of the draft. Simplify and improve | |||
| remaining security provisions. | remaining security provisions. | |||
| From -08 to -09 | From -08 to -09 | |||
| 1. Updates based on Routing Directorate review. | 1. Updates based on Routing Directorate review. | |||
| 2. Improvements to specification of pairwise DTLS and significant | 2. Improvements to specification of pairwise DTLS and significant | |||
| other security improvements. | 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 | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Acknowledgements | Acknowledgements | |||
| The contributions of the following are hereby gratefully | The contributions of the following are hereby gratefully | |||
| acknowledged: | acknowledged: | |||
| Jonathan Hardwick, Susan Hares, Gayle Noble, and Yaron Sheffer | 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 Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| Authors' Addresses | Authors' Addresses | |||
| Donald E. Eastlake, 3rd | Donald E. Eastlake, 3rd | |||
| Huawei Technologies | Huawei Technologies | |||
| End of changes. 56 change blocks. | ||||
| 121 lines changed or deleted | 203 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/ | ||||