idnits 2.17.1 draft-ietf-bfd-unsolicited-04.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 15, 2021) is 923 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 18, 2022 Zededa 6 R. Raszuk 7 NTT Network Innovations 8 R. Rahman 9 October 15, 2021 11 Unsolicited BFD for Sessionless Applications 12 draft-ietf-bfd-unsolicited-04 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 18, 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 . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 11 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 it does not find an existing 154 session with the same source address and the same "Discriminator" 155 pairs as in the packet and "unsolicited BFD" is allowed on the 156 interface by local policy, it MUST create a matching BFD session 157 toward the active side (based on the source address and destination 158 address in the BFD Control packet) as if the session were locally 159 registered. It would then start sending the BFD Control packets and 160 perform necessary procedure for bringing up, maintaining and tearing 161 down the BFD session. If the BFD session fails to get established 162 within certain specified time, or if an established BFD session goes 163 down, the passive side would stop sending BFD Control packets and MAY 164 delete the BFD session created until the BFD Control packets is 165 initiated by the active side again. 167 When on the passive side Unsolicited BFD sessions goes down an 168 implementation MAY keep such session state for a configurable amount 169 of time. Temporarily keeping such local state may permit retrieving 170 additional operational information of such session which went down. 172 The "Passive role" may change to the "Active role" when a local 173 client registers for the same BFD session, and from the "Active role 174 " to the "Passive role " when there is no longer any locally 175 registered client for the BFD session. 177 3. State Variables 179 This document defines a new state variable called Unsolicited Role. 181 bfd.UnsolicitedRole 183 The operational mode of BFD interface when configured for unsolicited 184 behaviour. Options can be either PASSIVE, ACTIVE or NULL (NULL - not 185 initialized) for unsolicited BFD sessions. Default (not configured 186 for unsolicited behaviour) MUST be set to NULL if present on the 187 interface. 189 4. YANG Data Model 191 This section extends the YANG data model for BFD [I-D.ietf-bfd-yang] 192 to cover the unsolicited BFD. 194 4.1. Unsolicited BFD Hierarchy 196 module: ietf-bfd-unsolicited 197 augment /rt:routing/rt:control-plane-protocols 198 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh: 199 +--rw unsolicited {bfd-unsol:unsolicited-params-global}? 200 +--rw enable? boolean 201 +--rw local-multiplier? multiplier 202 +--rw (interval-config-type)? 203 +--:(tx-rx-intervals) 204 | +--rw desired-min-tx-interval? uint32 205 | +--rw required-min-rx-interval? uint32 206 +--:(single-interval) {single-minimum-interval}? 207 +--rw min-interval? uint32 208 augment /rt:routing/rt:control-plane-protocols 209 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 210 /bfd-ip-sh:interfaces: 211 +--rw unsolicited {bfd-unsol:unsolicited-params-per-interface}? 212 +--rw enable? boolean 213 +--rw local-multiplier? multiplier 214 +--rw (interval-config-type)? 215 +--:(tx-rx-intervals) 216 | +--rw desired-min-tx-interval? uint32 217 | +--rw required-min-rx-interval? uint32 218 +--:(single-interval) {single-minimum-interval}? 219 +--rw min-interval? uint32 220 augment /rt:routing/rt:control-plane-protocols 221 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 222 /bfd-ip-sh:sessions/bfd-ip-sh:session: 223 +--ro unsolicited 224 +--ro role? bfd-unsol:unsolicited-role 226 4.2. Unsolicited BFD Module 228 file "ietf-bfd-unsolicited@2021-10-15.yang" 230 module ietf-bfd-unsolicited { 232 yang-version 1.1; 234 namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited"; 235 prefix "bfd-unsol"; 237 // RFC Ed.: replace occurences of YYYY with actual RFC numbers 238 // and remove this note 240 import ietf-bfd-types { 241 prefix "bfd-types"; 242 reference "RFC 9127: YANG Data Model for BFD"; 243 } 245 import ietf-bfd { 246 prefix "bfd"; 247 reference "RFC 9127: YANG Data Model for BFD"; 248 } 250 import ietf-bfd-ip-sh { 251 prefix "bfd-ip-sh"; 252 reference "RFC 9127: YANG Data Model for BFD"; 253 } 255 import ietf-routing { 256 prefix "rt"; 257 reference 258 "RFC 8349: A YANG Data Model for Routing Management 259 (NMDA version)"; 260 } 262 organization "IETF BFD Working Group"; 264 contact 265 "WG Web: 266 WG List: 268 Editors: Enke Chen (enchen@paloaltonetworks.com), 269 Naiming Shen (naiming@zededa.com), 270 Robert Raszuk (robert@raszuk.net), 271 Reshad Rahman (reshad@yahoo.com)"; 273 description 274 "This module contains the YANG definition for BFD unsolicited 275 as per RFC YYYY. 277 Copyright (c) 2021 IETF Trust and the persons 278 identified as authors of the code. All rights reserved. 280 Redistribution and use in source and binary forms, with or 281 without modification, is permitted pursuant to, and subject 282 to the license terms contained in, the Simplified BSD License 283 set forth in Section 4.c of the IETF Trust's Legal Provisions 284 Relating to IETF Documents 285 (http://trustee.ietf.org/license-info). 287 This version of this YANG module is part of RFC YYYY; see 288 the RFC itself for full legal notices."; 290 reference "RFC YYYY"; 292 revision 2021-10-15 { 293 description "Initial revision."; 294 reference "RFC 9127: A YANG data model for BFD unsolicited"; 295 } 297 /* 298 * Feature definitions 299 */ 300 feature unsolicited-params-global { 301 description 302 "This feature indicates that the server supports global 303 parameters for unsolicited sessions."; 304 } 306 feature unsolicited-params-per-interface { 307 description 308 "This feature indicates that the server supports per-interface 309 parameters for unsolicited sessions."; 310 } 312 /* 313 * Type Definitions 314 */ 315 typedef unsolicited-role { 316 type enumeration { 317 enum unsolicited-active { 318 description "Active role"; 319 } 320 enum unsolicited-passive { 321 description "Passive role"; 322 } 323 } 324 description "Unsolicited role"; 325 } 327 /* 328 * Augments 329 */ 330 augment "/rt:routing/rt:control-plane-protocols/" 331 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" { 332 description 333 "Augmentation for BFD unsolicited parameters"; 334 container unsolicited { 335 if-feature bfd-unsol:unsolicited-params-global; 336 description 337 "BFD unsolicited top level container"; 338 leaf enable { 339 type boolean; 340 default false; 341 description 342 "Enable BFD unsolicited globally for IP single-hop."; 343 } 344 uses bfd-types:base-cfg-parms; 345 } 346 } 348 augment "/rt:routing/rt:control-plane-protocols/" 349 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 350 + "bfd-ip-sh:interfaces" { 351 description 352 "Augmentation for BFD unsolicited on IP single-hop interface"; 353 container unsolicited { 354 if-feature bfd-unsol:unsolicited-params-per-interface; 355 description 356 "BFD IP single-hop interface unsolicited top level container"; 357 leaf enable { 358 type boolean; 359 default false; 360 description "Enable BFD unsolicited on this interface."; 361 } 362 uses bfd-types:base-cfg-parms; 363 } 364 } 366 augment "/rt:routing/rt:control-plane-protocols/" 367 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 368 + "bfd-ip-sh:sessions/bfd-ip-sh:session" { 369 description 370 "Augmentation for BFD unsolicited on IP single-hop session"; 371 container unsolicited { 372 config false; 373 description 374 "BFD IP single-hop session unsolicited top level container"; 375 leaf role { 376 type bfd-unsol:unsolicited-role; 377 description "Role."; 378 } 380 } 381 } 382 } 384 386 5. IANA Considerations 388 This documents makes no IANA requests. 390 6. Acknowledgments 392 Authors would like to thank Acee Lindem, Greg Mirsky and Raj Chetan 393 for their review and valuable input. 395 7. Security Considerations 397 7.1. BFD Protocol Security Considerations 399 The same security considerations and protection measures as those 400 described in [RFC5880] and [RFC5881] normatively apply to this 401 document. With "unsolicited BFD" there is potential risk for 402 excessive resource usage by BFD from "unexpected" remote systems. To 403 mitigate such risks, the following measures are mandatory: 405 o Limit the feature to specific interfaces, and to a single-hop BFD 406 with "TTL=255" [RFC5082]. For numbered interfaces source address 407 of an incoming BFD packet should belongs to the subnet of the 408 interface from which the BFD packet is received. For unnumbered 409 interfaces the above check should be aligned with routing protocol 410 addresses running on such pair of interfaces. 411 o Apply "access control" to allow BFD packets only from certain 412 subnets or hosts. 413 o Deploy the feature only in certain "trustworthy" environment, 414 e.g., at an IXP, or between a provider and its customers. 415 o Adjust BFD parameters as needed for the particular deployment and 416 scale. 417 o Use BFD authentication. 419 7.2. YANG Module Security Considerations 421 The YANG module specified in this document defines a schema for data 422 that is designed to be accessed via network management protocols such 423 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 424 is the secure transport layer, and the mandatory-to-implement secure 425 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 426 is HTTPS, and the mandatory-to-implement secure transport is TLS 427 [RFC5246]. 429 The NETCONF access control model [RFC6536] provides the means to 430 restrict access for particular NETCONF or RESTCONF users to a 431 preconfigured subset of all available NETCONF or RESTCONF protocol 432 operations and content. 434 There are a number of data nodes defined in this YANG module that are 435 writable/creatable/deletable (i.e., config true, which is the 436 default). These data nodes may be considered sensitive or vulnerable 437 in some network environments. Write operations (e.g., edit-config) 438 to these data nodes without proper protection can have a negative 439 effect on network operations. These are the subtrees and data nodes 440 and their sensitivity/vulnerability: 442 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 443 /unsolicited: 445 o data node "enable" enables creation of unsolicited BFD IP single- 446 hop sessions globally, i.e. on all interfaces. See Section 7.1. 447 o data nodes local-multiplier, desired-min-tx-interval, required- 448 min-rx-interval and min-interval all impact the parameters of the 449 unsolicited BFD IP single-hop sessions. 451 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 452 /interfaces/interface/unsolicited: 454 o data node "enable" enables creation of unsolicited BFD IP single- 455 hop sessions on a specific interface. See Section 7.1. 456 o data nodes local-multiplier, desired-min-tx-interval, required- 457 min-rx-interval and min-interval all impact the parameters of the 458 unsolicited BFD IP single-hop sessions on the interface. 460 Some of the readable data nodes in this YANG module may be considered 461 sensitive or vulnerable in some network environments. It is thus 462 important to control read access (e.g., via get, get-config, or 463 notification) to these data nodes. These are the subtrees and data 464 nodes and their sensitivity/vulnerability: 466 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 467 /sessions/session/unsolicited: access to this information discloses 468 the role of the local system in the creation of the unsolicited BFD 469 session. 471 8. References 472 8.1. Normative References 474 [I-D.ietf-bfd-yang] 475 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 476 and G. Mirsky, "YANG Data Model for Bidirectional 477 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 478 in progress), August 2018. 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 486 Pignataro, "The Generalized TTL Security Mechanism 487 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 488 . 490 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 491 (TLS) Protocol Version 1.2", RFC 5246, 492 DOI 10.17487/RFC5246, August 2008, 493 . 495 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 496 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 497 . 499 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 500 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 501 DOI 10.17487/RFC5881, June 2010, 502 . 504 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 505 and A. Bierman, Ed., "Network Configuration Protocol 506 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 507 . 509 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 510 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 511 . 513 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 514 Protocol (NETCONF) Access Control Model", RFC 6536, 515 DOI 10.17487/RFC6536, March 2012, 516 . 518 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 519 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 520 . 522 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 523 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 524 May 2017, . 526 8.2. Informative References 528 [I-D.ietf-idr-rs-bfd] 529 Bush, R., Haas, J., Scudder, J. G., Nipper, A., and C. 530 Dietzel, "Making Route Servers Aware of Data Link Failures 531 at IXPs", draft-ietf-idr-rs-bfd-09 (work in progress), 532 September 2020. 534 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 535 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 536 DOI 10.17487/RFC4271, January 2006, 537 . 539 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 540 Pallagatti, "Seamless Bidirectional Forwarding Detection 541 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 542 . 544 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 545 "Advertisement of Multiple Paths in BGP", RFC 7911, 546 DOI 10.17487/RFC7911, July 2016, 547 . 549 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 550 "Internet Exchange BGP Route Server", RFC 7947, 551 DOI 10.17487/RFC7947, September 2016, 552 . 554 Authors' Addresses 556 Enke Chen 557 Palo Alto Networks 559 Email: enchen@paloaltonetworks.com 561 Naiming Shen 562 Zededa 564 Email: naiming@zededa.com 565 Robert Raszuk 566 NTT Network Innovations 567 940 Stewart Dr 568 Sunnyvale, CA 94085 569 USA 571 Email: robert@raszuk.net 573 Reshad Rahman 575 Email: reshad@yahoo.com