< 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/