diff options
Diffstat (limited to 'doc/rfc/rfc7175.txt')
| -rw-r--r-- | doc/rfc/rfc7175.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7175.txt b/doc/rfc/rfc7175.txt new file mode 100644 index 0000000..5411b4e --- /dev/null +++ b/doc/rfc/rfc7175.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) V. Manral +Request for Comments: 7175 Ionos Corp. +Category: Standards Track D. Eastlake 3rd +ISSN: 2070-1721 Huawei R&D USA + D. Ward + Cisco Systems + A. Banerjee + Cumulus Networks + May 2014 + + + Transparent Interconnection of Lots of Links (TRILL): + Bidirectional Forwarding Detection (BFD) Support + +Abstract + + This document specifies use of the Bidirectional Forwarding Detection + (BFD) protocol in Routing Bridge (RBridge) campuses based on the + RBridge Channel extension to the Transparent Interconnection of Lots + of Links (TRILL) protocol. + + BFD is a widely deployed Operations, Administration, and Maintenance + (OAM) mechanism in IP and MPLS networks, using UDP and Associated + Channel Header (ACH) encapsulation respectively. This document + specifies the BFD encapsulation over TRILL. + +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 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7175. + + + + + + + + + + + + +Manral, et al. Standards Track [Page 1] + +RFC 7175 TRILL BFD Support May 2014 + + +Copyright Notice + + 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 + (http://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. + +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 critical feature of Transparent + Interconnection of Lots of Links (TRILL) [RFC6325] networks. The + TRILL IS-IS Hellos [RFC7177] [IS-IS] used between RBridges provide a + basic neighbor and continuity check for TRILL links. However, + failure detection by non-receipt of such Hellos is based on the + Holding Time parameter that is commonly set to a value of tens of + seconds and, in any case, has a minimum expressible value of one + second. + + + + + + +Manral, et al. Standards Track [Page 2] + +RFC 7175 TRILL BFD Support May 2014 + + + Some applications, including Voice over IP, may wish, with high + probability, to detect interruptions in continuity within a much + shorter time period. In some cases, physical-layer failures can be + detected very rapidly, but this is not always possible, such as when + there is a failure between two bridges that are in turn between two + RBridges. There are also many subtle failures possible at higher + levels. For example, some forms of failure could affect unicast + frames while still letting multicast frames through; since all TRILL + IS-IS Hellos are multicast, such a failure cannot be detected with + Hellos. Thus, a low-overhead method for frequently testing + continuity for the TRILL Data between neighbor RBridges is necessary + for some applications. The BFD protocol [RFC5880] provides a low- + overhead method for the 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 defined in [RFC6325] along with the + following: + + 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 and one-hop and multi-hop + BFD Control, as specified below, over the RBridge Channel facility + [RFC7178]. (Multi-destination BFD is a work in progress [MultiBFD].) + BFD-over-TRILL support is similar to BFD-over-IP support [RFC5881], + except where differences are explicitly mentioned. + + + + +Manral, et al. Standards Track [Page 3] + +RFC 7175 TRILL BFD Support May 2014 + + + Asynchronous and demand modes MUST be supported [RFC5880]. BFD over + TRILL supports the Echo function; however, implementation of TRILL + BFD Echo is optional, and it can only be used for single-hop + sessions. + + The TRILL Header hop count in the BFD packets is sent out with the + maximum value of 0x3F. To prevent spoofing attacks, the TRILL hop + count of a received session is 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 is discarded. For multi-hop + sessions, the hop count check can be disabled if the MH flag is one. + + As in 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 as supported in BFD are also supported for + BFD running over TRILL. + +2.1. Sessions and Initialization + + Within 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. This BFD session must be bound to this interface. As + such, both sides of a session MUST take the "Active" role (sending + initial BFD Control packets with a zero value of Your Discriminator), + and 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. + + Note that TRILL BFD provides OAM facilities for the TRILL data plane. + This is above whatever protocol is in use on a particular link, such + as a pseudowire [RFC7173], Ethernet [RFC6325], or PPP link [RFC6361]. + Link-technology-specific OAM protocols may be used on a link between + neighbor RBridges, for example, Continuity Fault Management [802.1Q] + if the link is Ethernet. But such link-layer OAM (and coordination + between it and OAM in the TRILL data-plane layer, such as TRILL BFD) + is beyond the scope of this document. + + If lower-level mechanisms are in use, such as link aggregation + [802.1AX], that present a single logical interface to TRILL IS-IS, + then only a single TRILL BFD session can be established to any other + RBridge over this logical interface. However, lower-layer OAM could + be aware of and/or run separately on each of the components of an + aggregation. + + + + +Manral, et al. Standards Track [Page 4] + +RFC 7175 TRILL BFD Support May 2014 + + +3. TRILL BFD Control Protocol + + TRILL BFD Control frames are unicast TRILL RBridge Channel frames + [RFC7178]. The RBridge Channel Protocol value is given in Section 8. + The protocol-specific data associated with the TRILL BFD Control + protocol 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 such + purposes SHOULD be sent with high priority; that is, the Inner.VLAN + tag priority should be 7, they should be queued for transmission as + maximum priority frames, and, if they are being 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 sends one-hop TRILL + BFD Control frames to the other only if TRILL IS-IS has detected + bidirectional connectivity; that is, the adjacency is in the 2-Way or + Report state [RFC7177], and both RBridges indicate support of TRILL + BFD 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. + + o Is the M bit in the TRILL Header non-zero? If so, discard the + frame. (Multi-destination BFD is a work in progress [MultiBFD].) + Failure to perform this test would make a denial-of-service attack + using bogus multi-destination BFD Control frames easier. + + o If the Channel Header MH flag is zero, indicating one hop, test + that the TRILL Header hop count received was 0x3F (i.e., is 0x3E + if it has already been decremented); if it is any other value, + discard the frame. If the Channel Header MH flag is one, + indicating multi-hop, test that the TRILL Header hop count + received was not less than a configurable value that defaults to + 0x30. If it is less, discard the frame. Failure to perform these + tests would make it easier to spoof BFD Control frames. However, + if forged BFD Control frames are a concern, then BFD + Authentication [RFC5880] should be used. + + + + + + + +Manral, et al. Standards Track [Page 5] + +RFC 7175 TRILL BFD Support May 2014 + + +4. TRILL BFD Echo Protocol + + A TRILL BFD Echo frame is a unicast RBridge Channel frame, as + specified in [RFC7178], which should be forwarded back by an + immediate neighbor because both the ingress and egress nicknames are + set to a nickname of the originating RBridge. Normal TRILL Data + frame forwarding will cause the frame to be returned unless micro- + loop suppression logic in the neighbor RBridge prohibits sending a + frame back out the port on which it was received or the like. + RBridges with such prohibitions cannot support BFD Echo. The TRILL + OAM protocol number for BFD Echo is given in Section 8. + + TRILL BFD Echo frames SHOULD be sent on a link only if the following + conditions are met. An Echo originating under other circumstances + will consume bandwidth and CPU resources but is unlikely to be + returned. + + - 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 RBridge that will be processing + a returned Echo frame, the entire TRILL BFD Echo protocol-specific + data area is considered opaque and left to the discretion of the + originating RBridge. Nevertheless, it is suggested that this data + include information by which the originating RBridge can authenticate + the returned BFD Echo frame and confirm the neighbor that echoed the + frame back. For example, it could include its own System ID, the + neighbor's System ID, a session identifier, and a sequence count as + well as a Message Authentication Code. + +4.1. BFD Echo Frame Processing + + The following tests MUST be performed on returned TRILL BFD Echo + frames before other processing. The RBridge Channel document + [RFC7178] requires that the information in the TRILL Header be given + to the BFD protocol. + + o Is the M bit in the TRILL Header non-zero? If so, discard the + frame. (Multi-destination BFD is a work in progress [MultiBFD].) + + + + + +Manral, et al. Standards Track [Page 6] + +RFC 7175 TRILL BFD Support May 2014 + + + o The TRILL BFD Echo frame should have gone exactly two hops, so + test that the TRILL Header hop count as received was 0x3E (i.e., + 0x3D if it has already been decremented), and if it is 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 are the same as in the IP BFD case [RFC5881], except where + specified in this document, such as for hop count. + + It is up to the operator of an RBridge campus to configure the rates + at which TRILL BFD frames are transmitted on a link to avoid + congestion (e.g., link, input/output (I/O), CPU) and 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 + + Consistent with TRILL's goal of being able to operate with minimum + configuration, the default for BFD authentication between neighbor + RBridges is based on the state of the IS-IS shared secret + authentication for Hellos between those RBridges as detailed below. + The BFD authentication algorithm and methods in this section MUST be + implemented at an RBridge if TRILL IS-IS authentication and BFD are + implemented at that RBridge. If such BFD authentication is + configured, then its configuration is not restricted by the + configuration of IS-IS security. + + If IS-IS authentication is not in effect between neighbor RBridges, + then, by default, TRILL BFD between those RBridges is also unsecured. + + If such 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 by default are derived + + + +Manral, et al. Standards Track [Page 7] + +RFC 7175 TRILL BFD Support May 2014 + + + 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, "|" indicates concatenation; HMAC-SHA256 is as + described in [FIPS180] and [RFC6234]; and "TRILL BFD Control" is the + 17-byte US ASCII [ASCII] string indicated that is then 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 items being in + network byte order. The Port and System IDs are included to minimize + exposure of the same key to improve resistance to cryptanalysis. + IS-IS-shared-key is secret keying material being used for IS-IS + authentication on the link. + + The use of the above derived key is accomplished by associating the + above default authentication type and key with the Key ID of the + IS-IS-shared-key used in the derivation and then using 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 configured to use no + security. + + Authentication for TRILL BFD Echo is a local implementation issue as + BFD Echo frames are authenticated by their sender when returned by 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 such + authentication should use different keying material from other types + of authentication. For example, it could use keying material derived + as follows, where "|" indicates concatenation: + + HMAC-SHA256 ( ( "TRILL BFD Echo" | originPortID | originSysID ), + IS-IS-shared-key ) + +7. Security Considerations + + BFD over TRILL utilizes the RBridge Channel extension to the TRILL + protocol and is generally analogous to BFD over IP. As such, the BFD + authentication facility is available to 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, + + + + +Manral, et al. Standards Track [Page 8] + +RFC 7175 TRILL BFD Support May 2014 + + + - [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 failure to check the TRILL Header M bit in BFD Control + packets. + +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], from which some material herein has been + reproduced. + + 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. + + + +Manral, et al. Standards Track [Page 9] + +RFC 7175 TRILL BFD Support May 2014 + + + [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. + + + + + + +Manral, et al. Standards Track [Page 10] + +RFC 7175 TRILL BFD Support May 2014 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Manral, et al. Standards Track [Page 11] + +RFC 7175 TRILL BFD Support May 2014 + + +Authors' Addresses + + Vishwas Manral + Ionos Corp. + 4100 Moorpark Ave. + San Jose, CA 95117 + USA + + EMail: vishwas@ionosnetworks.com + + + 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 + Cisco Systems + 170 W. Tasman Drive + San Jose, CA 95138 + USA + + EMail: dward@cisco.com + + + Ayan Banerjee + Cumulus Networks + 1089 West Evelyn Avenue + Sunnyvale, CA 94086 + USA + + EMail: ayabaner@gmail.com + + + + + + + + + + + + + + +Manral, et al. Standards Track [Page 12] + |