RFC 7175

Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support

📅 published May 2014, from ietf

RFC 7175: TRILL BFD Support, Part 1 🦋

Okay bestie, this RFC is about getting BFD (Bidirectional Forwarding Detection) working inside TRILL networks 🎀 It's a standards track doc and it's giving "we're fixing the slowness problem" energy.

Title: Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support ✨

Authors: V. Manral (Ionos Corp.), D. Eastlake 3rd (Huawei R&D USA), D. Ward (Cisco Systems), and A. Banerjee (Cumulus Networks) 💅

Category: Standards Track, which means it's an official Internet standard 👑

Date: May 2014

Number: RFC 7175, with ISSN 2070-1721 🌈

Its title block doesn't list anything it obsoletes or updates, so it's a fresh standalone spec 💜

Abstract

Okay so this doc explains how to use BFD inside Routing Bridge (RBridge) campuses. It builds on the RBridge Channel extension to TRILL 🧚

BFD is already super popular for OAM (Operations, Administration, and Maintenance) in IP and MPLS networks. It uses UDP for IP and the Associated Channel Header (ACH) for MPLS. This doc defines how BFD gets encapsulated over TRILL 🦋

Status of This Memo ✨

This is an Internet Standards Track document 👑

It's an IETF product, so it has consensus from the IETF community. It's been publicly reviewed and the IESG (Internet Engineering Steering Group) approved it for publication. If you want more on Internet Standards, check out Section 2 of RFC 5741 🫶

For the current status, any errata, or to send feedback, go to http://www.rfc-editor.org/info/rfc7175 💌

Copyright (c) 2014 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, which you can find at http://trustee.ietf.org/license-info. Those rules are the ones in effect on the publication date, so please read them carefully because they spell out your rights and restrictions 📜

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 without warranty, as described in that same license 💖

Table of Contents 🌸

1. Introduction ....................................................2
   1.1. Terminology ................................................3
   2. BFD over TRILL ..................................................3
      2.1. Sessions and Initialization ................................4
   3. TRILL BFD Control Protocol ......................................5
      3.1. One-Hop TRILL BFD Control ..................................5
      3.2. BFD Control Frame Processing ...............................5
   4. TRILL BFD Echo Protocol .........................................6
      4.1. BFD Echo Frame Processing ..................................6
   5. Management and Operations Considerations ........................7
   6. Default Authentication ..........................................7
   7. Security Considerations .........................................8
   8. IANA Considerations .............................................9
   9. Acknowledgements ................................................9
   10. References .....................................................9
      10.1. Normative References ......................................9
      10.2. Informative References ...................................10

1. Introduction 🌈

Faster convergence is a must-have feature for TRILL [RFC6325] networks 💅 The TRILL IS-IS Hellos [RFC7177] [IS-IS] that RBridges send to each other give a basic neighbor and continuity check. The problem is that failure detection based on not receiving Hellos depends on the Holding Time parameter, which is usually set to tens of seconds. Its smallest possible value is one second, so it's honestly not fast enough 🙈

Some apps, like Voice over IP, want to catch continuity breaks much faster. Sometimes physical-layer failures get caught really quickly, but not always. For example, if there's a failure between two bridges sitting between two RBridges, that can slip through. There are also sneaky failures at higher levels. Some failures might break unicast frames while multicast frames still get through. Since all TRILL IS-IS Hellos are multicast, Hellos can't catch that kind of failure 💀 So for some apps, you need a low-overhead way to keep testing continuity for TRILL Data between neighbor RBridges. The BFD protocol [RFC5880] does exactly that, giving low-overhead rapid detection of connectivity failures ✨

BFD is a widely deployed OAM [RFC6291] mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively 🧚 This document describes a TRILL encapsulation for BFD packets, for networks that forward based on the TRILL Header 🎀

1.1. Terminology 🍓

This document uses the acronyms from [RFC6325], plus these:

  • BFD: Bidirectional Forwarding Detection
  • IP: Internet Protocol
  • IS-IS: Intermediate System to Intermediate System
  • MH: Multi-Hop
  • PPP: Point-to-Point Protocol
  • OAM: Operations, Administration, and Maintenance

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶

2. BFD over TRILL 🦋

TRILL supports unicast neighbor BFD Echo, plus one-hop and multi-hop BFD Control, all over the RBridge Channel facility [RFC7178]. Multi-destination BFD is still a work in progress [MultiBFD] 🚧 BFD-over-TRILL is pretty similar to BFD-over-IP [RFC5881], except where the doc explicitly calls out a difference 👑

Asynchronous and demand modes MUST be supported [RFC5880]. BFD over TRILL does support the Echo function, but implementing TRILL BFD Echo is optional, and it can only be used for single-hop sessions 💅

The TRILL Header hop count in BFD packets gets sent out with the max value of 0x3F. To stop spoofing attacks, the TRILL hop count of a received session gets checked [RFC5082] 🙈 For a single-hop session, if the hop count is less than 0x3F and the RBridge Channel Header MH flag is zero, the packet gets discarded 💀 For multi-hop sessions, the hop count check can be turned off if the MH flag is one ✨

Just like BFD for IP, the format of the Echo Packet content is not defined 🌸

New RBridge Channel code points for BFD TRILL Control and BFD Echo packets are specified 🧚

Authentication mechanisms that BFD supports also work for BFD running over TRILL 🔥

2.1. Sessions and Initialization 🌷

Inside an RBridge campus, there will be no more than one TRILL BFD Control session from any RBridge RB1 to RBridge RB2 for each RB1 TRILL port 🎀 That BFD session has to be bound to that interface. So both sides of a session MUST take the "Active" role, meaning they send initial BFD Control packets with a zero value of Your Discriminator. Any BFD packet from the remote machine with a zero value of Your Discriminator MUST be associated with the session bound to the remote system and interface 🫶

Heads up that TRILL BFD gives OAM for the TRILL data plane 🦋 That sits above whatever protocol is running on a given link, like a pseudowire [RFC7173], Ethernet [RFC6325], or PPP link [RFC6361] 💅 Link-technology-specific OAM can run on a link between neighbor RBridges too. For Ethernet, that could be Continuity Fault Management [802.1Q]. But link-layer OAM, and how it coordinates with OAM in the TRILL data-plane layer like TRILL BFD, is out of scope for this document 🙈

If lower-level mechanisms like link aggregation [802.1AX] are in use and present a single logical interface to TRILL IS-IS, then only a single TRILL BFD session can be set up to any other RBridge over that logical interface 🍓 Lower-layer OAM could still be aware of, or run separately on, each of the components of an aggregation 🌈

3. TRILL BFD Control Protocol 💜

TRILL BFD Control frames are unicast TRILL RBridge Channel frames [RFC7178]. The RBridge Channel Protocol value is in Section 8. The protocol-specific data for TRILL BFD Control is as shown in Section 4.1 of [RFC5880] ✨

3.1. One-Hop TRILL BFD Control 🧚

One-hop TRILL BFD Control is typically used to rapidly detect link and RBridge failures 🔥 TRILL BFD frames over one hop for these purposes SHOULD be sent with high priority. That means the Inner.VLAN tag priority should be 7, they should be queued for transmission as maximum priority frames, and, if they're sent on an Ethernet link where the output port is configured to include an Outer.VLAN tag, that tag should specify priority 7 👑

For neighbor RBridges RB1 and RB2, each RBridge only sends one-hop TRILL BFD Control frames to the other if TRILL IS-IS has detected bidirectional connectivity. In other words, the adjacency is in the 2-Way or Report state [RFC7177], and both RBridges indicate that TRILL BFD support is enabled. The BFD-Enabled TLV is used to indicate this, as specified in [RFC6213] 🫶

3.2. BFD Control Frame Processing 💅

The following tests SHOULD be performed on received TRILL BFD Control frames before generic BFD processing 🌸

  • Is the M bit in the TRILL Header non-zero? If so, discard the frame. Multi-destination BFD is still a work in progress [MultiBFD]. Skipping this test would make a denial-of-service attack using bogus multi-destination BFD Control frames easier 💀
  • If the Channel Header MH flag is zero, meaning one hop, test that the TRILL Header hop count received was 0x3F (so 0x3E if it's already been decremented). If it's any other value, discard the frame. If the Channel Header MH flag is one, meaning multi-hop, test that the TRILL Header hop count received was not less than a configurable value that defaults to 0x30. If it's less, discard the frame. Skipping these tests would make it easier to spoof BFD Control frames. But if forged BFD Control frames are a concern, BFD Authentication [RFC5880] should be used 🔐

4. TRILL BFD Echo Protocol ✨

okay so a TRILL BFD Echo frame is a unicast RBridge Channel frame (see [RFC7178] 🦋). The fun part is that it should be forwarded back by an immediate neighbor, because both the ingress and egress nicknames are set to the nickname of the RBridge that sent it. bestie, that's the whole trick 💅 Normal TRILL Data forwarding will bounce it back unless the neighbor has micro-loop suppression logic that stops it from sending a frame back out the port it came in on (or something similar). RBridges with those prohibitions just can't support BFD Echo 😭 The TRILL OAM protocol number for BFD Echo is given in Section 8 🎀

Now, TRILL BFD Echo frames SHOULD be sent on a link only if all of these are true. An Echo sent under any other circumstances will eat up bandwidth and CPU and is unlikely to ever come back 💀

- A TRILL BFD Control session has been established,

- TRILL BFD Echo support is indicated by the RBridge that would potentially respond to the BFD Echo,

- The adjacency is in the Report state [RFC7177], and

- The TRILL BFD Echo originating RBridge wishes to make use of this optional feature.

Since the originating RBridge is the one that processes a returned Echo, the whole TRILL BFD Echo protocol-specific data area is treated as opaque and left up to the originating RBridge 🫶 Still, it is suggested that this data include info so the originating RBridge can authenticate the returned Echo and confirm which neighbor echoed it back. For example, it could carry its own System ID, the neighbor's System ID, a session identifier, and a sequence count, plus a Message Authentication Code 🔐✨

4.1. BFD Echo Frame Processing

Okay, these tests MUST be performed on returned TRILL BFD Echo frames before anything else happens. The RBridge Channel document [RFC7178] says the information in the TRILL Header has to be handed to the BFD protocol 🧚

  • Is the M bit in the TRILL Header non-zero? If so, discard the frame. (Multi-destination BFD is still a work in progress [MultiBFD] 🙈)
  • The TRILL BFD Echo frame should have gone exactly two hops, so check that the TRILL Header hop count as received was 0x3E (i.e., 0x3D if it has already been decremented). If it's any other value, discard the frame. The RBridge Channel Header in the frame MUST have the MH bit equal to one, and if it is zero, discard the frame 👑

5. Management and Operations Considerations 🌈

The TRILL BFD parameters on an RBridge are configurable 🍓 The default values match the IP BFD case [RFC5881], except where this document says otherwise, such as for hop count.

It's up to the operator of an RBridge campus to configure how often TRILL BFD frames go out on a link, so they don't cause congestion (on the link, I/O, or CPU) or false failure detection 😭 See also the discussion of congestion in Section 2 of [RFC5881].

As stated in [RFC5880]:

It is worth noting that a single BFD session does not consume a large amount of bandwidth. An aggressive session that achieves a detection time of 50 milliseconds, by using a transmit interval of 16.7 milliseconds and a detect multiplier of 3, will generate 60 packets per second. The maximum length of each packet on the wire is on the order of 100 bytes, for a total of around 48 kilobits per second of bandwidth consumption in each direction.

6. Default Authentication 🔐

okay so TRILL's big goal is working with minimal configuration, so the default BFD authentication between neighbor RBridges is based on the state of IS-IS shared secret authentication for Hellos between those RBridges (details below) 💖 The BFD authentication algorithm and methods in this section MUST be implemented at an RBridge if TRILL IS-IS authentication and BFD are both implemented at that RBridge. If BFD authentication is configured, its configuration is not restricted by the IS-IS security config.

If IS-IS authentication is not in effect between neighbor RBridges, then by default TRILL BFD between them is also unsecured 🥀

If IS-IS authentication is in effect, then unless configured otherwise, TRILL BFD Control frames sent between those RBridges MUST use BFD Meticulous Keyed SHA1 authentication [RFC5880] ✨ The BFD authentication keys between neighbor RBridges are derived by default from the IS-IS shared secret authentication keys for Hellos between those RBridges, as detailed below. However, such BFD authentication keys MAY be configured to some other value 🌸

  HMAC-SHA256 ( ( "TRILL BFD Control" | originPortID | originSysID ),
                IS-IS-shared-key )

In the above, "|" means concatenation. HMAC-SHA256 is as described in [FIPS180] and [RFC6234]. "TRILL BFD Control" is the 17-byte US ASCII [ASCII] string, which then gets concatenated with the 2-byte Port ID of the originating port and the 6-byte IS-IS System ID of the originating RBridge, the last two being in network byte order. The Port and System IDs are included to minimize exposure of the same key, which improves resistance to cryptanalysis 🧠 IS-IS-shared-key is secret keying material used for IS-IS authentication on the link.

To use the derived key, you associate the default authentication type and key above with the Key ID of the IS-IS-shared-key used in the derivation, then put that Key ID in the Authentication Section of the BFD Control frame OAM protocol-specific data. Also, Auth Type would be 5, and Auth Len would be 28 in the Authentication Section 🎀 RBridges MAY be configured to use other BFD security modes or keying material, or to use no security at all.

Authentication for TRILL BFD Echo is a local implementation issue, since BFD Echo frames are authenticated by their sender when they come back from a neighbor 🦋 However, if TRILL IS-IS and BFD Control are being authenticated to a neighbor and BFD Echo is in use, BFD Echo frames to be returned by that neighbor SHOULD be authenticated, and that authentication SHOULD use different keying material from other types of authentication. For example, it could use keying material derived like this, where "|" means concatenation:

  HMAC-SHA256 ( ( "TRILL BFD Echo" | originPortID | originSysID ),
                IS-IS-shared-key )

7. Security Considerations 🚨

BFD over TRILL uses the RBridge Channel extension to the TRILL protocol and is generally analogous to BFD over IP. So the BFD authentication facility can authenticate BFD-over-TRILL packet payloads, but no encryption or other security features are provided at the BFD-over-TRILL level. See the following:

  • [RFC5881] for general BFD security considerations,
  • [RFC7178] for general RBridge Channel security considerations, and
  • [RFC6325] for general TRILL protocol security considerations.

Section 3.2 describes security concerns with multi-hop BFD Control packets and with failing to check the TRILL Header M bit in BFD Control packets. This one is serious, bestie, so go read it 😭🚨

8. IANA Considerations 🌷

IANA has allocated two RBridge Channel protocol numbers [RFC7178] from the Standards Action range, as follows:

    Protocol     Number
    --------     ------
    BFD Control  0x002
    BFD Echo     0x003

9. Acknowledgements 💜

The authors would like to specially thank Dave Katz, an author of [RFC5880] and [RFC5881], since some material in this document was reproduced from those. 🫶

The following individuals are thanked for their comments and suggestions: Scott Bradner, Stewart Bryant, Stephen Farrell, Eric Gray, Brian Haberman, Barry Leiba, Erik Nordmark, John Scudder, Robert Sparks, Martin Stiemerling, and Sean Turner. 🌈

10. References 📚

10.1. Normative References

[ASCII]    American National Standards Institute, "Coded Character
           Set - 7-bit American Standard Code for Information
           Interchange", ANSI X3.4, 1986.

[FIPS180]  National Institute of Science and Technology, "Secure Hash
           Standard (SHS)", Federal Information Processing Standard
           (FIPS) 180-4, March 2012, <http://csrc.nist.gov/
           publications/fips/fips180-4/fips-180-4.pdf>.

[IS-IS]    International Organization for Standardization,
           "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)", Second
           Edition, November 2002.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
           (BFD)", RFC 5880, June 2010.

[RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
           (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
           2010.

[RFC6213]  Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC
           6213, April 2011.

[RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
           Ghanwani, "Routing Bridges (RBridges): Base Protocol
           Specification", RFC 6325, July 2011.

[RFC7177]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
           V. Manral, "Transparent Interconnection of Lots of Links
           (TRILL): Adjacency", RFC 7177, May 2014.

[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, May 2014.

10.2. Informative References

[802.1AX]  IEEE, "IEEE Standard for Local and metropolitan area
           networks -- Link Aggregation", IEEE Std 802.1AX-2008,
           January 2008.

[802.1Q]   IEEE, "IEEE Standard for Local and metropolitan area
           networks -- Media Access Control (MAC) Bridges and Virtual
           Bridged Local Area Networks", IEEE Std 802.1Q-2011, August
           2011.

[MultiBFD] Katz, D. and D. Ward, "BFD for Multipoint Networks", Work
           in Progress, February 2014.

[RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
           Pignataro, "The Generalized TTL Security Mechanism
           (GTSM)", RFC 5082, October 2007.

[RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
           (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

[RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
           D., and S. Mansfield, "Guidelines for the Use of the "OAM"
           Acronym in the IETF", BCP 161, RFC 6291, June 2011.

[RFC6361]  Carlson, J. and D. Eastlake 3rd, "PPP Transparent
           Interconnection of Lots of Links (TRILL) Protocol Control
           Protocol", RFC 6361, August 2011.

[RFC7173]  Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson,
           "Transparent Interconnection of Lots of Links (TRILL)
           Transport Using Pseudowires", RFC 7173, May 2014.

Authors' Addresses 💌

Okay bestie, here are the four brilliant minds who made this happen 🫶 and how to reach them.

Vishwas Manral 🌸

Vishwas Manral
Ionos Corp.
4100 Moorpark Ave.
San Jose, CA  95117
USA

EMail: vishwas@ionosnetworks.com

Donald Eastlake 3rd 🎀

Donald Eastlake 3rd
Huawei R&D USA
155 Beaver Street
Milford, MA  01757
USA

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

Dave Ward 🦋

Dave Ward
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95138
USA

EMail: dward@cisco.com

Ayan Banerjee 🧚

Ayan Banerjee
Cumulus Networks
1089 West Evelyn Avenue
Sunnyvale, CA 94086
USA

EMail: ayabaner@gmail.com

That's the whole squad, periodt! 🌈👑💅

📦 where this page comes from