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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/