| < draft-ietf-trill-channel-tunnel-10.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: January 4, 2017 July 5, 2016 | Expires: February 4, 2017 August 5, 2016 | |||
| TRILL: RBridge Channel Header Extension | TRILL: RBridge Channel Header Extension | |||
| <draft-ietf-trill-channel-tunnel-10.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 30 ¶ | skipping to change at page 2, line 30 ¶ | |||
| 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 [RFC5310]-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 Protocol Subregistries................20 | 6.2 RBridge Channel Protocol Subregistries................21 | |||
| 6.2.1 RBridge Channel Error Codes Subregistry.............20 | 6.2.1 RBridge Channel Error Codes.........................21 | |||
| 6.2.2 Extended RBridge Channel Payload Types Subregistry..21 | 6.2.2 RBridge Channel SubError Codes......................21 | |||
| 6.2.3 Extended RBridge Channel Security Types Subregistry.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 | Appendix Z: Change History................................27 | |||
| Acknowledgements..........................................27 | Acknowledgements..........................................29 | |||
| Authors' Addresses........................................28 | 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 | |||
| skipping to change at page 3, line 33 ¶ | skipping to change at page 3, line 33 ¶ | |||
| 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 - HMAC-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]. | |||
| 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 (see also Section 6.2.2). | the table below with further explanation after the table (see also | |||
| Section 6.2.2). | ||||
| PType Description Reference | PType Description Reference | |||
| ----- ----------- --------- | ----- ----------- --------- | |||
| 0 Reserved | 0 Reserved | |||
| 1 Null Section 3.1 of [this doc] | 1 Null Section 3.1 of [this doc] | |||
| 2 Ethertyped Payload Section 3.2 of [this doc] | 2 Ethertyped Payload Section 3.2 of [this doc] | |||
| 3 Ethernet Frame Section 3.3 of [this doc] | 3 Ethernet Frame Section 3.3 of [this doc] | |||
| 4-14 Unassigned | 4-14 Unassigned | |||
| 15 Reserved | 15 Reserved | |||
| skipping to change at page 8, line 38 ¶ | skipping to change at page 8, line 39 ¶ | |||
| 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 tunneled data after the Security Information field is | data payload. Any tunneled user data after the Security Information | |||
| ignored. If the RBridge Channel Header Extension is implemented, the | field is ignored. If the RBridge Channel Header Extension is | |||
| Null Payload MUST be supported in the sense that an "Unsupported | implemented, the Null Payload MUST be supported in the sense that an | |||
| PType" error is not returned (see Section 5). Any particular use of | "Unsupported PType" error is not returned (see Section 5). Any | |||
| the Null Payload should specify what VLAN or FGL and what priority | particular use of the Null Payload should specify what VLAN or FGL | |||
| should be used in the inner Data Label of the RBridge Channel message | and what priority should be used in the inner Data Label of the | |||
| (or in an outer VLAN tag for the native RBridge Channel message case) | RBridge Channel message (or in an outer VLAN tag for the native | |||
| when those 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 (tunneled data) of the | A PType of 2 indicates that the payload (tunneled data) of the | |||
| extended RBridge Channel message begins with an Ethertype. A TRILL | extended RBridge Channel message begins with an Ethertype. A TRILL | |||
| switch supporting the RBridge Channel Header Extension MUST support a | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| switch supporting the RBridge Channel Header Extension MUST support a | ||||
| PType of 2 with a payload beginning with the RBridge Channel | PType of 2 with a payload beginning with the RBridge Channel | |||
| Ethertype as described in Section 3.2.1. Other Ethertypes, including | 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 | the TRILL and L2-IS-IS Ethertypes as described in Section 3.2.2 and | |||
| 3.2.3, MAY be supported. | 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 | |||
| 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 | While [RFC5310]-based authentication is also specified and can be | |||
| used for both pairwise and multi-destination traffic, it provides | used for both pairwise and multi-destination traffic, it provides | |||
| only 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 | |||
| skipping to change at page 16, line 13 ¶ | skipping to change at page 16, line 13 ¶ | |||
| 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 on 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 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, security 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 29 ¶ | skipping to change at page 21, line 29 ¶ | |||
| Protocol Description Reference | Protocol Description Reference | |||
| -------- -------------------------- ---------------- | -------- -------------------------- ---------------- | |||
| TBD[4] RBridge Channel Extension [this document] | TBD[4] RBridge Channel Extension [this document] | |||
| 6.2 RBridge Channel Protocol Subregistries | 6.2 RBridge Channel Protocol Subregistries | |||
| IANA is requested to create three subregistries under the "RBridge | IANA is requested to create three subregistries under the "RBridge | |||
| Channel Protocols" registry as in the subsections below. | Channel Protocols" registry as in the subsections below. | |||
| 6.2.1 RBridge Channel Error Codes Subregistry | 6.2.1 RBridge Channel Error Codes | |||
| IANA is requested to create an "RBridge Channel Error Codes" | IANA is requested to assign three additional code points in the | |||
| subregistry under the "RBridge Channel Protocols" registry. The | "RBridge Channel Error Codes" registry on the TRILL Parameters web | |||
| header information is as follows: | page. The additional entries are as show in Table 5.1 in Section 5 | |||
| and the "Reference" column value is "[this document]". | ||||
| Registration Procedures: IETF Review | 6.2.2 RBridge Channel SubError Codes | |||
| References: [RFC7178] [this document] | ||||
| The subregistry is to have columns and entries as follows: | 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: | ||||
| Code Meaning Reference | Registry Name: RBridge Channel SubError Codes | |||
| ---- ------- --------- | Registration Procedures: IETF Review | |||
| [populate rows for codes 0 through 5 from Section 3.2 of | Reference: [this document] | |||
| [RFC7178] with reference [RFC7178] ] | ||||
| [populate rows for codes 6 through 8 from Table 5.1 of this | ||||
| document with reference [this document] ] | ||||
| 9-15 Unassigned | ||||
| 16 Reserved | ||||
| INTERNET-DRAFT TRILL: RBridge Channel Extension | INTERNET-DRAFT TRILL: RBridge Channel Extension | |||
| 6.2.2 Extended RBridge Channel Payload Types Subregistry | 6.2.3 Extended RBridge Channel Payload Types Subregistry | |||
| IANA is requested to create an "Extended RBridge Channel Payload | IANA is requested to create an "Extended RBridge Channel Payload | |||
| Types" subregistry under the "RBridge Channel Protocols" registry. | Types" registry after the "RBridge Channel Protocols" registry on the | |||
| The header information is as follows: | TRILL Parameters web page. The header information is as follows: | |||
| Registration Procedures: IETF Review | Registration Procedures: IETF Review | |||
| Reference: [this document] | Reference: [this document] | |||
| The initial subregistry content is Table 3.1 in this document. | The initial registry content is Table 3.1 in Section 3 of this | |||
| document. | ||||
| 6.2.3 Extended RBridge Channel Security Types Subregistry | 6.2.4 Extended RBridge Channel Security Types Subregistry | |||
| IANA is requested to create an "Extended RBridge Channel Security | IANA is requested to create an "Extended RBridge Channel Security | |||
| Types" subregistry under the "RBridge Channel Protocols" registry. | Types" registry after the "Extended RBridge Channel Payload Types" | |||
| The header information is as follows: | registry on the TRILL Parameters web page. The header information is | |||
| as follows: | ||||
| Registration Procedures: IETF Review | Registration Procedures: IETF Review | |||
| Reference: [this document] | Reference: [this document] | |||
| The initial subregistry content is Table 4.1 in 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 decapsulated extended RBridge Channel payloads is not a | processing of decapsulated extended RBridge Channel payloads is 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 24, 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 27, line 5 ¶ | skipping to change at page 28, line 39 ¶ | |||
| 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 | From -09 to -10 | |||
| Update based on GENART review. | 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, Yaron Sheffer, and | Stephen Farrell, Jonathan Hardwick, Susan Hares, Gayle Noble, | |||
| Peter Yee. | 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. 42 change blocks. | ||||
| 92 lines changed or deleted | 137 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/ | ||||