idnits 2.17.1 draft-ietf-bfd-unsolicited-07.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (24 October 2021) is 914 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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 Palo Alto Networks 4 Intended status: Standards Track N. Shen 5 Expires: 27 April 2022 Zededa 6 R. Raszuk 7 NTT Network Innovations 8 R. Rahman 9 24 October 2021 11 Unsolicited BFD for Sessionless Applications 12 draft-ietf-bfd-unsolicited-07 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", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in BCP 28 14 [RFC2119] [RFC8174] when, and only when, they appear in all 29 capitals, as shown here. 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 27 April 2022. 48 Copyright Notice 50 Copyright (c) 2021 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 (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Procedures for Unsolicited BFD . . . . . . . . . . . . . . . 3 66 3. State Variables . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Unsolicited BFD Hierarchy . . . . . . . . . . . . . . . . 5 69 4.2. Unsolicited BFD Module . . . . . . . . . . . . . . . . . 5 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7.1. BFD Protocol Security Considerations . . . . . . . . . . 9 74 7.2. YANG Module Security Considerations . . . . . . . . . . . 10 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 The current implementation and deployment practice for BFD ([RFC5880] 83 and [RFC5881]) usually requires BFD sessions be explicitly configured 84 or registered on both sides. This requirement is not an issue when 85 an application like BGP [RFC4271] has the concept of a "session" that 86 involves both sides for its establishment. However, this requirement 87 can be operationally challenging when the prerequisite "session" does 88 not naturally exist between two endpoints in an application. 89 Simultaneous configuration and coordination may be required on both 90 sides for BFD to take effect. For example: 92 * When BFD is used to keep track of the "liveness" of the nexthop of 93 static routes. Although only one side may need the BFD 94 functionality, currently both sides need to be involved in 95 specific configuration and coordination and in some cases static 96 routes are created unnecessarily just for BFD. 97 * When BFD is used to keep track of the "liveness" of the third-pary 98 nexthop of BGP routes received from the Route Server [RFC7947] at 99 an Internet Exchange Point (IXP). As the third-party nexthop is 100 different from the peering address of the Route Server, for BFD to 101 work, currently two routers peering with the Route Server need to 102 have routes and nexthops from each other (although indirectly via 103 the Router Server), and the nexthop of each router must be present 104 at the same time. These issues are also discussed in 105 [I-D.ietf-idr-rs-bfd]. 107 Clearly it is beneficial and desirable to reduce or eliminate 108 unnecessary configurations and coordination in these "sessionless" 109 applications using BFD. 111 In this document we present procedures for "unsolicited BFD" that 112 allow a BFD session to be initiated by only one side, and be 113 established without explicit per-session configuration or 114 registration by the other side (subject to certain per-interface or 115 per-router policies). 117 With "unsolicited BFD" there is potential risk for excessive resource 118 usage by BFD from "unexpected" remote systems. To mitigate such 119 risks, several mechanisms are recommended in the Security 120 Considerations section. 122 Compared to the "Seamless BFD" [RFC7880], this proposal involves only 123 minor procedural enhancements to the widely deployed BFD itself. 124 Thus we believe that this proposal is inherently simpler in the 125 protocol itself and deployment. As an example, it does not require 126 the exchange of BFD discriminators over an out-of-band channel before 127 the BFD session bring-up. 129 When BGP Add-Path [RFC7911] is deployed at an IXP using the Route 130 Server, multiple BGP paths (when exist) can be made available to the 131 clients of the Router Server as described in [RFC7947]. The 132 "unsolicited BFD" can be used in BGP route selection by these clients 133 to eliminate paths with "inaccessible nexthops". 135 2. Procedures for Unsolicited BFD 137 With "unsolicited BFD", one side takes the "Active role" and the 138 other side takes only the "Passive role" as described in [RFC5880]. 140 On the passive side, the "unsolicited BFD" SHOULD be explicitly 141 configured on an interface or globally (apply to all interfaces). 142 The BFD parameters can be either per-interface or per-router based. 143 It MAY also choose to use the parameters that the active side uses in 144 its BFD Control packets. The "My Discriminator", however, MUST be 145 chosen to allow multiple unsolicited BFD sessions. 147 The active side starts sending the BFD Control packets as specified 148 in [RFC5880]. The passive side does not send BFD Control packets. 150 When the passive side receives a BFD Control packet from the active 151 side with 0 as "Your Discriminator" and does not find an existing BFD 152 session, the passive side MAY create a matching BFD session toward 153 the active side, if permitted by local configuration. 155 It would then start sending the BFD Control packets and perform 156 necessary procedure for bringing up, maintaining and tearing down the 157 BFD session. If the BFD session fails to get established within 158 certain specified time, or if an established BFD session goes down, 159 the passive side would stop sending BFD Control packets and MAY 160 delete the BFD session created until the BFD Control packets is 161 initiated by the active side again. 163 When an Unsolicited BFD session goes down, an implementation MAY 164 retain the session state for a period of time, which may be 165 configurable. Retaining this state can be useful for operational 166 purposes. 168 The "Passive role" may change to the "Active role" when a local 169 client registers for the same BFD session, and from the "Active role" 170 to the "Passive role" when there is no longer any locally registered 171 client for the BFD session. 173 3. State Variables 175 This document defines a new state variable called Unsolicited Role. 177 bfd.UnsolicitedRole 179 The operational mode of BFD interface when configured for unsolicited 180 behaviour. Options can be either PASSIVE, ACTIVE or NULL (NULL - not 181 initialized) for unsolicited BFD sessions. Default (not configured 182 for unsolicited behaviour) MUST be set to NULL if present on the 183 interface. 185 4. YANG Data Model 187 This section extends the YANG data model for BFD [I-D.ietf-bfd-yang] 188 to cover the unsolicited BFD. 190 4.1. Unsolicited BFD Hierarchy 192 module: ietf-bfd-unsolicited 193 augment /rt:routing/rt:control-plane-protocols 194 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh: 195 +--rw unsolicited {bfd-unsol:unsolicited-params-global}? 196 +--rw enable? boolean 197 +--rw local-multiplier? multiplier 198 +--rw (interval-config-type)? 199 +--:(tx-rx-intervals) 200 | +--rw desired-min-tx-interval? uint32 201 | +--rw required-min-rx-interval? uint32 202 +--:(single-interval) {single-minimum-interval}? 203 +--rw min-interval? uint32 204 augment /rt:routing/rt:control-plane-protocols 205 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 206 /bfd-ip-sh:interfaces: 207 +--rw unsolicited {bfd-unsol:unsolicited-params-per-interface}? 208 +--rw enable? boolean 209 +--rw local-multiplier? multiplier 210 +--rw (interval-config-type)? 211 +--:(tx-rx-intervals) 212 | +--rw desired-min-tx-interval? uint32 213 | +--rw required-min-rx-interval? uint32 214 +--:(single-interval) {single-minimum-interval}? 215 +--rw min-interval? uint32 216 augment /rt:routing/rt:control-plane-protocols 217 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 218 /bfd-ip-sh:sessions/bfd-ip-sh:session: 219 +--ro unsolicited 220 +--ro role? bfd-unsol:unsolicited-role 222 4.2. Unsolicited BFD Module 224 file "ietf-bfd-unsolicited@2021-10-24.yang" 225 module ietf-bfd-unsolicited { 227 yang-version 1.1; 229 namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited"; 230 prefix "bfd-unsol"; 232 // RFC Ed.: replace occurences of YYYY with actual RFC numbers 233 // and remove this note 235 import ietf-bfd-types { 236 prefix "bfd-types"; 237 reference "RFC 9127: YANG Data Model for BFD"; 238 } 240 import ietf-bfd { 241 prefix "bfd"; 242 reference "RFC 9127: YANG Data Model for BFD"; 243 } 245 import ietf-bfd-ip-sh { 246 prefix "bfd-ip-sh"; 247 reference "RFC 9127: YANG Data Model for BFD"; 248 } 250 import ietf-routing { 251 prefix "rt"; 252 reference 253 "RFC 8349: A YANG Data Model for Routing Management 254 (NMDA version)"; 255 } 257 organization "IETF BFD Working Group"; 259 contact 260 "WG Web: 261 WG List: 263 Editors: Enke Chen (enchen@paloaltonetworks.com), 264 Naiming Shen (naiming@zededa.com), 265 Robert Raszuk (robert@raszuk.net), 266 Reshad Rahman (reshad@yahoo.com)"; 268 description 269 "This module contains the YANG definition for BFD unsolicited 270 as per RFC YYYY. 272 Copyright (c) 2021 IETF Trust and the persons 273 identified as authors of the code. All rights reserved. 275 Redistribution and use in source and binary forms, with or 276 without modification, is permitted pursuant to, and subject 277 to the license terms contained in, the Simplified BSD License 278 set forth in Section 4.c of the IETF Trust's Legal Provisions 279 Relating to IETF Documents 280 (http://trustee.ietf.org/license-info). 282 This version of this YANG module is part of RFC YYYY; see 283 the RFC itself for full legal notices."; 285 reference "RFC YYYY"; 287 revision 2021-10-24 { 288 description "Initial revision."; 289 reference "RFC YYYY: Unsolicited BFD for Sessionless Applications."; 290 } 292 /* 293 * Feature definitions 294 */ 295 feature unsolicited-params-global { 296 description 297 "This feature indicates that the server supports global 298 parameters for unsolicited sessions."; 299 } 301 feature unsolicited-params-per-interface { 302 description 303 "This feature indicates that the server supports per-interface 304 parameters for unsolicited sessions."; 305 } 307 /* 308 * Type Definitions 309 */ 310 typedef unsolicited-role { 311 type enumeration { 312 enum unsolicited-active { 313 description "Active role"; 314 } 315 enum unsolicited-passive { 316 description "Passive role"; 317 } 318 } 319 description "Unsolicited role"; 320 } 322 /* 323 * Augments 324 */ 325 augment "/rt:routing/rt:control-plane-protocols/" 326 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" { 327 description 328 "Augmentation for BFD unsolicited parameters"; 329 container unsolicited { 330 if-feature bfd-unsol:unsolicited-params-global; 331 description 332 "BFD unsolicited top level container"; 333 leaf enable { 334 type boolean; 335 default false; 336 description 337 "Enable BFD unsolicited globally for IP single-hop."; 338 } 339 uses bfd-types:base-cfg-parms; 340 } 341 } 343 augment "/rt:routing/rt:control-plane-protocols/" 344 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 345 + "bfd-ip-sh:interfaces" { 346 description 347 "Augmentation for BFD unsolicited on IP single-hop interface"; 348 container unsolicited { 349 if-feature bfd-unsol:unsolicited-params-per-interface; 350 description 351 "BFD IP single-hop interface unsolicited top level 352 container"; 353 leaf enable { 354 type boolean; 355 default false; 356 description "Enable BFD unsolicited on this interface."; 357 } 358 uses bfd-types:base-cfg-parms; 359 } 360 } 362 augment "/rt:routing/rt:control-plane-protocols/" 363 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 364 + "bfd-ip-sh:sessions/bfd-ip-sh:session" { 365 description 366 "Augmentation for BFD unsolicited on IP single-hop session"; 367 container unsolicited { 368 config false; 369 description 370 "BFD IP single-hop session unsolicited top level container"; 371 leaf role { 372 type bfd-unsol:unsolicited-role; 373 description "Role."; 375 } 376 } 377 } 378 } 379 381 5. IANA Considerations 383 This document registers the following namespace URI in the "IETF XML 384 Registry" [RFC3688]: 386 URI: urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited 388 Registrant Contact: The IESG. 390 XML: N/A; the requested URI is an XML namespace. 392 This document registers the following YANG module in the "YANG Module 393 Names" registry [RFC6020]: 395 Name: ietf-bfd-unsolicited 397 Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited 399 Prefix: ietf-bfd-unsolicited 401 Reference: RFC YYYY 403 6. Acknowledgments 405 Authors would like to thank Acee Lindem, Greg Mirsky, Jeffrey Haas 406 and Raj Chetan for their review and valuable input. 408 7. Security Considerations 410 7.1. BFD Protocol Security Considerations 412 The same security considerations and protection measures as those 413 described in [RFC5880] and [RFC5881] normatively apply to this 414 document. With "unsolicited BFD" there is potential risk for 415 excessive resource usage by BFD from "unexpected" remote systems. To 416 mitigate such risks, the following measures are mandatory: 418 * Limit the feature to specific interfaces, and to a single-hop BFD 419 with "TTL=255" [RFC5082]. For numbered interfaces source address 420 of an incoming BFD packet should belongs to the subnet of the 421 interface from which the BFD packet is received. For unnumbered 422 interfaces the above check should be aligned with routing protocol 423 addresses running on such pair of interfaces. 424 * Apply "access control" to allow BFD packets only from certain 425 subnets or hosts. 426 * Deploy the feature only in certain "trustworthy" environment, 427 e.g., at an IXP, or between a provider and its customers. 428 * Adjust BFD parameters as needed for the particular deployment and 429 scale. 430 * Use BFD authentication. 432 7.2. YANG Module Security Considerations 434 The YANG module specified in this document defines a schema for data 435 that is designed to be accessed via network management protocols such 436 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 437 is the secure transport layer, and the mandatory-to-implement secure 438 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 439 is HTTPS, and the mandatory-to-implement secure transport is TLS 440 [RFC5246]. 442 The NETCONF access control model [RFC6536] provides the means to 443 restrict access for particular NETCONF or RESTCONF users to a 444 preconfigured subset of all available NETCONF or RESTCONF protocol 445 operations and content. 447 There are a number of data nodes defined in this YANG module that are 448 writable/creatable/deletable (i.e., config true, which is the 449 default). These data nodes may be considered sensitive or vulnerable 450 in some network environments. Write operations (e.g., edit-config) 451 to these data nodes without proper protection can have a negative 452 effect on network operations. These are the subtrees and data nodes 453 and their sensitivity/vulnerability: 455 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 456 /unsolicited: 458 * data node "enable" enables creation of unsolicited BFD IP single- 459 hop sessions globally, i.e. on all interfaces. See Section 7.1. 460 * data nodes local-multiplier, desired-min-tx-interval, required- 461 min-rx-interval and min-interval all impact the parameters of the 462 unsolicited BFD IP single-hop sessions. 464 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 465 /interfaces/interface/unsolicited: 467 * data node "enable" enables creation of unsolicited BFD IP single- 468 hop sessions on a specific interface. See Section 7.1. 469 * data nodes local-multiplier, desired-min-tx-interval, required- 470 min-rx-interval and min-interval all impact the parameters of the 471 unsolicited BFD IP single-hop sessions on the interface. 473 Some of the readable data nodes in this YANG module may be considered 474 sensitive or vulnerable in some network environments. It is thus 475 important to control read access (e.g., via get, get-config, or 476 notification) to these data nodes. These are the subtrees and data 477 nodes and their sensitivity/vulnerability: 479 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 480 /sessions/session/unsolicited: access to this information discloses 481 the role of the local system in the creation of the unsolicited BFD 482 session. 484 8. References 486 8.1. Normative References 488 [I-D.ietf-bfd-yang] 489 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 490 and G. Mirsky, "YANG Data Model for Bidirectional 491 Forwarding Detection (BFD)", Work in Progress, Internet- 492 Draft, draft-ietf-bfd-yang-17, 2 August 2018, 493 . 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, 498 DOI 10.17487/RFC2119, March 1997, 499 . 501 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 502 DOI 10.17487/RFC3688, January 2004, 503 . 505 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 506 Pignataro, "The Generalized TTL Security Mechanism 507 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 508 . 510 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 511 (TLS) Protocol Version 1.2", RFC 5246, 512 DOI 10.17487/RFC5246, August 2008, 513 . 515 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 516 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 517 . 519 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 520 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 521 DOI 10.17487/RFC5881, June 2010, 522 . 524 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 525 the Network Configuration Protocol (NETCONF)", RFC 6020, 526 DOI 10.17487/RFC6020, October 2010, 527 . 529 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 530 and A. Bierman, Ed., "Network Configuration Protocol 531 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 532 . 534 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 535 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 536 . 538 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 539 Protocol (NETCONF) Access Control Model", RFC 6536, 540 DOI 10.17487/RFC6536, March 2012, 541 . 543 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 544 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 545 . 547 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 548 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 549 May 2017, . 551 8.2. Informative References 553 [I-D.ietf-idr-rs-bfd] 554 Bush, R., Haas, J., Scudder, J. G., Nipper, A., and C. 555 Dietzel, "Making Route Servers Aware of Data Link Failures 556 at IXPs", Work in Progress, Internet-Draft, draft-ietf- 557 idr-rs-bfd-09, 21 September 2020, 558 . 561 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 562 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 563 DOI 10.17487/RFC4271, January 2006, 564 . 566 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 567 Pallagatti, "Seamless Bidirectional Forwarding Detection 568 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 569 . 571 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 572 "Advertisement of Multiple Paths in BGP", RFC 7911, 573 DOI 10.17487/RFC7911, July 2016, 574 . 576 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 577 "Internet Exchange BGP Route Server", RFC 7947, 578 DOI 10.17487/RFC7947, September 2016, 579 . 581 Authors' Addresses 583 Enke Chen 584 Palo Alto Networks 586 Email: enchen@paloaltonetworks.com 588 Naiming Shen 589 Zededa 591 Email: naiming@zededa.com 593 Robert Raszuk 594 NTT Network Innovations 595 940 Stewart Dr 596 Sunnyvale, CA 94085 597 United States of America 599 Email: robert@raszuk.net 601 Reshad Rahman 603 Email: reshad@yahoo.com