idnits 2.17.1 draft-ietf-bfd-unsolicited-05.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 date (October 19, 2021) is 918 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: 2 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: April 22, 2022 Zededa 6 R. Raszuk 7 NTT Network Innovations 8 R. Rahman 9 October 19, 2021 11 Unsolicited BFD for Sessionless Applications 12 draft-ietf-bfd-unsolicited-05 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 April 22, 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 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. State Variables . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1. Unsolicited BFD Hierarchy . . . . . . . . . . . . . . . . 5 70 4.2. Unsolicited BFD Module . . . . . . . . . . . . . . . . . 5 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7.1. BFD Protocol Security Considerations . . . . . . . . . . 9 75 7.2. YANG Module Security Considerations . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 8.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The current implementation and deployment practice for BFD ([RFC5880] 84 and [RFC5881]) usually requires BFD sessions be explicitly configured 85 or registered on both sides. This requirement is not an issue when 86 an application like BGP [RFC4271] has the concept of a "session" that 87 involves both sides for its establishment. However, this requirement 88 can be operationally challenging when the prerequisite "session" does 89 not naturally exist between two endpoints in an application. 90 Simultaneous configuration and coordination may be required on both 91 sides for BFD to take effect. For example: 93 o When BFD is used to keep track of the "liveness" of the nexthop of 94 static routes. Although only one side may need the BFD 95 functionality, currently both sides need to be involved in 96 specific configuration and coordination and in some cases static 97 routes are created unnecessarily just for BFD. 98 o When BFD is used to keep track of the "liveness" of the third-pary 99 nexthop of BGP routes received from the Route Server [RFC7947] at 100 an Internet Exchange Point (IXP). As the third-party nexthop is 101 different from the peering address of the Route Server, for BFD to 102 work, currently two routers peering with the Route Server need to 103 have routes and nexthops from each other (although indirectly via 104 the Router Server), and the nexthop of each router must be present 105 at the same time. These issues are also discussed in 106 [I-D.ietf-idr-rs-bfd]. 108 Clearly it is beneficial and desirable to reduce or eliminate 109 unnecessary configurations and coordination in these "sessionless" 110 applications using BFD. 112 In this document we present procedures for "unsolicited BFD" that 113 allow a BFD session to be initiated by only one side, and be 114 established without explicit per-session configuration or 115 registration by the other side (subject to certain per-interface or 116 per-router policies). 118 With "unsolicited BFD" there is potential risk for excessive resource 119 usage by BFD from "unexpected" remote systems. To mitigate such 120 risks, several mechanisms are recommended in the Security 121 Considerations section. 123 Compared to the "Seamless BFD" [RFC7880], this proposal involves only 124 minor procedural enhancements to the widely deployed BFD itself. 125 Thus we believe that this proposal is inherently simpler in the 126 protocol itself and deployment. As an example, it does not require 127 the exchange of BFD discriminators over an out-of-band channel before 128 the BFD session bring-up. 130 When BGP Add-Path [RFC7911] is deployed at an IXP using the Route 131 Server, multiple BGP paths (when exist) can be made available to the 132 clients of the Router Server as described in [RFC7947]. The 133 "unsolicited BFD" can be used in BGP route selection by these clients 134 to eliminate paths with "inaccessible nexthops". 136 2. Procedures for Unsolicited BFD 138 With "unsolicited BFD", one side takes the "Active role" and the 139 other side takes only the "Passive role" as described in [RFC5880]. 141 On the passive side, the "unsolicited BFD" SHOULD be explicitly 142 configured on an interface or globally (apply to all interfaces). 143 The BFD parameters can be either per-interface or per-router based. 145 It MAY also choose to use the parameters that the active side uses in 146 its BFD Control packets. The "My Discriminator", however, MUST be 147 chosen to allow multiple unsolicited BFD sessions. 149 The active side starts sending the BFD Control packets as specified 150 in [RFC5880]. The passive side does not send BFD Control packets. 152 When the passive side receives a BFD Control packet from the active 153 side with 0 as "Your Discriminator" and does not find an existing BFD 154 session, the passive side MAY create a matching BFD session toward 155 the active side, if permitted by local configuration. 157 It would then start sending the BFD Control packets and perform 158 necessary procedure for bringing up, maintaining and tearing down the 159 BFD session. If the BFD session fails to get established within 160 certain specified time, or if an established BFD session goes down, 161 the passive side would stop sending BFD Control packets and MAY 162 delete the BFD session created until the BFD Control packets is 163 initiated by the active side again. 165 When an Unsolicited BFD session goes down, an implementation MAY 166 retain the session state for a period of time, which may be 167 configurable. Retaining this state can be useful for operational 168 purposes. 170 The "Passive role" may change to the "Active role" when a local 171 client registers for the same BFD session, and from the "Active role" 172 to the "Passive role" when there is no longer any locally registered 173 client for the BFD session. 175 3. State Variables 177 This document defines a new state variable called Unsolicited Role. 179 bfd.UnsolicitedRole 181 The operational mode of BFD interface when configured for unsolicited 182 behaviour. Options can be either PASSIVE, ACTIVE or NULL (NULL - not 183 initialized) for unsolicited BFD sessions. Default (not configured 184 for unsolicited behaviour) MUST be set to NULL if present on the 185 interface. 187 4. YANG Data Model 189 This section extends the YANG data model for BFD [I-D.ietf-bfd-yang] 190 to cover the unsolicited BFD. 192 4.1. Unsolicited BFD Hierarchy 194 module: ietf-bfd-unsolicited 195 augment /rt:routing/rt:control-plane-protocols 196 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh: 197 +--rw unsolicited {bfd-unsol:unsolicited-params-global}? 198 +--rw enable? boolean 199 +--rw local-multiplier? multiplier 200 +--rw (interval-config-type)? 201 +--:(tx-rx-intervals) 202 | +--rw desired-min-tx-interval? uint32 203 | +--rw required-min-rx-interval? uint32 204 +--:(single-interval) {single-minimum-interval}? 205 +--rw min-interval? uint32 206 augment /rt:routing/rt:control-plane-protocols 207 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 208 /bfd-ip-sh:interfaces: 209 +--rw unsolicited {bfd-unsol:unsolicited-params-per-interface}? 210 +--rw enable? boolean 211 +--rw local-multiplier? multiplier 212 +--rw (interval-config-type)? 213 +--:(tx-rx-intervals) 214 | +--rw desired-min-tx-interval? uint32 215 | +--rw required-min-rx-interval? uint32 216 +--:(single-interval) {single-minimum-interval}? 217 +--rw min-interval? uint32 218 augment /rt:routing/rt:control-plane-protocols 219 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 220 /bfd-ip-sh:sessions/bfd-ip-sh:session: 221 +--ro unsolicited 222 +--ro role? bfd-unsol:unsolicited-role 224 4.2. Unsolicited BFD Module 226 file "ietf-bfd-unsolicited@2021-10-15.yang" 228 module ietf-bfd-unsolicited { 230 yang-version 1.1; 232 namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited"; 234 prefix "bfd-unsol"; 236 // RFC Ed.: replace occurences of YYYY with actual RFC numbers 237 // and remove this note 238 import ietf-bfd-types { 239 prefix "bfd-types"; 240 reference "RFC 9127: YANG Data Model for BFD"; 241 } 243 import ietf-bfd { 244 prefix "bfd"; 245 reference "RFC 9127: YANG Data Model for BFD"; 246 } 248 import ietf-bfd-ip-sh { 249 prefix "bfd-ip-sh"; 250 reference "RFC 9127: YANG Data Model for BFD"; 251 } 253 import ietf-routing { 254 prefix "rt"; 255 reference 256 "RFC 8349: A YANG Data Model for Routing Management 257 (NMDA version)"; 258 } 260 organization "IETF BFD Working Group"; 262 contact 263 "WG Web: 264 WG List: 266 Editors: Enke Chen (enchen@paloaltonetworks.com), 267 Naiming Shen (naiming@zededa.com), 268 Robert Raszuk (robert@raszuk.net), 269 Reshad Rahman (reshad@yahoo.com)"; 271 description 272 "This module contains the YANG definition for BFD unsolicited 273 as per RFC YYYY. 275 Copyright (c) 2021 IETF Trust and the persons 276 identified as authors of the code. All rights reserved. 278 Redistribution and use in source and binary forms, with or 279 without modification, is permitted pursuant to, and subject 280 to the license terms contained in, the Simplified BSD License 281 set forth in Section 4.c of the IETF Trust's Legal Provisions 282 Relating to IETF Documents 283 (http://trustee.ietf.org/license-info). 285 This version of this YANG module is part of RFC YYYY; see 286 the RFC itself for full legal notices."; 288 reference "RFC YYYY"; 290 revision 2021-10-15 { 291 description "Initial revision."; 292 reference "RFC 9127: A YANG data model for BFD unsolicited"; 293 } 295 /* 296 * Feature definitions 297 */ 298 feature unsolicited-params-global { 299 description 300 "This feature indicates that the server supports global 301 parameters for unsolicited sessions."; 302 } 304 feature unsolicited-params-per-interface { 305 description 306 "This feature indicates that the server supports per-interface 307 parameters for unsolicited sessions."; 308 } 310 /* 311 * Type Definitions 312 */ 313 typedef unsolicited-role { 314 type enumeration { 315 enum unsolicited-active { 316 description "Active role"; 317 } 318 enum unsolicited-passive { 319 description "Passive role"; 320 } 321 } 322 description "Unsolicited role"; 323 } 325 /* 326 * Augments 327 */ 328 augment "/rt:routing/rt:control-plane-protocols/" 329 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" { 330 description 331 "Augmentation for BFD unsolicited parameters"; 332 container unsolicited { 333 if-feature bfd-unsol:unsolicited-params-global; 334 description 335 "BFD unsolicited top level container"; 336 leaf enable { 337 type boolean; 338 default false; 339 description 340 "Enable BFD unsolicited globally for IP single-hop."; 341 } 342 uses bfd-types:base-cfg-parms; 343 } 344 } 346 augment "/rt:routing/rt:control-plane-protocols/" 347 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 348 + "bfd-ip-sh:interfaces" { 349 description 350 "Augmentation for BFD unsolicited on IP single-hop interface"; 351 container unsolicited { 352 if-feature bfd-unsol:unsolicited-params-per-interface; 353 description 354 "BFD IP single-hop interface unsolicited top level container"; 355 leaf enable { 356 type boolean; 357 default false; 358 description "Enable BFD unsolicited on this interface."; 359 } 360 uses bfd-types:base-cfg-parms; 361 } 362 } 364 augment "/rt:routing/rt:control-plane-protocols/" 365 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 366 + "bfd-ip-sh:sessions/bfd-ip-sh:session" { 367 description 368 "Augmentation for BFD unsolicited on IP single-hop session"; 369 container unsolicited { 370 config false; 371 description 372 "BFD IP single-hop session unsolicited top level container"; 373 leaf role { 374 type bfd-unsol:unsolicited-role; 375 description "Role."; 376 } 377 } 378 } 379 } 381 383 5. IANA Considerations 385 This documents makes no IANA requests. 387 6. Acknowledgments 389 Authors would like to thank Acee Lindem, Greg Mirsky, Jeffrey Haas 390 and Raj Chetan for their review and valuable input. 392 7. Security Considerations 394 7.1. BFD Protocol Security Considerations 396 The same security considerations and protection measures as those 397 described in [RFC5880] and [RFC5881] normatively apply to this 398 document. With "unsolicited BFD" there is potential risk for 399 excessive resource usage by BFD from "unexpected" remote systems. To 400 mitigate such risks, the following measures are mandatory: 402 o Limit the feature to specific interfaces, and to a single-hop BFD 403 with "TTL=255" [RFC5082]. For numbered interfaces source address 404 of an incoming BFD packet should belongs to the subnet of the 405 interface from which the BFD packet is received. For unnumbered 406 interfaces the above check should be aligned with routing protocol 407 addresses running on such pair of interfaces. 408 o Apply "access control" to allow BFD packets only from certain 409 subnets or hosts. 410 o Deploy the feature only in certain "trustworthy" environment, 411 e.g., at an IXP, or between a provider and its customers. 412 o Adjust BFD parameters as needed for the particular deployment and 413 scale. 414 o Use BFD authentication. 416 7.2. YANG Module Security Considerations 418 The YANG module specified in this document defines a schema for data 419 that is designed to be accessed via network management protocols such 420 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 421 is the secure transport layer, and the mandatory-to-implement secure 422 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 423 is HTTPS, and the mandatory-to-implement secure transport is TLS 424 [RFC5246]. 426 The NETCONF access control model [RFC6536] provides the means to 427 restrict access for particular NETCONF or RESTCONF users to a 428 preconfigured subset of all available NETCONF or RESTCONF protocol 429 operations and content. 431 There are a number of data nodes defined in this YANG module that are 432 writable/creatable/deletable (i.e., config true, which is the 433 default). These data nodes may be considered sensitive or vulnerable 434 in some network environments. Write operations (e.g., edit-config) 435 to these data nodes without proper protection can have a negative 436 effect on network operations. These are the subtrees and data nodes 437 and their sensitivity/vulnerability: 439 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 440 /unsolicited: 442 o data node "enable" enables creation of unsolicited BFD IP single- 443 hop sessions globally, i.e. on all interfaces. See Section 7.1. 444 o data nodes local-multiplier, desired-min-tx-interval, required- 445 min-rx-interval and min-interval all impact the parameters of the 446 unsolicited BFD IP single-hop sessions. 448 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 449 /interfaces/interface/unsolicited: 451 o data node "enable" enables creation of unsolicited BFD IP single- 452 hop sessions on a specific interface. See Section 7.1. 453 o data nodes local-multiplier, desired-min-tx-interval, required- 454 min-rx-interval and min-interval all impact the parameters of the 455 unsolicited BFD IP single-hop sessions on the interface. 457 Some of the readable data nodes in this YANG module may be considered 458 sensitive or vulnerable in some network environments. It is thus 459 important to control read access (e.g., via get, get-config, or 460 notification) to these data nodes. These are the subtrees and data 461 nodes and their sensitivity/vulnerability: 463 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 464 /sessions/session/unsolicited: access to this information discloses 465 the role of the local system in the creation of the unsolicited BFD 466 session. 468 8. References 470 8.1. Normative References 472 [I-D.ietf-bfd-yang] 473 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 474 and G. Mirsky, "YANG Data Model for Bidirectional 475 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 476 in progress), August 2018. 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 484 Pignataro, "The Generalized TTL Security Mechanism 485 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 486 . 488 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 489 (TLS) Protocol Version 1.2", RFC 5246, 490 DOI 10.17487/RFC5246, August 2008, 491 . 493 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 494 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 495 . 497 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 498 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 499 DOI 10.17487/RFC5881, June 2010, 500 . 502 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 503 and A. Bierman, Ed., "Network Configuration Protocol 504 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 505 . 507 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 508 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 509 . 511 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 512 Protocol (NETCONF) Access Control Model", RFC 6536, 513 DOI 10.17487/RFC6536, March 2012, 514 . 516 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 517 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 518 . 520 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 521 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 522 May 2017, . 524 8.2. Informative References 526 [I-D.ietf-idr-rs-bfd] 527 Bush, R., Haas, J., Scudder, J. G., Nipper, A., and C. 528 Dietzel, "Making Route Servers Aware of Data Link Failures 529 at IXPs", draft-ietf-idr-rs-bfd-09 (work in progress), 530 September 2020. 532 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 533 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 534 DOI 10.17487/RFC4271, January 2006, 535 . 537 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 538 Pallagatti, "Seamless Bidirectional Forwarding Detection 539 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 540 . 542 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 543 "Advertisement of Multiple Paths in BGP", RFC 7911, 544 DOI 10.17487/RFC7911, July 2016, 545 . 547 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 548 "Internet Exchange BGP Route Server", RFC 7947, 549 DOI 10.17487/RFC7947, September 2016, 550 . 552 Authors' Addresses 554 Enke Chen 555 Palo Alto Networks 557 Email: enchen@paloaltonetworks.com 559 Naiming Shen 560 Zededa 562 Email: naiming@zededa.com 563 Robert Raszuk 564 NTT Network Innovations 565 940 Stewart Dr 566 Sunnyvale, CA 94085 567 USA 569 Email: robert@raszuk.net 571 Reshad Rahman 573 Email: reshad@yahoo.com