RFC 7978
Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension
RFC 7978: TRILL RBridge Channel Header Extension 🎀
Okay bestie, this one is a whole vibe. 💖 It's an IETF Standards Track doc, so it's official and it's for real. It's written by D. Eastlake 3rd (Huawei), M. Umair (IPinfusion), and Y. Li (Huawei). It came out in September 2016, and it's published as ISSN 2070-1721. It also updates RFC 7178. That means it tweaks the RBridge Channel rules from that earlier doc. In a conflict, this one wins. 👑
The whole thing is about TRILL (Transparent Interconnection of Lots of Links), which is the protocol for switches to talk to each other. ✨
Abstract ✨
Okay so, TRILL has this optional feature called RBridge Channel (defined in RFC 7178) 🦋 It's how TRILL switches send typed messages to each other inside the same campus. It also lets those switches send messages to end stations on the same link. This doc adds to the RBridge Channel header so it can do two new things. First, it gives a standard way to tunnel payloads whose type can be shown by an Ethertype, wrapped inside RBridge Channel messages. Second, it gives a way to add security to RBridge Channel messages. 🔥 The doc updates RFC 7178.
Status of This Memo 📜
This is an Internet Standards Track document. 💅
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841. 🌸
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7978. 🫶
Copyright Notice ©️
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), which apply on the publication date. Please read these documents carefully, because they explain your rights and restrictions for this doc. 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Simplified BSD License describes. 🎀
Table of Contents 🧚
1. Introduction ....................................................4
1.1. Terminology and Acronyms ...................................4
2. RBridge Channel Header Extension Format .........................5
3. Extended RBridge Channel Payload Types ..........................8
3.1. Null Payload ...............................................8
3.2. Ethertyped Payload .........................................9
3.2.1. RBridge Channel Message as the Payload ..............9
3.2.2. TRILL Data Packet as the Payload ...................10
3.2.3. TRILL IS-IS Packet as the Payload ..................10
3.3. Ethernet Frame ............................................11
4. Extended RBridge Channel Security ..............................13
4.1. Derived Keying Material ...................................14
4.2. SType None ................................................14
4.3. IS-IS CRYPTO_AUTH-Based Authentication ....................15
4.4. DTLS Pairwise Security ....................................17
4.5. Composite Security ........................................18
5. Extended RBridge Channel Errors ................................18
5.1. SubERRs ...................................................19
5.2. Secure Nested RBridge Channel Errors ......................19
6. IANA Considerations ............................................19
6.1. Extended RBridge Channel Protocol Number ..................19
6.2. RBridge Channel Protocol Subregistries ....................20
6.2.1. RBridge Channel Error Codes ........................20
6.2.2. RBridge Channel SubError Codes .....................20
6.2.3. Extended RBridge Channel Payload Types
Subregistry ........................................20
6.2.4. Extended RBridge Channel Security Types
Subregistry ........................................21
7. Security Considerations ........................................21
8. Normative References ...........................................22
9. Informative References .........................................23
Acknowledgements ..................................................25
Authors' Addresses ................................................251. Introduction 🦋
Okay so the TRILL base protocol ([RFC6325] and [RFC7780]) got extended with the RBridge Channel [RFC7178]. It's a facility for sending typed messages, like Bidirectional Forwarding Detection (BFD) [RFC7175], between two TRILL switches (RBridges) in the same campus. It also covers messages between an RBridge and an end station on the same link. 💜
When the messages go between RBridges in the same campus, a TRILL Data packet with a TRILL Header is used, and the destination RBridge is named by its nickname. When the messages go between an RBridge and an end station on the same link (either direction), a native RBridge Channel message [RFC7178] is used. That one has no TRILL Header, and the destination port or ports are named by a Media Access Control (MAC) address. 🎀
Heads up on one thing: there's no mechanism to stop end stations on the same link from sending native RBridge Channel messages to each other. 🙈 Still, that kind of use is outside the scope of this doc.
This doc updates [RFC7178], and it adds extensions to the RBridge Channel header that give two extra facilities:
- (1) A standard method to tunnel payloads, whose type may be indicated by Ethertype, through encapsulation in RBridge Channel messages. ✨
- (2) A method to provide security facilities for RBridge Channel messages. Example uses that need this include the security of Pull Directory messages
[RFC7067], address flush messages[AddrFlush], and port shutdown messages[TRILL-AF]. 🔥
Using each of these facilities is optional. There's one exception, though: as spelled out below, if this header extension is implemented, there are two payload types that MUST be implemented. 💅 You can use both facilities in the same packet. And if this doc and [RFC7178] ever conflict, this doc takes precedence. 👑
1.1. Terminology and Acronyms 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119]. 🫶
This doc uses terminology and abbreviations defined in [RFC6325] and [RFC7178]. A few of them are listed below for convenience, along with some new terms and abbreviations. 🌸
application_data: a DTLS[RFC6347]message type.- Data Label: VLAN or FGL.
- DTLS: Datagram Transport Layer Security
[RFC6347]. - FCS: Frame Check Sequence.
- FGL: Fine-Grained Label
[RFC7172]. - HKDF: HMAC-based Key Derivation Function
[RFC5869]. - IS-IS: Intermediate System to Intermediate System
[IS-IS]. - PDU: Protocol Data Unit.
- MTU: Maximum Transmission Unit.
- RBridge: An alternative term for a TRILL switch. 🦋
- SHA: Secure Hash Algorithm
[RFC6234]. - Sz: Campus-wide minimum link MTU
[RFC6325][RFC7780]. - TRILL: Transparent Interconnection of Lots of Links, or Tunneled Routing in the Link Layer. 🧚
- TRILL switch: A device that implements the TRILL protocol
[RFC6325][RFC7780], sometimes called an RBridge. 💖
2. RBridge Channel Header Extension Format ✨
okay so bestie, the general structure of an RBridge Channel message between two TRILL switches (RBridges) in the same campus looks like Figure 1 below 🦋. A native RBridge Channel message, the kind that goes between an RBridge and an end station on the same link (in either direction), is shown in Figure 2. Compared with Figure 1, it skips the TRILL Header, the inner Ethernet addresses, and the Data Label, so it's giving minimalist 💅. A Protocol field in the RBridge Channel Header tells you what type of RBridge Channel message you're looking at and how to read the Channel-Protocol-Specific Payload [RFC7178] 🎀.
+-----------------------------------+
| Link Header |
+-----------------------------------+
| TRILL Header |
+-----------------------------------+
| Inner Ethernet Addresses |
+-----------------------------------+
| Data Label (VLAN or FGL) |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel-Protocol-Specific Payload |
+-----------------------------------+
| Link Trailer (FCS if Ethernet) |
+-----------------------------------+
Figure 1: RBridge Channel Packet Structure
+-----------------------------------+
| Ethernet Link Header |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel-Protocol-Specific Payload |
+-----------------------------------+
| FCS |
+-----------------------------------+
Figure 2: Native RBridge Channel FrameThe RBridge Channel Header looks like this 👀:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8946 | CHV=0 | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ Channel-Protocol-Specific Data /
/-+-+-+-+-+- /
Figure 3: RBridge Channel Headerwhere 0x8946 is the RBridge-Channel Ethertype and CHV is the Channel Header Version. This document is based on RBridge Channel version zero 🌈.
The header extensions in this spec are in the form of an RBridge Channel protocol called the Extended RBridge Channel Protocol ✨. Figure 4 below expands the RBridge Channel Header and Protocol-Specific Payload from above for when 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
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8946 | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Extension Specific: | SubERR| RESV4 | SType | PType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Tunneled Data, variable length
| ...
Figure 4: RBridge Channel Header Extension StructureThe RBridge Channel Header Protocol field is how you tell that the header extension is there 🔥. Its contents MUST be the value allocated for this purpose (see Section 6). Using an RBridge Channel protocol to signal extensions is so smart because it's easy to check whether a remote RBridge in the campus supports extensions, since RBridges advertise which such protocols they support in their LSP 🧠💜.
The Extended RBridge Channel-Protocol-Specific Data fields go like this:
SubERR: This field gives more detail when an error is indicated in the RBridge ChannelERRfield. IfERRis zero, thenSubERRMUST be sent as zero and ignored on receipt. See Section 5 💀.RESV4: This field MUST be sent as zero. If it's non-zero when received, that's an error condition. See Section 5 🙈.SType: This field describes the type of security information and features, including keying material, that the extended RBridge Channel message is using or providing. See Section 4 🔐.PType: Payload Type. This describes the tunneled data. See Section 3 🍓.Security Information: Variable-length information. The length is zero ifSTypeis zero. See Section 4 🫶.
The RBridge Channel Header Extension is integrated with the RBridge Channel facility, and extension errors get reported as if they were RBridge Channel errors. The way they do this is by using newly allocated code points in the ERR field of the RBridge Channel Header, backed up by the SubERR field ⭐.
3. Extended RBridge Channel Payload Types 💖
The Extended RBridge Channel Protocol can carry a bunch of different payloads, and the PType (Payload Type) field tells you which one you've got 🎀. The values are in the table below, with more explanation after it (see also Section 6.2.2) 👑.
PType Description Reference
----- ----------- ---------
0 Reserved
1 Null Section 3.1 of RFC 7978
2 Ethertyped Payload Section 3.2 of RFC 7978
3 Ethernet Frame Section 3.3 of RFC 7978
4-14 Unassigned
15 Reserved
Table 1: Payload Type ValuesImplementing the RBridge Channel Header Extension is optional, but if you do implement it, PType 1 (Null) MUST be implemented, and PType 2 (Ethertyped Payload) with the RBridge-Channel Ethertype MUST be implemented too 🌸. PType 2 for any Ethertypes other than the RBridge-Channel Ethertype MAY be implemented. PType 3 MAY be implemented 🧚♀️.
Whether a particular extended header RBridge Channel message and its payload get processed depends on meeting local security and other policy at the destination TRILL switch or end station 🔐✨.
3.1. Null Payload 🌸
The Null payload type (PType = 1) is meant for testing, or for messages like key negotiation where only security information is present. It means there's no user data payload 🙅♀️. Any tunneled user data after the Security Information field is ignored. If the RBridge Channel Header Extension is 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. Ethertyped Payload 🦋
A PType of 2 means the payload (tunneled data) of the extended RBridge Channel message starts with an Ethertype 💜. A TRILL switch that supports 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 Sections 3.2.2 and 3.2.3, MAY be supported 🌈.
3.2.1. RBridge Channel Message as the Payload 🧚
A PType of 2 whose payload starts with the RBridge-Channel Ethertype means you've got an encapsulated RBridge Channel message inside 🪆. A typical reason to send an RBridge Channel message inside an extended RBridge Channel message is to get 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
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 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | CHV=0 |Nested Channel Protocol|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Nested Channel-Protocol-Specific Data ... /
/ /
Figure 5: Message Structure with RBridge Channel Payload3.2.2. TRILL Data Packet as the Payload ✨
okay bestie, a PType of 2 with an initial TRILL Ethertype means the payload is an encapsulated TRILL Data packet 🦋 (see Figure 6). If that Ethertype is supported for PType = 2 and the message passes local policy, the TRILL Data packet gets handled as if the destination TRILL switch had received it on the port where the Extended RBridge Channel message came in 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL (0x22F3) | V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Optional Flags Word /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacDA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacDA continued | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Data Label (2 or 4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL Data Packet payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Message Structure with TRILL Data Packet PayloadThe optional flags word only shows up if the F bit in the TRILL Header is one [RFC7780] 🌸
3.2.3. TRILL IS-IS Packet as the Payload 💜
A PType of 2 and an initial L2-IS-IS Ethertype mean the payload of the Extended RBridge Channel protocol message is an encapsulated TRILL IS-IS PDU (see Figure 7). If this Ethertype is supported for PType = 2, the tunneled TRILL IS-IS packet gets processed by the destination RBridge if it meets local policy. One possible use is to speed up receipt of a link state PDU (LSP) by some TRILL switch or switches that need the link state information right away 🚀 A link local IS-IS PDU would not normally be sent this way, except possibly to encrypt the PDU, since those PDUs can just be transmitted on the link and don't normally need RBridge Channel handling. (Link local IS-IS PDUs are (1) Hello, CSNP, PSNP [IS-IS]; (2) MTU-probe, MTU-ack [RFC7176]; and (3) circuit scoped FS-LSP, FS-CSNP, and FS-PSNP [RFC7356].)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | CHV=0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| L2-IS-IS (0x22F4) | 0x83 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rest of IS-IS PDU
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 7: Message Structure with TRILL IS-IS Packet Payload3.3. Ethernet Frame 🍓
If PType is 3, the extended RBridge Channel payload is an Ethernet frame, just like one a station might receive from or send to an end station. The difference is that the encapsulated Ethernet frame's FCS is left out (see Figure 8). (There is still an overall final FCS if the RBridge Channel message is being sent on an Ethernet link.) If this PType is implemented and the message passes local policy, the encapsulated frame is handled as if it had been received on the port where the Extended RBridge Channel message came in 🧚
The priority of the RBridge Channel message can be copied from the Ethernet frame VLAN tag, if one is present, except that priority 7 SHOULD only be used for messages critical to establishing or maintaining adjacency, and priority 6 SHOULD only be used for other important control messages. 👑
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | 0x0 | Channel Protocol=0x004|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | SubERR| RESV4 | SType | 0x3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Information, variable length (0 length if SType = 0) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacDA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacDA (cont.) | MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Any Ethernet frame tagging...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Ethernet frame payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 8: Message Structure with Ethernet Frame PayloadOn a non-Ethernet link, such as a PPP (Point-to-Point Protocol) link [RFC6361], the ports on the link are considered to have link-local synthetic 48-bit MAC addresses, built the way described below. Such a constructed address MAY be used as a MacSA. If the RBridge Channel message is individually addressed to a link-local port, the source TRILL switch will have the info it needs to build such a MAC address for the destination TRILL switch port, and that MAC address MAY be used as the MacDA. 🌈 By using that MacSA together with either that unicast MacDA or a group-addressed MacDA, an 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 ports are built like this (see Figure 9): 0xFEFF, the nickname of the TRILL switch used in TRILL Hellos sent on that port, and the Port ID that the TRILL switch has assigned to that port. (Both the Port ID of the port where a TRILL Hello is sent and the nickname of the sending TRILL switch show up in the Special VLANs and Flags sub-TLV [RFC7176] in TRILL IS-IS Hellos.) The resulting MAC address has the Local bit on and the Group bit off [RFC7042]. However, since there will be no Ethernet end stations on a non-Ethernet link in a TRILL campus, these synthetic MAC addresses cannot conflict on the link with a real Ethernet port address, no matter their values. 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFEFF | Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Synthetic MAC Address4. Extended RBridge Channel Security 🔐
Table 2 below lists the assigned values of the SType (Security Type) field and what they mean. Use of DTLS Pairwise Security (SType = 2) or Composite Security (SType = 3) is RECOMMENDED.
While IS-IS CRYPTO_AUTH-based authentication is also specified and can be used for both pairwise and multi-destination traffic, it only provides authentication and is not considered to meet current security standards. For example, it does not provide for key negotiation, so its use is NOT RECOMMENDED.
The Extended RBridge Channel DTLS-based security specified in Section 4.4 and the Composite Security specified in Section 4.5 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.
Multi-destination Extended RBridge Channel packets are those with the M bit in the TRILL Header set to one or, in the native RBridge Channel case, where the Outer.MacDA is 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. A true group keyed SType to secure multi-destination packets is intended to be specified in a separate document [GroupKey]. 💖
SType Description Reference
----- ----------- ---------
0 None Section 4.2 of RFC 7978
1 IS-IS CRYPTO_AUTH-Based Section 4.3 of RFC 7978
Authentication
2 DTLS Pairwise Security Section 4.4 of RFC 7978
3 Composite Security Section 4.5 of RFC 7978
4-14 Unassigned
15 Reserved
Table 2: SType Values4.1. Derived Keying Material 🗝️
In some cases, it is possible to use material derived from IS-IS CRYPTO_AUTH keying material [RFC5310] 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:
Derived Material =
HKDF-Expand-SHA256 ( IS-IS-key, "Extended Channel" | 0x0S, L )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. 🍬
Whenever IS-IS keying material is being used as above, the underlying IS-IS CRYPTO_AUTH keying material [RFC5310] 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 IS-IS CRYPTO_AUTH keying material. 💀
4.2. SType None 🙈
No security services are being invoked. The length of the Security Information field (see Figure 4) is zero. ✨
4.3. IS-IS CRYPTO_AUTH-Based Authentication ✨
okay so this SType gives Extended RBridge Channel messages the same kind of protection that the [IS-IS] Authentication TLV gives [IS-IS] PDUs 🔐 bestie, it's giving déjà vu. The Security Information (see Figure 4) looks like Figure 10 🎀
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)
+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 10: SType 1 Security InformationRESV: Four bits that MUST be sent as zero and ignored on receipt. 🫶Size: Set to 2 + the size of Authentication Data in bytes.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. 🗝️Authentication Data: The authentication data produced by the 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. 🧮
As shown in Figure 11, 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. 👀
+-----------------------------+
| Link Header |
+-----------------------------+
| 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 |
+-----------------------------+
Figure 11: SType 1 Authentication CoverageIn 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 12). 🌸
+-----------------------------+
| Ethernet Header |
+-----------------------------+ ^
| RBridge Channel Header | |
+-----------------------------+ .
| Extended Channel Header | | <-authentication
| (plus Security Information)| .
+-----------------------------+ |
| Payload | .
+-----------------------------+ v
| Ethernet Trailer |
+-----------------------------+
Figure 12: Native SType 1 Authentication CoverageRBridges are IS-IS routers, so it's reasonable to expect them to hold IS-IS CRYPTO_AUTH keying material [RFC5310]. That means this SType can be used for RBridge Channel messages that go between RBridges 🛜 How end stations might come to hold IS-IS CRYPTO_AUTH keying material is beyond the scope of this document, so this SType might not be applicable to native RBridge Channel messages, which are between an RBridge and an end station. 🙈
4.4. DTLS Pairwise 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.
When DTLS pairwise security is used, the entire payload of the Extended RBridge Channel packet, starting just after the null Security Information and ending just before the link trailer, is one or more DTLS records [RFC6347]. As specified in [RFC6347], DTLS records MUST be limited by the path MTU, so that in this case each record 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. 🧁
The DTLS Pairwise keying is set up between a pair of RBridges, independent of Data Label. It uses messages of a priority configurable at the RBridge level, which defaults to priority 6. DTLS message types other than application_data can be the payload of an extended RBridge Channel message with a TRILL Header using any Data Label. For those DTLS message types, the PType in the RBridge Channel Header Extension is ignored. 💅
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 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 are out of scope for this document. 📜
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 Key ID as defined in [RFC5310], 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 endpoints. Otherwise, security could be attacked by diverting messages to another endpoint holding that pre-shared key. 🚨
4.5. Composite Security 🎀
Composite Security (SType = 3) is the combination of DTLS Pairwise Security and IS-IS CRYPTO_AUTH-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 IS-IS CRYPTO_AUTH-based authentication is verified first, and an error is returned if it fails. If the IS-IS CRYPTO_AUTH-based authentication succeeds, then the DTLS record or records are processed. 🔄
An advantage of Composite Security is that the payload is authenticated and encrypted with a modern security protocol. In addition, the RBridge Channel Header and (except in the native case) preceding the MAC addresses and Data Label are provided with some authentication. Bestie, that's a lot of protection 🦋
5. Extended RBridge Channel Errors 🚨
RBridge Channel Header Extension errors are reported like RBridge Channel errors. The ERR field is set to one of the following error codes:
Value RBridge Channel Error Code Meaning
----- ------------------------------------
6 Unknown or unsupported field value
7 Authentication failure
8 Error in nested RBridge Channel message
Table 3: Additional ERR Values5.1. SubERRs 🧩
If the ERR field is 6, the SubERR field indicates the problematic field or value as shown in the table below. At this time, no suberror codes are assigned under any other ERR field value.
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
Table 4: SubERR Values5.2. Secure Nested RBridge Channel Errors 🪆
If:
- an extended RBridge Channel message is sent with security and with 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 field,
then that returned message SHOULD also be nested in an extended RBridge Channel message using the same type of security. In this 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 tunneled back. 💌
6. IANA Considerations 🌈
6.1. Extended RBridge Channel Protocol Number 🍓
IANA has assigned 0x004 from the range assigned by Standards Action [RFC5226] as the RBridge Channel protocol number to indicate RBridge Channel Header Extension.
The added "RBridge Channel Protocols" registry in the TRILL Parameters registry is as follows:
Protocol Description Reference
-------- -------------------------- ----------------
0x004 RBridge Channel Extension RFC 79786.2. RBridge Channel Protocol Subregistries 🗂️
IANA has created three subregistries under the "RBridge Channel Protocols" registry, as detailed in the subsections below.
6.2.1. RBridge Channel Error Codes 🧾
IANA has assigned three additional code points in the "RBridge Channel Error Codes" subregistry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The additional entries are as shown in Table 3 in Section 5, and the "Reference" column value is "RFC 7978" for those rows.
6.2.2. RBridge Channel SubError Codes 👑
IANA has created a subregistry indented under the "RBridge Channel Error Codes" registry, for RBridge Channel SubError Codes. The initial contents of this subregistry are shown in Table 4 in Section 5.1, and the fourth column "Reference" includes value "RFC 7978" for all rows. The header information is as follows:
Registry Name: RBridge Channel SubError Codes
Registration Procedures: IETF Review
Reference: RFC 79786.2.3. Extended RBridge Channel Payload Types Subregistry 🦋
okay so IANA got a brand new "Extended RBridge Channel Payload Types" subregistry 🎀 It lives right after the "RBridge Channel Protocols" registry, inside the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry. The header info is:
Registration Procedures: IETF Review
Reference: RFC 7978The starter content is Table 1 in Section 3 of this document 💜
6.2.4. Extended RBridge Channel Security Types Subregistry 🔐
same energy here ✨ IANA made an "Extended RBridge Channel Security Types" subregistry, placed after the "Extended RBridge Channel Payload Types" registry in that same TRILL Parameters registry. The header info:
Registration Procedures: IETF Review
Reference: RFC 7978The initial content is Table 2 in Section 4 of this document 🫶
7. Security Considerations 🔥
this section is giving drama and honestly it deserves it 💀 The RBridge Channel Header Extension has potentially positive and negative effects on security. It's a double-edged sparkly sword 🗡️✨
On the good side, it gives you optional security that can be used to authenticate and/or encrypt RBridge Channel messages 🛡️ Some payloads, like BFD [RFC7175], bring their own security. But where that isn't true, consideration should be given, when you're specifying an RBridge Channel protocol, to recommending or requiring use of the security features of the RBridge Channel Header Extension 💅
Now the not-so-cute side 😭 The optional ability to tunnel more payload types, and to tunnel them between TRILL switches and to and from end stations, can increase risk unless precautions are taken. Processing decapsulated extended RBridge Channel payloads is a place where you SHOULD NOT be liberal in what you accept 🙅♀️ The reason is that the tunneling facility makes it way easier for unexpected messages to pop up in unexpected places in a TRILL campus, whether by accident or because of an adversary 👀 Local policies SHOULD generally be strict: only accept the payload types you actually need, and only with adequate security for the particular circumstances 🔒
Strict is the vibe. If you're not sure a payload belongs, it doesn't get in 🚫
A few more bestie reminders 🧚 See the first paragraph of Section 4 for recommendations on SType usage. See [RFC7457] for security considerations of DTLS. If IS-IS authentication isn't being used, then IS-IS CRYPTO_AUTH keying material [RFC5310] wouldn't normally be available, but that presumably reflects a judgment by the TRILL campus operator that no security is needed 🤷♀️ And for the general stuff, check out [RFC7178] for general RBridge Channel security considerations and [RFC6325] for general TRILL security considerations 📚
8. Normative References 📖
these are the must-reads, all in one place 💜
[IS-IS] International Organization for Standardization,
"Information technology -- Telecommunications and
information exchange between systems -- Intermediate System
to Intermediate System intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service
(ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", RFC 4279,
DOI 10.17487/RFC4279, December 2005,
<http://www.rfc-editor.org/info/rfc4279>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic Authentication",
RFC 5310, DOI 10.17487/RFC5310,v February 2009,
<http://www.rfc-editor.org/info/rfc5310>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
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
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
D. Dutt, "Transparent Interconnection of Lots of Links
(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, D.,
and A. Banerjee, "Transparent Interconnection of Lots of
Links (TRILL) Use of IS-IS", RFC 7176,
DOI 10.17487/RFC7176, May 2014,
<http://www.rfc-editor.org/info/rfc7176>.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
Ward, "Transparent Interconnection of Lots of Links (TRILL):
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
Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014,
<http://www.rfc-editor.org/info/rfc7356>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection of
Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>.9. Informative References 🌸
extra reading if you want to go deeper 🧁
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent
Interconnection of Lots of Links (TRILL) Protocol Control
Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011,
<http://www.rfc-editor.org/info/rfc6361>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[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,
"Transparent Interconnection of Lots of Links (TRILL):
Bidirectional Forwarding Detection (BFD) Support",
RFC 7175, DOI 10.17487/RFC7175, May 2014,
<http://www.rfc-editor.org/info/rfc7175>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <http://www.rfc-editor.org/info/rfc7457>.
[AddrFlush]
Hao, W., Eastlake, D., and Y. Li, "TRILL: Address Flush
Message", Work in Progress, draft-ietf-trill-address-
flush-00, May 2016.
[GroupKey]
Eastlake, D., "TRILL: Group Keying", Work in Progress,
draft-eastlake-trill-group-keying-00, July 2016.
[TRILL-AF]
Eastlake, D., Li, Y., Umair, M., Banerjee, A., and F. Hu,
"TRILL: Appointed Forwarders", Work in Progress,
draft-ietf-trill-rfc6439bis-03, August 2016.Acknowledgements 💖
huge thank-yous to these legends 🫶 Stephen Farrell, Jonathan Hardwick, Susan Hares, Gayle Noble, Alvaro Retana, Yaron Sheffer, and Peter Yee. You're the real MVPs 👑
Authors' Addresses 💜
the people who made this happen 🧚
Donald E. Eastlake, 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Mohammed Umair
IPinfusion
Email: mohammed.umair2@gmail.com
Yizhou Li
Huawei Technologies
101 Software Avenue
Nanjing 210012
China
Phone: +86-25-56622310
Email: liyizhou@huawei.com📦 where this page comes from
- ietf: rfc7978 2016-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms