Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension
updates
- rfc-7178 — Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support
Extracted elements (30)
Composite Security (SType = 3) is defined because it provides complementary coverage: DTLS secures the payload with modern authenticated encryption and key negotiation, while the outer IS-IS CRYPTO_AUTH layer also authenticates the RBridge Channel Header and (in non-native cases) the preceding MAC addresses and Data Label, which DTLS alone cannot cover.
DTLS Pairwise Security and Composite Security are designed exclusively for pairwise (unicast) use. For multi-destination delivery, the specification requires serial unicasting to each data-accessible RBridge in the recipient group, with a note that a true group-keyed SType for multicast/broadcast will be defined in a separate document.
The header extension is implemented as an RBridge Channel protocol (assigned protocol number 0x004) rather than as a new Ethertype or framing layer. This design makes it easy to determine whether a remote RBridge supports the extension, because RBridges advertise in their IS-IS LSP which RBridge Channel protocols they support.
IS-IS CRYPTO_AUTH-Based Authentication (SType = 1) is applicable to RBridge-to-RBridge extended RBridge Channel messages because RBridges are IS-IS routers and can be expected to hold IS-IS keying material. However, how end stations would obtain such material is out of scope, so this SType may not be usable for native RBridge Channel messages between an RBridge and an end station.
A TRILL switch supporting the RBridge Channel Header Extension MUST support PType 2 (Ethertyped Payload) with the RBridge-Channel Ethertype (0x8946) as the leading Ethertype of the payload (i.e., an encapsulated nested RBridge Channel message).
DTLS records used in the DTLS Pairwise SType MUST be limited by the path MTU so that each record fits entirely within a single Extended RBridge Channel message.
If the RBridge Channel ERR field is zero, the SubERR field MUST be sent as zero and ignored on receipt.
If the RBridge Channel Header Extension is implemented, PType 1 (Null) MUST be implemented in the sense that an 'Unsupported PType' error is not returned for it.
Local policies SHOULD generally be strict and only accept payload types that are required, and then only with adequate security for the particular circumstances. The processing of decapsulated extended RBridge Channel payloads is explicitly identified as a place where implementations SHOULD NOT be liberal in what they accept.
The DTLS version negotiated for the extended RBridge Channel DTLS Pairwise SType MUST NOT be less than 1.2.
The RBridge Channel Header Protocol field MUST contain the value allocated for the Extended RBridge Channel protocol (0x004) to indicate that the header extension is present.
The RESV4 nibble MUST be sent as zero. If received as non-zero, this constitutes an error condition reportable via ERR=6, SubERR=1.
TRILL switches supporting the extended RBridge Channel DTLS Pairwise SType MUST support the use of pre-shared keys. If the psk_identity is two bytes, it is treated as a Key ID (RFC 5310) and the value derived via HKDF (Section 4.1) is used as the pre-shared key.
Use of DTLS Pairwise Security (SType = 2) or Composite Security (SType = 3) is RECOMMENDED. IS-IS CRYPTO_AUTH-Based Authentication (SType = 1) is NOT RECOMMENDED because it provides only authentication without key negotiation and does not meet current security standards.
When an extended RBridge Channel message is sent with security and an Ethertyped payload containing a nested RBridge Channel message, any error response for the nested message SHOULD itself be nested in an extended RBridge Channel message using the same type of security, with ERR=8 in the outer envelope.
When IS-IS CRYPTO_AUTH keying material expires or is invalidated, use of any Derived Material produced from that keying material MUST cease at or before the time of expiration or invalidation.
Composite Security (SType = 3) combines DTLS Pairwise Security and IS-IS CRYPTO_AUTH-Based Authentication. On transmission, the payload is first secured via DTLS (Section 4.4), then IS-IS CRYPTO_AUTH authentication (Section 4.3) is applied over the result. On reception, IS-IS authentication is verified first; only on success are the DTLS records processed.
DTLS Pairwise Security (SType = 2) encapsulates the entire Extended RBridge Channel payload—from just after the null Security Information to just before the link trailer—as one or more DTLS records (RFC 6347). The DTLS session is established pairwise between two RBridges, independent of Data Label, at configurable priority (default 6).
Key derivation from IS-IS CRYPTO_AUTH material uses HKDF-Expand-SHA256(IS-IS-key, "Extended Channel" | 0x0S, L), where 0x0S is a single byte with the SType in the lower nibble. This derived material is used instead of raw IS-IS keys for both IS-IS CRYPTO_AUTH-Based and Composite security types.
The PType (Payload Type) field indicates the tunneled data format. Defined values are: 0 (Reserved), 1 (Null — no user data), 2 (Ethertyped Payload — payload begins with an Ethertype), 3 (Ethernet Frame — encapsulated Ethernet frame without FCS), 4–14 (Unassigned), 15 (Reserved).
The SType (Security Type) field describes the security services applied to the extended RBridge Channel message. Defined values are: 0 (None), 1 (IS-IS CRYPTO_AUTH-Based Authentication), 2 (DTLS Pairwise Security), 3 (Composite Security = DTLS + IS-IS CRYPTO_AUTH), 4–14 (Unassigned), 15 (Reserved).
IANA assigned RBridge Channel protocol number 0x004 (from the Standards Action range) to indicate the RBridge Channel Header Extension. This entry appears in the 'RBridge Channel Protocols' registry within the TRILL Parameters registry.
IANA created the 'Extended RBridge Channel Payload Types' subregistry (registration procedure: IETF Review) with initial values: 0 (Reserved), 1 (Null), 2 (Ethertyped Payload), 3 (Ethernet Frame), 4–14 (Unassigned), 15 (Reserved).
IANA created the 'Extended RBridge Channel Security Types' subregistry (registration procedure: IETF Review) with initial values: 0 (None), 1 (IS-IS CRYPTO_AUTH-Based Authentication), 2 (DTLS Pairwise Security), 3 (Composite Security), 4–14 (Unassigned), 15 (Reserved).
IANA created the 'RBridge Channel SubError Codes' subregistry (registration procedure: IETF Review) under the existing 'RBridge Channel Error Codes' registry. SubERR values are defined only for ERR=6 (Unknown or unsupported field value): 0 (Reserved), 1 (Non-zero RESV4), 2 (Unsupported SType), 3 (Unsupported PType), 4 (Unknown Key ID), 5 (Unsupported Ethertype with PType=2), 6 (Unsupported authentication algorithm for SType=1), 7 (Non-zero SubERR with zero ERR). IANA also assigned ERR codes 6, 7, and 8 in the existing Error Codes registry.
IS-IS CRYPTO_AUTH-Based Authentication (SType = 1) provides only authentication, lacks key negotiation, and is not considered to meet current security standards. It may also not be usable for native RBridge Channel messages (between an RBridge and an end station) because end stations do not normally hold IS-IS CRYPTO_AUTH keying material.
The tunneling facility in the RBridge Channel Header Extension increases risk by making it easier for unexpected messages to appear in unexpected places within a TRILL campus, either through accidents or adversarial action. Strict local acceptance policies limiting payload types and requiring appropriate security are essential mitigations.
Synthetic 48-bit MAC addresses for non-Ethernet TRILL ports are constructed as: 0xFEFF (2 bytes) | Nickname of the TRILL switch (2 bytes) | Port ID assigned by the TRILL switch (2 bytes). The resulting address has the Local bit set and the Group bit clear.
The Extended RBridge Channel header extension occupies the Channel-Protocol-Specific Data area when Channel Protocol equals 0x004. It contains four nibble-sized fields: SubERR (4 bits), RESV4 (4 bits), SType (4 bits), and PType (4 bits), followed by variable-length Security Information and variable-length Tunneled Data.
The SType 1 (IS-IS CRYPTO_AUTH-Based) Security Information field begins with a 4-bit RESV and 12-bit Size (set to 2 plus the byte length of Authentication Data), followed by a 2-byte Key ID, followed by variable-length Authentication Data whose length depends on the algorithm.