idnits 2.17.1 draft-ietf-bfd-unsolicited-00.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: ---------------------------------------------------------------------------- No issues found here. 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 25, 2019) is 1859 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-idr-rs-bfd-06 Summary: 0 errors (**), 0 flaws (~~), 3 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: Standards Track Cisco Systems 5 Expires: August 29, 2019 R. Raszuk 6 Bloomberg LP 7 R. Rahman 8 Cisco Systems 9 February 25, 2019 11 Unsolicited BFD for Sessionless Applications 12 draft-ietf-bfd-unsolicited-00 14 Abstract 16 For operational simplification of "sessionless" applications using 17 BFD, in this document we present procedures for "unsolicited BFD" 18 that allow a BFD session to be initiated by only one side, and be 19 established without explicit per-session configuration or 20 registration by the other side (subject to certain per-interface or 21 per-router policies). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 27 be interpreted as described in [RFC2119] only when they appear in all 28 upper case. They may also appear in lower or mixed case as English 29 words, without normative meaning. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 29, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Procedures for Unsolicited BFD . . . . . . . . . . . . . . . 3 67 3. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Unsolicited BFD Hierarchy . . . . . . . . . . . . . . . . 4 69 3.2. Unsolicited BFD Module . . . . . . . . . . . . . . . . . 5 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 6.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The current implementation and deployment practice for BFD ([RFC5880] 80 and [RFC5881]) usually requires BFD sessions be explicitly configured 81 or registered on both sides. This requirement is not an issue when 82 an application like BGP [RFC4271] has the concept of a "session" that 83 involves both sides for its establishment. However, this requirement 84 can be operationally challenging when the prerequisite "session" does 85 not naturally exist between two endpoints in an application. 86 Simultaneous configuration and coordination may be required on both 87 sides for BFD to take effect. For example: 89 o When BFD is used to keep track of the "liveness" of the nexthop of 90 static routes. Although only one side may need the BFD 91 functionality, currently both sides need to be involved in 92 specific configuration and coordination and in some cases static 93 routes are created unnecessarily just for BFD. 94 o When BFD is used to keep track of the "liveness" of the third-pary 95 nexthop of BGP routes received from the Route Server [RFC7947] at 96 an Internet Exchange Point (IXP). As the third-party nexthop is 97 different from the peering address of the Route Server, for BFD to 98 work, currently two routers peering with the Route Server need to 99 have routes and nexthops from each other (although indirectly via 100 the Router Server), and the nexthop of each router must be present 101 at the same time. These issues are also discussed in 102 [I-D.ietf-idr-rs-bfd]. 104 Clearly it is beneficial and desirable to reduce or eliminate 105 unnecessary configurations and coordination in these "sessionless" 106 applications using BFD. 108 In this document we present procedures for "unsolicited BFD" that 109 allow a BFD session to be initiated by only one side, and be 110 established without explicit per-session configuration or 111 registration by the other side (subject to certain per-interface or 112 per-router policies). 114 With "unsolicited BFD" there is potential risk for excessive resource 115 usage by BFD from "unexpected" remote systems. To mitigate such 116 risks, several mechanisms are recommended in the Security 117 Considerations section. 119 Compared to the "Seamless BFD" [RFC7880], this proposal involves only 120 minor procedural enhancements to the widely deployed BFD itself. 121 Thus we believe that this proposal is inherently simpler in the 122 protocol itself and deployment. As an example, it does not require 123 the exchange of BFD discriminators over an out-of-band channel before 124 the BFD session bring-up. 126 When BGP Add-Path [RFC7911] is deployed at an IXP using the Route 127 Server, multiple BGP paths (when exist) can be made available to the 128 clients of the Router Server as described in [RFC7947]. The 129 "unsolicited BFD" can be used in BGP route selection by these clients 130 to eliminate paths with "inaccessible nexthops". 132 2. Procedures for Unsolicited BFD 134 With "unsolicited BFD", one side takes the "Active role" and the 135 other side takes only the "Passive role" as described in [RFC5880]. 137 On the passive side, the "unsolicited BFD" SHOULD be configured 138 explicitly on an interface. The BFD parameters can be either per- 139 interface or per-router based. It MAY also choose to use the 140 parameters that the active side uses in its BFD Control packets. The 141 "Discriminator", however, MUST be chosen to allow multiple 142 unsolicited BFD sessions. 144 The active side initiates the BFD Control packets as specified in 145 [RFC5880]. The passive side does not initiates the BFD Control 146 packets. 148 When the passive side receives a BFD Control packet from the active 149 side with 0 as the "remote-discriminator", and it does not find an 150 existing session with the same source address as in the packet and 151 "unsolicited BFD" is allowed on the interface by local policy, it 152 SHOULD then create a matching BFD session toward the active side 153 (based on the source address and destination address in the BFD 154 Control packet) as if the session were locally registered. It would 155 then start sending the BFD Control packets and perform necessary 156 procedure for bringing up, maintaining and tearing down the BFD 157 session. If the BFD session fails to get established within certain 158 specified time, or if an established BFD session goes down, the 159 passive side would stop sending BFD Control packets and delete the 160 BFD session created until the BFD Control packets is initiated by the 161 active side again. 163 The "Passive role" may change to the "Active role" when a local 164 client registers for the same BFD session, and from the "Active role 165 " to the "Passive role " when there is no longer any locally 166 registered client for the BFD session. 168 3. YANG Data Model 170 This section extends the YANG data model for BFD [I-D.ietf-bfd-yang] 171 to cover the unsolicited BFD. 173 3.1. Unsolicited BFD Hierarchy 174 module: ietf-bfd-unsolicited 175 augment /rt:routing/rt:control-plane-protocols 176 /rt:control-plane-protocol/bfd:bfd: 177 +--rw unsolicited {bfd-unsol:unsolicited-params-global}? 178 +--rw allow? boolean 179 +--rw local-multiplier? multiplier 180 +--rw (interval-config-type)? 181 +--:(tx-rx-intervals) 182 | +--rw desired-min-tx-interval? uint32 183 | +--rw required-min-rx-interval? uint32 184 +--:(single-interval) {single-minimum-interval}? 185 +--rw min-interval? uint32 186 augment /rt:routing/rt:control-plane-protocols 187 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 188 /bfd-ip-sh:interfaces: 189 +--rw unsolicited {bfd-unsol:unsolicited-params-per-interface}? 190 +--rw allow? boolean 191 +--rw local-multiplier? multiplier 192 +--rw (interval-config-type)? 193 +--:(tx-rx-intervals) 194 | +--rw desired-min-tx-interval? uint32 195 | +--rw required-min-rx-interval? uint32 196 +--:(single-interval) {single-minimum-interval}? 197 +--rw min-interval? uint32 198 augment /rt:routing/rt:control-plane-protocols 199 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 200 /bfd-ip-sh:sessions/bfd-ip-sh:session: 201 +--ro unsolicited 202 +--ro role? bfd-unsol:unsolicited-role 204 3.2. Unsolicited BFD Module 206 file "ietf-bfd-unsolicited@ 2018-10-27.yang" 208 module ietf-bfd-unsolicited { 210 yang-version 1.1; 212 namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited"; 214 prefix "bfd-unsol"; 216 // RFC Ed.: replace occurences of XXXX/YYYY with actual RFC numbers 217 // and remove this note 219 import ietf-bfd-types { 220 prefix "bfd-types"; 221 reference "RFC XXXX: YANG Data Model for BFD"; 222 } 224 import ietf-bfd { 225 prefix "bfd"; 226 reference "RFC XXXX: YANG Data Model for BFD"; 227 } 229 import ietf-bfd-ip-sh { 230 prefix "bfd-ip-sh"; 231 reference "RFC XXXX: YANG Data Model for BFD"; 232 } 234 import ietf-routing { 235 prefix "rt"; 236 reference 237 "RFC 8349: A YANG Data Model for Routing Management 238 (NMDA version)"; 239 } 241 organization "IETF BFD Working Group"; 243 contact 244 "WG Web: 245 WG List: 247 Editors: Enke Chen (enkechen@cisco.com), 248 Naiming Shen (naiming@cisco.com), 249 Robert Raszuk (robert@raszuk.net), 250 Reshad Rahman (rrahman@cisco.com)"; 252 description 253 "This module contains the YANG definition for BFD unsolicited 254 as per RFC YYYY. 256 Copyright (c) 2018 IETF Trust and the persons 257 identified as authors of the code. All rights reserved. 259 Redistribution and use in source and binary forms, with or 260 without modification, is permitted pursuant to, and subject 261 to the license terms contained in, the Simplified BSD License 262 set forth in Section 4.c of the IETF Trust's Legal Provisions 263 Relating to IETF Documents 264 (http://trustee.ietf.org/license-info). 266 This version of this YANG module is part of RFC XXXX; see 267 the RFC itself for full legal notices."; 269 reference "RFC YYYY"; 271 revision 2018-10-27 { 272 description "Initial revision."; 273 reference "RFC YYYY: A YANG data model for BFD unsolicited"; 274 } 276 /* 277 * Feature definitions 278 */ 279 feature unsolicited-params-global { 280 description 281 "This feature indicates that the server supports global 282 parameters for unsolicited sessions."; 283 } 285 feature unsolicited-params-per-interface { 286 description 287 "This feature indicates that the server supports per-interface 288 parameters for unsolicited sessions."; 289 } 291 /* 292 * Type Definitions 293 */ 294 typedef unsolicited-role { 295 type enumeration { 296 enum unsolicited-active { 297 description "Active role"; 298 } 299 enum unsolicited-passive { 300 description "Passive role"; 301 } 302 } 303 description "Unsolicited role"; 304 } 306 /* 307 * Augments 308 */ 309 augment "/rt:routing/rt:control-plane-protocols/" 310 + "rt:control-plane-protocol/bfd:bfd" { 311 description 312 "Augmentation for BFD unsolicited parameters"; 313 container unsolicited { 314 if-feature bfd-unsol:unsolicited-params-global; 315 description 316 "BFD unsolicited top level container"; 318 leaf allow { 319 type boolean; 320 default false; 321 description "Allow BFD unsolicited globally."; 322 } 323 uses bfd-types:base-cfg-parms; 324 } 325 } 327 augment "/rt:routing/rt:control-plane-protocols/" 328 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 329 + "bfd-ip-sh:interfaces" { 330 description 331 "Augmentation for BFD unsolicited on IP single-hop interface"; 332 container unsolicited { 333 if-feature bfd-unsol:unsolicited-params-per-interface; 334 description 335 "BFD IP single-hop interface unsolicited top level container"; 336 leaf allow { 337 type boolean; 338 default false; 339 description "Allow BFD unsolicited on this interface."; 340 } 341 uses bfd-types:base-cfg-parms; 342 } 343 } 345 augment "/rt:routing/rt:control-plane-protocols/" 346 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 347 + "bfd-ip-sh:sessions/bfd-ip-sh:session" { 348 description 349 "Augmentation for BFD unsolicited on IP single-hop session"; 350 container unsolicited { 351 config false; 352 description 353 "BFD IP single-hop session unsolicited top level container"; 354 leaf role { 355 type bfd-unsol:unsolicited-role; 356 description "Role."; 357 } 358 } 359 } 360 } 362 364 4. IANA Considerations 366 This documents makes no IANA requests. 368 5. Security Considerations 370 The same security considerations as those described in [RFC5880] and 371 [RFC5881] apply to this document. With "unsolicited BFD" there is 372 potential risk for excessive resource usage by BFD from "unexpected" 373 remote systems. To mitigate such risks, the following measures are 374 RECOMMENDED: 376 o Limit the feature to specific interfaces, and to a single-hop BFD 377 with "TTL=255" [RFC5082]. In addition make sure the source 378 address of an incoming BFD packet belongs to the subnet of the 379 interface from which the BFD packet is received. 380 o Apply "access control" to allow BFD packets only from certain 381 subnets or hosts. 382 o Deploy the feature only in certain "trustworthy" environment, 383 e.g., at an IXP, or between a provider and its customers. 384 o Adjust BFD parameters as needed for the particular deployment and 385 scale. 386 o Use BFD authentication. 388 6. References 390 6.1. Normative References 392 [I-D.ietf-bfd-yang] 393 Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and 394 G. Mirsky, "YANG Data Model for Bidirectional Forwarding 395 Detection (BFD)", draft-ietf-bfd-yang-17 (work in 396 progress), August 2018. 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 404 Pignataro, "The Generalized TTL Security Mechanism 405 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 406 . 408 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 409 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 410 . 412 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 413 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 414 DOI 10.17487/RFC5881, June 2010, 415 . 417 6.2. Informative References 419 [I-D.ietf-idr-rs-bfd] 420 Bush, R., Haas, J., Scudder, J., Nipper, A., and C. 421 Dietzel, "Making Route Servers Aware of Data Link Failures 422 at IXPs", draft-ietf-idr-rs-bfd-06 (work in progress), 423 October 2018. 425 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 426 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 427 DOI 10.17487/RFC4271, January 2006, 428 . 430 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 431 Pallagatti, "Seamless Bidirectional Forwarding Detection 432 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 433 . 435 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 436 "Advertisement of Multiple Paths in BGP", RFC 7911, 437 DOI 10.17487/RFC7911, July 2016, 438 . 440 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 441 "Internet Exchange BGP Route Server", RFC 7947, 442 DOI 10.17487/RFC7947, September 2016, 443 . 445 Authors' Addresses 447 Enke Chen 448 Cisco Systems 449 560 McCarthy Blvd. 450 Milpitas, CA 95035 451 USA 453 Email: enkechen@cisco.com 454 Naiming Shen 455 Cisco Systems 456 560 McCarthy Blvd. 457 Milpitas, CA 95035 458 USA 460 Email: naiming@cisco.com 462 Robert Raszuk 463 Bloomberg LP 464 731 Lexington Ave 465 New York City, NY 10022 466 USA 468 Email: robert@raszuk.net 470 Reshad Rahman 471 Cisco Systems 472 2000 Innovation Drive 473 Kanata, Ontario K2K 3E8 474 Canada 476 Email: rrahman@cisco.com