RFC 8384

Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes

📅 published July 2018, from ietf

okay bestie, let's get the basics down first 💅 This is RFC 8384, published by the IETF in July 2018. It's on the Standards Track, so it's a real official spec and not just a draft vibe 👑 Its ISSN is 2070-1721. The authors are R. Perlman from Dell EMC, F. Hu from ZTE Corporation, D. Eastlake 3rd, and T. Liao from Huawei Technologies. The header doesn't list anything it obsoletes or updates, so no drama there ✨

Abstract 🌸

okay so the big problem here is the size and freshness of the endnode learning table in edge Routing Bridges (RBridges) 😩 The fix is to let endnodes volunteer for endnode learning and encapsulation/decapsulation. These volunteer endnodes are called "Smart Endnodes" 🧚 Only the attached edge RBridge can tell a "Smart Endnode" apart from a "normal endnode." A Smart Endnode uses the nickname of its attached edge RBridge, so this solution doesn't burn through extra nicknames. It also works for endnodes that are Fine-Grained Label (FGL) aware 💜

Status of This Memo 📜

this is an Internet Standards Track document ✨

it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶 If you want more on Internet Standards, check out Section 2 of RFC 7841.

for the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8384 🔗

Copyright (c) 2018 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 (https://trustee.ietf.org/license-info), as in effect on the date this document was published 📖 Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅

Table of Contents 📖

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
  2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
  2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   4
4.  Smart-Hello Mechanism between Smart Endnode and RBridge . . .   6
  4.1.  Smart-Hello Encapsulation . . . . . . . . . . . . . . . .   6
  4.2.  Edge RBridge's Smart-Hello  . . . . . . . . . . . . . . .   8
  4.3.  Smart Endnode's Smart-Hello . . . . . . . . . . . . . . .   8
5.  Processing Data Packets . . . . . . . . . . . . . . . . . . .  10
  5.1.  Data-Packet Processing for Smart Endnodes . . . . . . . .  10
  5.2.  Data-Packet Processing for Edge RBridge . . . . . . . . .  11
6.  Multihoming Scenario  . . . . . . . . . . . . . . . . . . . .  12
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction 🧚

okay so the TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC7780] gives you optimal pair-wise data frame forwarding with zero configuration 🤩 It also keeps forwarding safe even during temporary loops, and it supports multipathing for both unicast and multicast traffic. How does it pull this off? It uses IS-IS [IS-IS] [RFC7176] link state routing and wraps traffic in a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges) or "TRILL Switches" 💖

an RBridge that attaches to endnodes is called an "edge RBridge" or "edge TRILL Switch," while one that only forwards encapsulated frames is a "transit RBridge" or "transit TRILL Switch" 🌈 Traditionally, the edge RBridge is the one that wraps a native Ethernet frame in a TRILL header, or receives a TRILL-encapsulated packet and unwraps the TRILL header. To encapsulate efficiently, the edge RBridge has to keep an "endnode table" made of (Media Access Control (MAC), Data Label, TRILL egress switch nickname) sets. These are for remote MAC addresses, in Data Labels, that are currently talking to endnodes attached to the edge RBridge 👀

those table entries might be configured, received from End Station Address Distribution Information (ESADI) [RFC7357], looked up in a directory [RFC7067], or learned from decapsulating received traffic. If the edge RBridge has attached endnodes talking to lots of remote endnodes, this table could get super huge 😭 Also, if a MAC address / Data Label pair in the table has moved to a different remote TRILL switch, the edge RBridge might have a hard time noticing quickly. And because it's encapsulating toward the wrong egress RBridge, the traffic gets lost 💀

2. Conventions Used in This Document 💜

2.1. Terminology 🎀

here's the glossary, bestie 🫶

  • BUM: Broadcast, Unknown unicast, and Multicast.
  • Edge RBridge: An RBridge providing endnode service on at least one of its ports. It is also called an edge TRILL Switch.
  • Data Label: VLAN or FGL.
  • DRB: Designated RBridge [RFC6325].
  • ESADI: End Station Address Distribution Information [RFC7357].
  • FGL: Fine-Grained Label [RFC7172].
  • IS-IS: Intermediate System to Intermediate System [IS-IS].
  • LSP: Link State PDU.
  • PDU: Protocol Data Unit.
  • RBridge: Routing Bridge, an alternative name for a TRILL switch.
  • Smart Endnode: An endnode that has the capability specified in this document, including learning and maintaining (MAC, Data Label, nickname) entries and encapsulating/decapsulating TRILL frame.
  • Transit RBridge: An RBridge that exclusively forwards encapsulated frames. It is also called a transit TRILL Switch.
  • TRILL: Transparent Interconnection of Lots of Links [RFC6325][RFC7780].
  • TRILL ES-IS: TRILL End System to Intermediate System, a variation of TRILL IS-IS designed to run on a TRILL link among and between one or more TRILL switches and end stations on that link [RFC8171].
  • TRILL Switch: a device that implements the TRILL protocol; an alternative term for an RBridge.

2.2. Requirements Language 🔥

the BCP 14 key words are the ones that carry the real weight in here, so read this part carefully 🧐 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 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅

3. Solution Overview 🍓

the Smart Endnode solution in this document goes after the size and freshness problem of the endnode learning table in edge RBridges 🌸 Here's how it works: an endnode E, attached to an edge RBridge R, tells R that E would like to be a "Smart Endnode." That means E will encapsulate and decapsulate the TRILL frame using R's nickname. Since E borrows R's nickname, this solution doesn't use up extra nicknames ✨

check out Figure 1 for the example Smart Endnode scenario 👀 RB1, RB2, and RB3 are the RBridges in the TRILL domain, and SE1 and SE2 are the Smart Endnodes that can encapsulate and decapsulate the TRILL packets. RB1 is the edge RB that SE1 and SE2 are attached to. RB1 assigns one of its nicknames for SE1 and SE2 to use.

 +----------+
 |SE1(Smart |
 |Endnode1) |  \      +------------------------------+
 +----------+   \    /                                \
                 \  /+------+   +------+    +-----+    \   +-----------+
                 /-+-| RB 1 |---|  RB2 |----| RB3 |-----+--|Endnode3   |
                /  | +------+   +------+    +-----+     |  |MAC=D      |
 +----------+ /     \                                  /   +-----------+
 |SE2(Smart |        \                                /
 | Endnode2)|         +------------------------------+
 +----------+

                     Figure 1: Smart Endnode Scenario

each Smart Endnode, SE1 and SE2, uses RB1's nickname when it encapsulates, and it keeps an endnode table of (MAC, Data Label, TRILL egress switch nickname) for the remote endnodes it's talking to 🧚 RB1 doesn't decapsulate packets destined for SE1 or SE2, and it doesn't learn (MAC, Data Label, TRILL egress switch nickname) for endnodes talking to SE1 or SE2. BUT RB1 does decapsulate and does learn that info for any endnodes attached to RB1 that haven't declared themselves Smart Endnodes 💀

just like an RBridge learns and times out (MAC, Data Label, TRILL egress switch nickname), SE1 and SE2 also learn and time out endnode entries. The difference is that SE1 and SE2 might also figure out, through ICMP messages or other techniques, that an endnode entry isn't reaching the destination endnode successfully. When that happens, the entry can be deleted, even if it hasn't timed out yet 🙈

if SE1 wants to talk to destination MAC D and there's no endnode entry for it, SE1 will encapsulate the packet as an unknown destination, or consult a directory [RFC7067] (just like an RBridge would if there were no endnode entry) 🫶

here's the mechanism in a nutshell: the Smart Endnode SE1 issues a Smart-Hello, saying it wants to act as a Smart Endnode, along with the set of MAC addresses and Data Labels that SE1 owns 💖 The Smart-Hello is how the Smart Endnode announces its capability and parameters (like MAC address, Data Label, and so on). The Smart-Hello is a type of TRILL ES-IS PDU, specified in Section 5 of [RFC8171]. The detailed content of a Smart Endnode's Smart-Hello is defined in Section 4 ✨

if RB1 supports having a Smart Endnode neighbor, it sends Smart-Hellos too 🌈 The Smart Endnode learns from RB1's Smart-Hellos what RB1's nickname is, and which trees RB1 can use when RB1 ingresses multi-destination frames. Even though SE1 transmits Smart-Hellos, it does not transmit or receive Link State PDUs (LSPs) or Extended Level 1 Flooding Scope (E-L1FS) FS LSPs [RFC7780] 🔥

since a Smart Endnode can encapsulate TRILL Data packets, it can cause the Inner.Label to be a Fine-Grained Label [RFC7172], so this method supports FGL-aware endnodes 👑 When and how a Smart Endnode decides to use the FGL instead of VLANs to encapsulate the TRILL Data packet is out of scope for this document 🙈

4. Smart-Hello Mechanism between Smart Endnode and RBridge 💖

next up, the subsections below dig into Smart-Hello messages 🦋

4.1. Smart-Hello Encapsulation ✨

okay bestie, so a Smart Endnode isn't an RBridge 🙈 it doesn't send LSPs, doesn't keep a copy of the link state database, and doesn't do routing calculations. but it is still required to have a "Hello" mechanism so it can (1) tell edge RBridges that it's a Smart Endnode and (2) tell them which MAC addresses it's handling in which Data Labels 🎀 edge RBridges that support Smart Endnodes need their own message too, to (1) announce that support, (2) tell Smart Endnodes which nickname to use for ingress and which nickname(s) can be used as egress nickname in a multi-destination TRILL Data packet, and (3) share the list of Smart Endnodes they know about on that link 💅

the messages sent by Smart Endnodes and by edge RBridges that support Smart Endnodes are called "Smart-Hellos" 🦋 a Smart-Hello is a type of TRILL ES-IS PDU, which is specified in [RFC8171].

the Smart-Hello Payload, for Smart-Hellos from Smart Endnodes and from edge RBridges, is made of TRILL IS-IS TLVs (more on those in the next two subsections 🧚). the non-extended format is used, so TLVs, sub-TLVs, and APPsub-TLVs have an 8-bit size and type field. both types of Smart-Hellos MUST include a Smart-Parameters APPsub-TLV inside a TRILL GENINFO TLV, like this:

             +-+-+-+-+-+-+-+-+-
             |Smart-Parameters|                 (1 byte)
             +-+-+-+-+-+-+-+-+-
             |    Length      |                 (1 byte)
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |        Holding Time           |  (2 bytes)
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |             Flags             |  (2 bytes)
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Smart-Parameters APPsub-TLV

  • Type: APPsub-TLV type Smart-Parameters, value is 22. 🌸
  • Length: 4. ✨
  • Holding Time: a time in seconds as an unsigned integer. it has the same meaning as the Holding Time field in IS-IS Hellos [IS-IS]. a Smart Endnode and an edge RBridge supporting Smart Endnodes MUST send a Smart-Hello at least three times during their Holding Time. if no Smart-Hellos are received from a Smart Endnode or edge RBridge within the most recent Holding Time it sent, it's assumed that it's no longer available 😭
  • Flags: at this time, all of the Flags are reserved and MUST be sent as zero and ignored on receipt. no vibes, just zeros 🙈
  • if more than one Smart-Parameters APPsub-TLV appears in a Smart-Hello, the first one is used and any following ones are ignored. if no Smart-Parameters APPsub-TLVs appear in a Smart-Hello, that Smart-Hello is ignored 💀

4.2. Edge RBridge's Smart-Hello 🍓

the edge RBridge's Smart-Hello contains the following info in addition to the Smart-Parameters APPsub-TLV:

  • RBridge's nickname. the nickname sub-TLV, specified in Section 2.3.2 in [RFC7176], is reused here, carried inside a TLV 242 (IS-IS router capability) in a Smart-Hello frame. if more than one nickname appears in the Smart-Hello, the first one is used and the following ones are ignored. 👑
  • Trees that RB1 can use when ingressing multi-destination frames. the Tree Identifiers sub-TLV, specified in Section 2.3.4 in [RFC7176], is reused here. 🌈
  • Smart Endnode neighbor list. the TRILL Neighbor TLV, specified in section 2.5 in [RFC7176], is reused for this purpose. 🫶
  • An Authentication TLV MAY also be included. ✨

4.3. Smart Endnode's Smart-Hello 💜

a new APPsub-TLV (Smart-MAC TLV) for use by Smart Endnodes is defined below. in addition, there will be a Smart-Parameters APPsub-TLV, and there MAY be an Authentication TLV in a Smart Endnode Smart-Hello. 🦋

if there are several VLANs/FGL Data Labels for that Smart Endnode, the Smart-MAC APPsub-TLV is included several times in the Smart Endnode's Smart-Hello. this APPsub-TLV appears inside a TRILL GENINFO TLV.

    +-+-+-+-+-+-+-+-+
    |Type=Smart-MAC |                          (1 byte)
    +-+-+-+-+-+-+-+-+
    |   Length      |                          (1 byte)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |F|M|   RSV     |  VLAN/FGL Data Label  |  (4 bytes)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          MAC (1)       (6 bytes)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      .................                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          MAC (N)       (6 bytes)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Smart-MAC APPsub-TLV

  • Type: TRILL APPsub-TLV Type Smart-MAC, value is 23. 🎀
  • Length: total number of bytes contained in the value field of the TLV, that is, the sum of the length of the F/M/RSV/FGL Data Label fields and six times the number of MAC addresses present. so, if there are n MAC addresses, this is 4+6*n. 🧮
  • F: 1 bit. if it is set to 1, it indicates that the endnode supports FGL Data Labels [RFC7172], and that this Smart-MAC APPsub-TLV has an FGL in the following VLAN/FGL field. otherwise, the VLAN/FGL Data Label field is a VLAN ID. (see below for the format of the VLAN/FGL Data Label field).
  • M: 1 bit. if it is set to 1, it indicates multihoming (see Section 6). if it is set to 0, it indicates that the Smart Endnodes are not using multihoming.
  • RSV: 6 bits; reserved for future use. 🔒
  • VLAN/FGL Data Label: 24 bits. if F is 1, this field is a 24-bit FGL Data Label for all subsequent MAC addresses in this APPsub-TLV. otherwise, if F is 0, the lower 12 bits are the VLAN of all subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits are not used (sent as zero and ignored on receipt). if there is no VLAN/FGL Data Label specified, the VLAN/FGL Data Label is zero. 🌙
  • MAC(i): this is a 48-bit MAC address reachable in the Data Label sent by the Smart Endnode that is announcing this APPsub-TLV. 🧚

5. Processing Data Packets ✨

the subsections below specify how Smart Endnode data packets get processed. all TRILL Data packets sent to or from Smart Endnodes are sent in the Designated VLAN [RFC6325] of the local link, but they don't necessarily have to be VLAN tagged 💅

5.1. Data-Packet Processing for Smart Endnodes 🦋

a Smart Endnode doesn't issue or receive LSPs or E-L1FS FS LSPs, and it doesn't calculate topology. here's what it does:

  • a Smart Endnode maintains an endnode table of (the MAC address of remote endnode, Data Label, the nickname of the edge RBridge's attached) entries of end nodes it's communicating with. entries in this table get populated the same way an edge RBridge populates the entries in its table 🫶
    • learning from (source MAC address ingress nickname) on packets it decapsulates.
    • by querying a directory [RFC7067].
    • by having some entries configured.
  • when Smart Endnode SE1 wishes to send a unicast frame to remote node D, if the (MAC address of remote endnode D, Data Label, nickname) entry is in SE1's endnode table, SE1 encapsulates the ingress nickname as the nickname of the RBridge (RB1), and egress nickname as indicated in D's table entry. if D is unknown, SE1 either queries a directory or encapsulates the packet as a multi-destination frame, using one of the trees that RB1 has specified in RB1's Smart-Hello. the mechanism for querying a directory is given in [RFC8171]. 🔍
  • when SE1 wishes to send a Broadcast, Unknown Unicast, and Multicast (BUM) packet to the TRILL campus, SE1 encapsulates the packet using one of the trees that RB1 has specified. 📣

if the Smart Endnode SE1 sends a multi-destination TRILL Data packet, the destination MAC of the outer Ethernet is the All-RBridges multicast address. 🌸

the Smart Endnode SE1 need not send Smart-Hellos as frequently as normal RBridges do. these Smart-Hellos could be periodically unicast to the Appointed Forwarder RB1. in case RB1 crashes and restarts, or the DRB changes and SE1 receives the Smart-Hello without mentioning SE1, SE1 SHOULD send a Smart-Hello immediately ⚡ if RB1 is Appointed Forwarder for any of the VLANs that SE1 claims, RB1 MUST list SE1 in its Smart-Hellos as a Smart Endnode neighbor. 👑

5.2. Data-Packet Processing for Edge RBridge ✨

Okay so, the attached edge RBridge handles TRILL Data packets based on the endnode property, not just by encapsulating and forwarding native frames the way traditional RBridges do. 🦋 There are a few situations for edge RBridges, and they go like this:

  • Say an edge RBridge gets an encapsulated unicast TRILL Data packet from a port with a Smart Endnode, and RB1's nickname is the ingress. RB1 forwards the frame to the specified egress nickname, just like any encapsulated frame. BUT RB1 SHOULD filter that encapsulated frame based on the inner source MAC and Data Label set for the Smart Endnode. If the MAC (or Data Label) isn't one of the expected entries for that Smart Endnode, the edge RBridge drops the frame. If the edge RBridge skips this check, a rogue end station finds it much easier to inject bogus TRILL Data packets into the TRILL campus. 🙈
  • Say RB1 gets a unicast TRILL Data packet from the TRILL campus with RB1's nickname as the egress, and the destination MAC address inside it is one that a Smart Endnode has listed. Then RB1 leaves the packet encapsulated and sends it on to that Smart Endnode. The outer Ethernet destination MAC is the destination Smart Endnode's MAC address. The inner destination MAC is either that Smart Endnode's MAC address or some other MAC address the Smart Endnode advertised in its Smart Hello. The outer Ethernet source MAC is RB1's port MAC address. The edge RBridge still decreases the Hop count value by 1, since there is one hop between RB1 and the Smart Endnode. 💅
  • Say RB1 gets a multi-destination TRILL Data packet from a port with a Smart Endnode. RBridge RB1 forwards the TRILL encapsulation into the TRILL campus, following the distribution tree that the egress nickname points to. If the egress nickname doesn't match any distribution tree, the packet gets discarded. 💀 If there are normal endnodes (meaning endnodes that aren't Smart Endnodes) attached to edge RBridge RB1, then RB1 decapsulates the frame and sends the native frame out to those ports, possibly pruned based on multicast listeners. It also forwards the multi-destination TRILL frame on to the rest of the campus. 🌸
  • Say RB1 gets a native multi-destination data frame from a port. The frame was sent by an endnode that is not a Smart Endnode. The port can include hybrid endnodes (Smart Endnodes and endnodes that aren't Smart Endnodes). RB1 encapsulates the frame as a multi-destination TRILL Data packet. It sends that packet back out the same port to the Smart Endnodes attached to it, and it also sends the encapsulated multi-destination TRILL Data packet into the TRILL campus through other ports. 🧚
  • Say RB1 gets a multi-destination TRILL Data packet from a remote RBridge, and the exit port has hybrid endnodes (Smart Endnodes and endnodes that aren't Smart Endnodes). Then RB1 sends two copies of the multicast frame out that port: one native and one TRILL-encapsulated. 🎀 When a Smart Endnode gets a multi-destination TRILL Data packet, it learns the remote (MAC address, Data Label, nickname) entry, and it ignores native data frames. A normal (non-Smart) endnode gets the native frame, learns the remote MAC address, and ignores the TRILL Data packet. This transit solution can get a bit messy for the edge RBridge and wastes network bandwidth. So keeping things clean by attaching the Smart and non-Smart endnodes to different ports is RECOMMENDED. 👑

6. Multihoming Scenario 🌈

Multihoming is a super common scenario for the Smart Endnode. The Smart Endnode is on a link attached to the TRILL domain in two places: edge RBridges RB1 and RB2. Check out Figure 4 for the picture. Smart Endnode SE1 is attached to the TRILL domain through RB1 and RB2 separately, and both RB1 and RB2 could announce their nicknames to SE1. 🦋

                        . .....................
                        .  +------+           .
                        .  | RB1  |           .
                        . /+------+           .
           +----------+ ./            +-----+ .    +----------+
           |SE1(Smart |/.             | RB3 |......| Smart    |
           | Endnode1)| .\            +-----+ .    | Endnode2 |
           +----------+ . \                   .    +----------+
                        .  +-----+            .
                        .  | RB2 |   TRILL    .
                        .  +-----+   Domain   .
                        .......................

Figure 4: Multihoming Scenario

So SE1 can pick either RB1's nickname or RB2's nickname when it encapsulates and forwards a TRILL Data packet. ✨ If you want active-active load balancing in the multihoming setup, SE1 can use both RB1's nickname and RB2's nickname to encapsulate and forward TRILL Data packets. SE1 uses RB1's nickname when it forwards through RB1, and RB2's nickname when it forwards through RB2. 😭 The catch is that this causes MAC flip-flopping (see [RFC7379]) of the endnode table entry in the remote RBridges (or Smart Endnodes). The fix for MAC flip-flopping is to set a multihoming bit in the RSV field of the TRILL Data packet. When remote RBridge RB3 or a Smart Endnode gets a data packet with the multihomed bit set, the endnode entries (SE1's MAC address, label, RB1's nickname) and (SE1's MAC address, label, RB2's nickname) can coexist as endnode entries in the remote RBridge. 🫶 (An alternative would be to use the ESADI protocol to distribute multiple attachments of a MAC address in a multihoming group. ESADI is deployed among the edge RBridges, see Section 5.3 of [RFC7357].)

7. Security Considerations 🔐

Okay, this section is serious, bestie. Read it all. 💜

Smart-Hellos can be secured by using Authentication TLVs based on [RFC5310]. If they aren't secured, it becomes much easier for a rogue end station that doesn't possess the required keying material to be falsely recognized as a valid Smart Endnode. 🚨

For general TRILL Security Considerations, see [RFC6325]. As that document explains, end stations connect to edge RBridge ports over Ethernet, so those ports MAY require end stations to authenticate themselves using [IEEE802.1X], and they can authenticate and encrypt traffic to and from the RBridge port with [IEEE802.1AE]. 🔒

If they misbehave, Smart Endnodes can forge arbitrary ingress and egress nicknames in the TRILL headers of the TRILL Data packets they build. Decapsulating at egress RBridges or remote Smart Endnodes that trust such a forged ingress nickname would send future traffic destined for the inner-source MAC address of the TRILL data frame to the wrong edge RBridge, if data-plane learning is in use. Because of this, an RBridge port should not be configured to support Smart Endnodes unless the end stations on that link are trusted or can be adequately authenticated. 😤

As with any end station, Smart Endnodes can forge the outer MAC addresses of packets they send (see Section 6 of [RFC6325].) Since they encapsulate TRILL Data packets, they can also forge inner MAC addresses. The encapsulation Smart Endnodes perform also means they can send data in any Data Label, which means they must be trusted if you want to enforce a security policy based on Data Labels. 🙃

The TRILL-Hello is a type of TRILL ES-IS and is defined in [RFC8171]. Receiving and processing TRILL-Hello for RBridges and Smart Endnodes wouldn't bring any more security and vulnerability issues than the TRILL ES-IS security defined in [RFC8171]. 👍

For extra protection against data being compromised because it was misdelivered for any reason (including the ones above), end-to-end encryption and authentication should be considered. That means encryption and authentication from the source end station all the way to the destination end station. 🔑

The mechanism described in this document requires Smart Endnodes to know the MAC address(es) of the TRILL edge RBridge(s) they're attached to, and the egress RBridge nickname that the destination of the packets can be reached from. With that information, Smart Endnodes can learn a substantial amount about the topology of the TRILL domain. So there could be a real security risk when Smart Endnodes aren't trusted or have been compromised. 🚩

8. IANA Considerations 🧾

IANA has allocated APPsub-TLV type numbers for the Smart-MAC and Smart-Parameters APPsub-TLVs. The "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry has been updated as shown in Table 1. 🌸

          +-----------+-------------------+------------+
          |  Protocol |    Description    | Reference  |
          +-----------+-------------------+------------+
          |     22    |  Smart-Parameters |  RFC 8384  |
          |     23    |     Smart-MAC     |  RFC 8384  |
          +-----------+-------------------+------------+

Table 1

9. References 📚

9.1. Normative References

Okay bestie, these are the must-read docs 📚 You literally can't implement this without them 🫶

[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.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[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, February 2009, <https://www.rfc-editor.org/info/rfc5310>.

[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, <https://www.rfc-editor.org/info/rfc6325>.

[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, <https://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, <https://www.rfc-editor.org/info/rfc7176>.

[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <https://www.rfc-editor.org/info/rfc7357>.

[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, <https://www.rfc-editor.org/info/rfc7780>.

[RFC8171] Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms", RFC 8171, DOI 10.17487/RFC8171, June 2017, <https://www.rfc-editor.org/info/rfc8171>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

Now the extra-credit reading 🌈 Not required, but lowkey worth a look if you want the backstory 🦋

[IEEE802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Security", IEEE 802.1AE.

[IEEE802.1X] IEEE, "IEEE Standard for Local and metropolitan area networks -- Port-Based Network Access Control", IEEE 802.1X.

[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, <https://www.rfc-editor.org/info/rfc7067>.

[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <https://www.rfc-editor.org/info/rfc7379>.

Acknowledgements 🫶

Huge shoutout to these legends who helped make this happen 💜 Thank you, Mingui Zhang, Weiguo Hao, Linda Dunbar, Kesava Vijaya Krupakaran, and Andrew Qu! ✨

Authors' Addresses 💅

Radia Perlman, all the way from Dell EMC 🎀

Radia Perlman
Dell EMC
176 South Street
Hopkinton, MA  01748
United States of America

Phone: +1-206-291-367
Email: radiaperlman@gmail.com

Next up is Fangwei Hu at ZTE Corporation 🌸

Fangwei Hu
ZTE Corporation
No.889 Bibo Rd
Shanghai  201203
China

Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn

Donald Eastlake, repping Huawei Technologies 🦋

Donald Eastlake
Huawei Technologies
1424 Pro Shop Court
Davenport, FL 33896
United States of America

Phone: +1-508-333-2270
Email: d3e3e3@gmail.com

And last but absolutely not least, Ting Liao, also at Huawei Technologies 🧚

Ting Liao
Huawei Technologies
Nanjing, Jiangsu  210012
China

Email: liaoting1@huawei.com
📦 where this page comes from