Internet Engineering Task Force (IETF) R. Perlman Request for Comments: 8384 Dell EMC Category: Standards Track F. Hu ISSN: 2070-1721 ZTE Corporation D. Eastlake 3rd T. Liao Huawei Technologies July 2018 Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes
AbstractThis document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "Smart Endnode". Only the attached edge RBridge can distinguish a "Smart Endnode" from a "normal endnode". The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables endnodes that are Fine-Grained Label (FGL) aware. 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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8384.
Copyright Notice 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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
RFC6325] [RFC7780] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] [RFC7176] link state routing and encapsulating traffic using 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", whereas one that exclusively forwards encapsulated frames is known as a "transit RBridge" or "transit TRILL Switch". An edge RBridge traditionally is the one that encapsulates a native Ethernet frame with a TRILL header or that receives a TRILL- encapsulated packet and decapsulates the TRILL header. To encapsulate efficiently, the edge RBridge must keep an "endnode table" consisting of (Media Access Control (MAC), Data Label, TRILL egress switch nickname) sets, for those remote MAC addresses in Data Labels currently communicating with endnodes to which the edge RBridge is attached. These 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 communicating with many remote endnodes, this table could become very large. Also, if a MAC address / Data Label pair in the table have moved to a different remote TRILL switch, it might be difficult for the edge RBridge to notice this quickly; and because the edge RBridge is encapsulating to the incorrect egress RBridge, the traffic will get lost. 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, is a variation of TRILL IS-IS designed to operate 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. RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Take Figure 1 as 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 to which SE1 and SE2 have attached. RB1 assigns one of its nicknames to be used by SE1 and SE2. Each Smart Endnode, SE1 and SE2, uses RB1's nickname when encapsulating and maintains an endnode table of (MAC, Data Label, TRILL egress switch nickname) for remote endnodes that it (SE1 or SE2) is corresponding with. RB1 does not decapsulate packets destined for SE1 or SE2 and does not learn (MAC, Data Label, TRILL egress switch nickname) for endnodes corresponding with SE1 or SE2, but RB1 does decapsulate and does learn (MAC, Data Label, TRILL egress switch nickname) for any endnodes attached to RB1 that have not declared themselves to be Smart Endnodes. Just as an RBridge learns and times out (MAC, Data Label, TRILL egress switch nickname), Smart Endnodes SE1 and SE2 also learn and time out endnode entries. However, SE1 and SE2 might also determine, through ICMP messages or other techniques that an endnode entry is not successfully reaching the destination endnode, and it can be deleted, even if the entry has not timed out. If SE1 wishes to correspond with destination MAC D, and no endnode entry exists, SE1 will encapsulate the packet as an unknown destination, or consult a directory [RFC7067] (just as an RBridge would do if there was no endnode entry). +----------+ |SE1(Smart | |Endnode1) | \ +------------------------------+ +----------+ \ / \ \ /+------+ +------+ +-----+ \ +-----------+ /-+-| RB 1 |---| RB2 |----| RB3 |-----+--|Endnode3 | / | +------+ +------+ +-----+ | |MAC=D | +----------+ / \ / +-----------+ |SE2(Smart | \ / | Endnode2)| +------------------------------+ +----------+ Figure 1: Smart Endnode Scenario
The mechanism in this document is that the Smart Endnode SE1 issues a Smart-Hello, indicating SE1's desire to act as a Smart Endnode, together with the set of MAC addresses and Data Labels that SE1 owns. The Smart-Hello is used to announce the Smart Endnode capability and parameters (such as MAC address, Data Label, etc.). The Smart-Hello is a type of TRILL ES-IS PDU, which is specified in Section 5 of [RFC8171]. The detailed content for a Smart Endnode's Smart-Hello is defined in Section 4. If RB1 supports having a Smart Endnode neighbor, it also sends Smart- Hellos. 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. Although Smart Endnode 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]; thus, 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 in this document. RFC8171].
The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes and for Smart-Hellos sent by edge RBridges, consists of TRILL IS-IS TLVs as described in the following 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 as follows inside a TRILL GENINFO TLV: +-+-+-+-+-+-+-+-+- |Smart-Parameters| (1 byte) +-+-+-+-+-+-+-+-+- | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holding Time | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Smart-Parameters APPsub-TLV o Type: APPsub-TLV type Smart-Parameters, value is 22. o Length: 4. o 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 is assumed that it is no longer available. o Flags: At this time, all of the Flags are reserved and MUST be sent as zero and ignored on receipt. o 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.
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. o 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. o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in section 2.5 in [RFC7176], is reused for this purpose. o An Authentication TLV MAY also be included.
+-+-+-+-+-+-+-+-+ |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 o Type: TRILL APPsub-TLV Type Smart-MAC, value is 23. o 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. o 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). o 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. o RSV: 6 bits; reserved for the future use. o 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. o 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.
RFC6325] of the local link but do not necessarily have to be VLAN tagged. RFC7067]. * by having some entries configured. o When Smart Endnode SE1 wishes to send 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), 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]. o 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. 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.
o If RB1 receives a native multi-destination data frame, which is sent by an endnode that is not a Smart Endnode, from a port, including hybrid endnodes (Smart Endnodes and endnodes that are not Smart Endnodes), RB1 will encapsulate it as multi-destination TRILL Data packet, and send the encapsulated multi-destination TRILL Data packet out that same port to the Smart Endnodes attached to the port, and also send the encapsulated multi- destination TRILL Data packet to the TRILL campus through other ports. o If RB1 receives a multi-destination TRILL Data packet from a remote RBridge, and the exit port includes hybrid endnodes (Smart Endnodes and endnodes that are not Smart Endnodes), it sends two copies of multicast frames out the port, one as native and the other as a TRILL-encapsulated frame. When a Smart Endnode receives a multi-destination TRILL Data packet, it learns the remote (MAC address, Data Label, nickname) entry. A Smart Endnode ignores native data frames. A normal (non-Smart) endnode receives the native frame and learns the remote MAC address and ignores the TRILL Data packet. This transit solution may bring some complexity for the edge RBridge and waste network bandwidth resource, so avoiding the hybrid endnodes scenario by attaching the endnodes that are Smart and non-Smart to different ports is RECOMMENDED. Figure 4 as an example. The Smart Endnode SE1 is attached to the TRILL domain by RB1 and RB2 separately. Both RB1 and RB2 could announce their nicknames to SE1. . ..................... . +------+ . . | RB1 | . . /+------+ . +----------+ ./ +-----+ . +----------+ |SE1(Smart |/. | RB3 |......| Smart | | Endnode1)| .\ +-----+ . | Endnode2 | +----------+ . \ . +----------+ . +-----+ . . | RB2 | TRILL . . +-----+ Domain . ....................... Figure 4: Multihoming Scenario
Smart Endnode SE1 can choose either the nickname of RB1 or RB2 when encapsulating and forwarding a TRILL Data packet. If the active- active load balance is considered for the multihoming scenario, the Smart Endnode SE1 could use both the nickname of RB1 and RB2 to encapsulate and forward TRILL Data packet. SE1 uses RB1's nickname when forwarding through RB1 and RB2's nickname when forwarding through RB2. This will cause MAC flip-flopping (see [RFC7379]) of the endnode table entry in the remote RBridges (or Smart Endnodes). The solution for the MAC flip-flopping issue is to set a multihoming bit in the RSV field of the TRILL Data packet. When remote RBridge RB3 or Smart Endnodes receive 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) will coexist as endnode entries in the remote RBridge. (An alternative solution would be to use the ESADI protocol to distribute multiple attachments of a MAC address of a multihoming group. The ESADI is deployed among the edge RBridges (see Section 5.3 of [RFC7357]). RFC5310]. If they are not secured, then it is easier for a rogue end station that does not posses the required keying material to be falsely recognized as a valid Smart Endnode. For general TRILL Security Considerations, see [RFC6325]. As stated there, since end stations are connected to edge RBridge ports by Ethernet, those ports MAY require end stations to authenticate themselves using [IEEE802.1X] and authenticate and encrypt traffic to/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 construct. Decapsulating at egress RBridges or remote Smart Endnodes that believe 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].) Because they encapsulate TRILL Data packets, they can also forge inner MAC addresses. The encapsulation performed by Smart Endnodes also means they can send data in any Data Label, which means they must be trusted in order 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 would not bring more security and vulnerability issues than the TRILL ES-IS security defined in [RFC8171]. For added security against the compromise of data due to its misdelivery for any reason, including the above, end-to-end encryption and authentication should be considered; that is, encryption and authentication from source end station to destination end station. The mechanism described in this document requires Smart Endnodes to be aware of the MAC address(es) of the TRILL edge RBridge(s) to which they are attached and the egress RBridge nickname from which the destination of the packets is reachable. With that information, Smart Endnodes can learn a substantial amount about the topology of the TRILL domain. Therefore, there could be a potential security risk when the Smart Endnodes are not trusted or are compromised. +-----------+-------------------+------------+ | Protocol | Description | Reference | +-----------+-------------------+------------+ | 22 | Smart-Parameters | RFC 8384 | | 23 | Smart-MAC | RFC 8384 | +-----------+-------------------+------------+ Table 1
[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>. [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>.