idnits 2.17.1 draft-chen-bfd-unsolicited-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 3, 2018) is 2093 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-idr-rs-bfd-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Chen 3 Internet Draft N. Shen 4 Intended Status: Informational Cisco Systems 5 Expiration Date: February 4, 2019 R. Raszuk 6 Bloomberg LP 7 August 3, 2018 9 Unsolicited BFD for Sessionless Applications 10 draft-chen-bfd-unsolicited-03.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on February 4, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Abstract 52 For operational simplification of "sessionless" applications using 53 BFD, in this document we present procedures for "unsolicited BFD" 54 that allow a BFD session to be initiated by only one side, and be 55 established without explicit per-session configuration or 56 registration by the other side (subject to certain per-interface or 57 per-router policies). 59 1. Introduction 61 The current implementation and deployment practice for BFD ([RFC5880] 62 and [RFC5881]) usually requires BFD sessions be explicitly configured 63 or registered on both sides. This requirement is not an issue when an 64 application like BGP [RFC4271] has the concept of a "session" that 65 involves both sides for its establishment. However, this requirement 66 can be operationally challenging when the prerequisite "session" does 67 not naturally exist between two endpoints in an application. 68 Simultaneous configuration and coordination may be required on both 69 sides for BFD to take effect. For example: 71 o When BFD is used to keep track of the "liveness" of the nexthop 72 of static routes. Although only one side may need the BFD 73 functionality, currently both sides need to be involved in 74 specific configuration and coordination and in some cases 75 static routes are created unnecessarily just for BFD. 77 o When BFD is used to keep track of the "liveness" of the 78 third-pary nexthop of BGP routes received from the Route Server 79 [RFC7947] at an Internet Exchange Point (IXP). As the 80 third-party nexthop is different from the peering address of 81 the Route Server, for BFD to work, currently two routers peering 82 with the Route Server need to have routes and nexthops from each 83 other (although indirectly via the Router Server), and the 84 nexthop of each router must be present at the same time. These 85 issues are also discussed in [I-D.ietf-idr-rs-bfd]. 87 Clearly it is beneficial and desirable to reduce or eliminate 88 unnecessary configurations and coordination in these "sessionless" 89 applications using BFD. 91 In this document we present procedures for "unsolicited BFD" that 92 allow a BFD session to be initiated by only one side, and be 93 established without explicit per-session configuration or 94 registration by the other side (subject to certain per-interface or 95 per-router policies). 97 With "unsolicited BFD" there is potential risk for excessive resource 98 usage by BFD from "unexpected" remote systems. To mitigate such 99 risks, several mechanisms are recommended in the Security 100 Considerations section. 102 Compared to the "Seamless BFD" [RFC7880], this proposal involves only 103 minor procedural enhancements to the widely deployed BFD itself. 104 Thus we believe that this proposal is inherently simpler in the 105 protocol itself and deployment. As an example, it does not require 106 the exchange of BFD discriminators over an out-of-band channel before 107 the BFD session bring-up. 109 When BGP Add-Path [RFC7911] is deployed at an IXP using the Route 110 Server, multiple BGP paths (when exist) can be made available to the 111 clients of the Router Server as described in [RFC7947]. The 112 "unsolicited BFD" can be used in BGP route selection by these clients 113 to eliminate paths with "inaccessible nexthops". 115 1.1. Specification of Requirements 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Procedures for Unsolicited BFD 123 With "unsolicited BFD", one side takes the "Active role" and the 124 other side takes only the "Passive role" as described in [RFC5880]. 126 On the passive side, the "unsolicited BFD" SHOULD be configured 127 explicitly on an interface. The BFD parameters can be either per- 128 interface or per-router based. It MAY also choose to use the 129 parameters that the active side uses in its BFD Control packets. The 130 "Discriminator", however, MUST be chosen to allow multiple 131 unsolicited BFD sessions. 133 The active side initiates the BFD Control packets as specified in 134 [RFC5880]. The passive side does not initiates the BFD Control 135 packets. 137 When the passive side receives a BFD Control packet from the active 138 side with 0 as the "remote-discriminator", and it does not find an 139 existing session with the same source address as in the packet and 140 "unsolicited BFD" is allowed on the interface by local policy, it 141 SHOULD then create a matching BFD session toward the active side 142 (based on the source address and destination address in the BFD 143 Control packet) as if the session were locally registered. It would 144 then start sending the BFD Control packets and perform necessary 145 procedure for bringing up, maintaining and tearing down the BFD 146 session. If the BFD session fails to get established within certain 147 specified time, or if an established BFD session goes down, the 148 passive side would stop sending BFD Control packets and delete the 149 BFD session created until the BFD Control packets is initiated by the 150 active side again. 152 The "Passive role" may change to the "Active role" when a local 153 client registers for the same BFD session, and from the "Active role 154 " to the "Passive role " when there is no longer any locally 155 registered client for the BFD session. 157 3. IANA Considerations 159 This documents makes no IANA requests. 161 4. Security Considerations 163 The same security considerations as those described in [RFC5880] and 164 [RFC5881] apply to this document. With "unsolicited BFD" there is 165 potential risk for excessive resource usage by BFD from "unexpected" 166 remote systems. To mitigate such risks, the following measures are 167 RECOMMENDED: 169 o Limit the feature to specific interfaces, and to a single-hop 170 BFD with "TTL=255" [RFC5082]. In addition make sure the source 171 address of an incoming BFD packet belongs to the subnet of the 172 interface from which the BFD packet is received. 174 o Apply "access control" to allow BFD packets only from certain 175 subnets or hosts. 177 o Deploy the feature only in certain "trustworthy" environment, 178 e.g., at an IXP, or between a provider and its customers. 180 o Adjust BFD parameters as needed for the particular deployment 181 and scale. 183 o Use BFD authentication. 185 5. Acknowledgments 187 TBD 189 6. References 191 6.1. Normative References 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, 195 DOI 10.17487/RFC2119, March 1997, 196 . 198 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and 199 C. Pignataro, "The Generalized TTL Security Mechanism 200 (GTSM)", RFC 5082, October 2007. 202 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 203 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 204 . 206 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 207 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 208 DOI 10.17487/RFC5881, June 2010, 209 . 211 6.2. Informative References 213 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 214 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 215 DOI 10.17487/RFC4271, January 2006, 216 . 218 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 219 Pallagatti, "Seamless Bidirectional Forwarding Detection 220 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 221 . 223 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 224 "Advertisement of Multiple Paths in BGP", RFC 7911, 225 DOI 10.17487/RFC7911, July 2016, 226 . 228 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 229 "Internet Exchange BGP Route Server", RFC 7947, 230 DOI 10.17487/RFC7947, September 2016, 231 . 233 [I-D.ietf-idr-rs-bfd] 234 Bush, R., J. Haas, J. Scudder, A. Nipper, and T. King, 235 "Making Route Servers Aware of Data Link Failures at 236 IXPs", draft-ietf-idr-rs-bfd-03 (work in progress), July 237 2017. 239 7. Authors' Addresses 241 Enke Chen 242 Cisco Systems 243 560 McCarthy Blvd. 244 Milpitas, CA 95035 245 USA 247 Email: enkechen@cisco.com 249 Naiming Shen 250 Cisco Systems 251 560 McCarthy Blvd. 252 Milpitas, CA 95035 253 USA 255 Email: naiming@cisco.com 257 Robert Raszuk 258 Bloomberg LP 259 731 Lexington Ave 260 New York City, NY 10022 261 USA 263 Email:robert@raszuk.net