Unsolicited BFD for Sessionless Applications
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|Authors||Enke Chen , Naiming Shen , Robert Raszuk|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Network Working Group E. Chen Internet Draft N. Shen Intended Status: Informational Cisco Systems Expiration Date: January 17, 2018 R. Raszuk Bloomberg LP July 16, 2017 Unsolicited BFD for Sessionless Applications draft-chen-bfd-unsolicited-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 17, 2018. Copyright Notice Copyright (c) 2017 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 Chen, Shen & Raszuk [Page 1] Internet Draft draft-chen-bfd-unsolicited-00.txt July 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies). 1. Introduction The current implementation and deployment practice for BFD ([RFC5880] and [RFC5881]) usually requires BFD sessions be explicitly configured or registered on both sides. This requirement is not an issue when an application like BGP [RFC4271] has the concept of a "session" that involves both sides for its establishment. However, this requirement can be operationally challenging when the prerequisite "session" does not naturally exist between two endpoints in an application. Simultaneous configuration and coordination may be required on both sides for BFD to take effect. For example: o When BFD is used to keep track of the "liveness" of the nexthop of static routes. Although only one side may need the BFD functionality, currently both sides need to be involved in specific configuration and coordination and in some cases static routes are created unnecessarily just for BFD. o When BFD is used to keep track of the "liveness" of the third-pary nexthop of BGP routes received from the Route Server [RFC7947] at an Internet Exchange Point (IXP). As the third-party nexthop is different from the peering address of the Route Server, for BFD to work, currently two routers peering with the Route Server need to have routes and nexthops from each other (although indirectly via the Router Server), and the nexthop of each router must be present at the same time. These issues are discussed in detail in [RS-BFD]. Clearly it is beneficial and desirable to reduce or eliminate unnecessary configurations and coordination in these "sessionless" applications using BFD. In this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or Chen, Shen & Raszuk [Page 2] Internet Draft draft-chen-bfd-unsolicited-00.txt July 2017 registration by the other side (subject to certain per-interface or per-router policies). With "unsolicited BFD" there is potential risk for excessive resource usage by BFD. To mitigate such risks, several mechanisms are recommended in the Security Considerations section. Compared to the "Seamless BFD" [RFC7880], this proposal involves only minor procedural enhancements to the widely deployed BFD itself. It does not require the exchange of BFD discriminators over an out-of- band channel before the BFD session bring-up. Thus we believe that it is a much simpler solution to the issues discussed. When BGP Add-Path [RFC7911] is deployed at an IXP using the Route Server, the alternate BGP paths can be made available to the clients of the Router Server. The "unsolicited BFD" can be used in BGP route selection by these clients to eliminate paths with "inaccessible nexthops". 1.1. Specification of Requirements 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. Procedures for Unsolicited BFD With "unsolicited BFD", one side takes the "Active role" and the other side takes only the "Passive role" as described in [RFC5880]. On the passive side, the "unsolicited BFD" SHOULD be configured explicitly on an interface. The BFD parameters can be either per- interface or per-router based. It MAY also choose to use the parameters that the active side uses in its BFD Control packets. The "Discriminator", however, MUST be chosen to allow multiple unsolicited BFD sessions. The active side initiates the BFD Control packets as specified in [RFC5880]. The passive side does not initiates the BFD Control packets. When the passive side receives a BFD Control packet from the active side with 0 as the "remote-discriminator", and it does not find an existing session with the same source address as in the packet and "unsolicited BFD" is allowed on the interface by local policy, it SHOULD then create a matching BFD session toward the active side Chen, Shen & Raszuk [Page 3] Internet Draft draft-chen-bfd-unsolicited-00.txt July 2017 (based on the source address and destination address in the BFD Control packet) as if the session were locally registered. It would then start sending the BFD Control packets and perform necessary procedure for bringing up, maintaining and tearing down the BFD session. If the BFD session fails to get established within certain specified time, or if an established BFD session goes down, the passive side would stop sending BFD Control packets and delete the BFD session created until the BFD Control packets is initiated by the active side again. The "Passive role" may change to the "Active role" when a local client registers for the same BFD session, and from the "Active role " to the "Passive role " when there is no longer any locally registered client for the BFD session. 3. IANA Considerations This documents makes no IANA requests. 4. Security Considerations The same security considerations as those described in [RFC5880] and [RFC5881] apply to this document. With "unsolicited BFD" there is potential risk for excessive resource usage by BFD. To mitigate such risks, the following measures are RECOMMENDED: o Limit the feature to a single-hop BFD with "TTL=255" [RFC5082], and to specific interfaces. o Apply "access control" to allow BFD packets only from certain subnets or hosts. o Deploy the feature only in an environment with certain level of "trust". o Use BFD authentication. o Limit the number of "unsolicited BFD" sessions. Chen, Shen & Raszuk [Page 4] Internet Draft draft-chen-bfd-unsolicited-00.txt July 2017 5. Acknowledgments TBD 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>. [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, <http://www.rfc-editor.org/info/rfc5881>. 6.2. Informative References [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, <http://www.rfc-editor.org/info/rfc7880>. [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <http://www.rfc-editor.org/info/rfc7911>. [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, Chen, Shen & Raszuk [Page 5] Internet Draft draft-chen-bfd-unsolicited-00.txt July 2017 DOI 10.17487/RFC7947, September 2016, <http://www.rfc-editor.org/info/rfc7947>. [RS-BFD] Bush, R., J. Haas, J. Scudder, A. Nipper, and T. King, "Making Route Servers Aware of Data Link Failures at IXPs", Work in Progress, draft-ietf-idr-rs-bfd-02, March 2017. 7. Authors' Addresses Enke Chen Cisco Systems 560 McCarthy Blvd. Milpitas, CA 95035 USA Email: firstname.lastname@example.org Naiming Shen Cisco Systems 560 McCarthy Blvd. Milpitas, CA 95035 USA Email: email@example.com Robert Raszuk Bloomberg LP 731 Lexington Ave New York City, NY 10022 USA Email:firstname.lastname@example.org Chen, Shen & Raszuk [Page 6]