idnits 2.17.1 draft-ietf-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: ---------------------------------------------------------------------------- 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 (April 22, 2021) is 1071 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) -- No information found for draft-ietf-bfd-yang - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-bfd-yang' ** 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 (==), 3 comments (--). 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: October 24, 2021 Zededa 6 R. Raszuk 7 NTT Network Innovations 8 R. Rahman 9 April 22, 2021 11 Unsolicited BFD for Sessionless Applications 12 draft-ietf-bfd-unsolicited-03 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 October 24, 2021. 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. 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 6.1. BFD Protocol Security Considerations . . . . . . . . . . 9 74 6.2. YANG Module Security Considerations . . . . . . . . . . . 9 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 7.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 o 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 o 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 explicitely 141 configured on an interface or globally (apply to all interfaces). 142 The BFD parameters can be either per-interface or per-router based. 144 It MAY also choose to use the parameters that the active side uses in 145 its BFD Control packets. The "My Discriminator", however, MUST be 146 chosen to allow multiple unsolicited BFD sessions. 148 The active side starts sending the BFD Control packets as specified 149 in [RFC5880]. The passive side does not send BFD Control packets. 151 When the passive side receives a BFD Control packet from the active 152 side with 0 as "Your Discriminator", and it does not find an existing 153 session with the same source address and the same "Discriminator" 154 pairs as in the packet and "unsolicited BFD" is allowed on the 155 interface by local policy, it SHOULD then create a matching BFD 156 session toward the active side (based on the source address and 157 destination address in the BFD Control packet) as if the session were 158 locally registered. It would then start sending the BFD Control 159 packets and perform necessary procedure for bringing up, maintaining 160 and tearing down the BFD session. If the BFD session fails to get 161 established within certain specified time, or if an established BFD 162 session goes down, the passive side would stop sending BFD Control 163 packets and delete the BFD session created until the BFD Control 164 packets is initiated by the active side again. 166 The "Passive role" may change to the "Active role" when a local 167 client registers for the same BFD session, and from the "Active role 168 " to the "Passive role " when there is no longer any locally 169 registered client for the BFD session. 171 3. YANG Data Model 173 This section extends the YANG data model for BFD [I-D.ietf-bfd-yang] 174 to cover the unsolicited BFD. 176 3.1. Unsolicited BFD Hierarchy 177 module: ietf-bfd-unsolicited 178 augment /rt:routing/rt:control-plane-protocols 179 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh: 180 +--rw unsolicited {bfd-unsol:unsolicited-params-global}? 181 +--rw enable? boolean 182 +--rw local-multiplier? multiplier 183 +--rw (interval-config-type)? 184 +--:(tx-rx-intervals) 185 | +--rw desired-min-tx-interval? uint32 186 | +--rw required-min-rx-interval? uint32 187 +--:(single-interval) {single-minimum-interval}? 188 +--rw min-interval? uint32 189 augment /rt:routing/rt:control-plane-protocols 190 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 191 /bfd-ip-sh:interfaces: 192 +--rw unsolicited {bfd-unsol:unsolicited-params-per-interface}? 193 +--rw enable? boolean 194 +--rw local-multiplier? multiplier 195 +--rw (interval-config-type)? 196 +--:(tx-rx-intervals) 197 | +--rw desired-min-tx-interval? uint32 198 | +--rw required-min-rx-interval? uint32 199 +--:(single-interval) {single-minimum-interval}? 200 +--rw min-interval? uint32 201 augment /rt:routing/rt:control-plane-protocols 202 /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh 203 /bfd-ip-sh:sessions/bfd-ip-sh:session: 204 +--ro unsolicited 205 +--ro role? bfd-unsol:unsolicited-role 207 3.2. Unsolicited BFD Module 209 file "ietf-bfd-unsolicited@2019-06-26.yang" 211 module ietf-bfd-unsolicited { 213 yang-version 1.1; 215 namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-unsolicited"; 217 prefix "bfd-unsol"; 219 // RFC Ed.: replace occurences of XXXX/YYYY with actual RFC numbers 220 // and remove this note 222 import ietf-bfd-types { 223 prefix "bfd-types"; 224 reference "RFC XXXX: YANG Data Model for BFD"; 225 } 227 import ietf-bfd { 228 prefix "bfd"; 229 reference "RFC XXXX: YANG Data Model for BFD"; 230 } 232 import ietf-bfd-ip-sh { 233 prefix "bfd-ip-sh"; 234 reference "RFC XXXX: YANG Data Model for BFD"; 235 } 237 import ietf-routing { 238 prefix "rt"; 239 reference 240 "RFC 8349: A YANG Data Model for Routing Management 241 (NMDA version)"; 242 } 244 organization "IETF BFD Working Group"; 246 contact 247 "WG Web: 248 WG List: 250 Editors: Enke Chen (enchen@paloaltonetworks.com), 251 Naiming Shen (naiming@zededa.com), 252 Robert Raszuk (robert@raszuk.net), 253 Reshad Rahman (reshad@yahoo.com)"; 255 description 256 "This module contains the YANG definition for BFD unsolicited 257 as per RFC YYYY. 259 Copyright (c) 2018 IETF Trust and the persons 260 identified as authors of the code. All rights reserved. 262 Redistribution and use in source and binary forms, with or 263 without modification, is permitted pursuant to, and subject 264 to the license terms contained in, the Simplified BSD License 265 set forth in Section 4.c of the IETF Trust's Legal Provisions 266 Relating to IETF Documents 267 (http://trustee.ietf.org/license-info). 269 This version of this YANG module is part of RFC XXXX; see 270 the RFC itself for full legal notices."; 272 reference "RFC YYYY"; 274 revision 2019-06-26 { 275 description "Initial revision."; 276 reference "RFC YYYY: A YANG data model for BFD unsolicited"; 277 } 279 /* 280 * Feature definitions 281 */ 282 feature unsolicited-params-global { 283 description 284 "This feature indicates that the server supports global 285 parameters for unsolicited sessions."; 286 } 288 feature unsolicited-params-per-interface { 289 description 290 "This feature indicates that the server supports per-interface 291 parameters for unsolicited sessions."; 292 } 294 /* 295 * Type Definitions 296 */ 297 typedef unsolicited-role { 298 type enumeration { 299 enum unsolicited-active { 300 description "Active role"; 301 } 302 enum unsolicited-passive { 303 description "Passive role"; 304 } 305 } 306 description "Unsolicited role"; 307 } 309 /* 310 * Augments 311 */ 312 augment "/rt:routing/rt:control-plane-protocols/" 313 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh" { 314 description 315 "Augmentation for BFD unsolicited parameters"; 316 container unsolicited { 317 if-feature bfd-unsol:unsolicited-params-global; 318 description 319 "BFD unsolicited top level container"; 321 leaf enable { 322 type boolean; 323 default false; 324 description 325 "Enable BFD unsolicited globally for IP single-hop."; 326 } 327 uses bfd-types:base-cfg-parms; 328 } 329 } 331 augment "/rt:routing/rt:control-plane-protocols/" 332 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 333 + "bfd-ip-sh:interfaces" { 334 description 335 "Augmentation for BFD unsolicited on IP single-hop interface"; 336 container unsolicited { 337 if-feature bfd-unsol:unsolicited-params-per-interface; 338 description 339 "BFD IP single-hop interface unsolicited top level container"; 340 leaf enable { 341 type boolean; 342 default false; 343 description "Enable BFD unsolicited on this interface."; 344 } 345 uses bfd-types:base-cfg-parms; 346 } 347 } 349 augment "/rt:routing/rt:control-plane-protocols/" 350 + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" 351 + "bfd-ip-sh:sessions/bfd-ip-sh:session" { 352 description 353 "Augmentation for BFD unsolicited on IP single-hop session"; 354 container unsolicited { 355 config false; 356 description 357 "BFD IP single-hop session unsolicited top level container"; 358 leaf role { 359 type bfd-unsol:unsolicited-role; 360 description "Role."; 361 } 362 } 363 } 364 } 366 368 4. IANA Considerations 370 This documents makes no IANA requests. 372 5. Acknowledgments 374 Authors would like to thank Acee Lindem, Greg Mirsky and Raj Chetan 375 for their review and valuable input. 377 6. Security Considerations 379 6.1. BFD Protocol Security Considerations 381 The same security considerations as those described in [RFC5880] and 382 [RFC5881] apply to this document. With "unsolicited BFD" there is 383 potential risk for excessive resource usage by BFD from "unexpected" 384 remote systems. To mitigate such risks, the following measures are 385 RECOMMENDED: 387 o Limit the feature to specific interfaces, and to a single-hop BFD 388 with "TTL=255" [RFC5082]. For numbered interfaces source address 389 of an incoming BFD packet should belongs to the subnet of the 390 interface from which the BFD packet is received. For unnumbered 391 interfaces the above check should be alinged with routing protocol 392 addresses running on such pair of interfaces. 393 o Apply "access control" to allow BFD packets only from certain 394 subnets or hosts. 395 o Deploy the feature only in certain "trustworthy" environment, 396 e.g., at an IXP, or between a provider and its customers. 397 o Adjust BFD parameters as needed for the particular deployment and 398 scale. 399 o Use BFD authentication. 401 6.2. YANG Module Security Considerations 403 The YANG module specified in this document defines a schema for data 404 that is designed to be accessed via network management protocols such 405 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 406 is the secure transport layer, and the mandatory-to-implement secure 407 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 408 is HTTPS, and the mandatory-to-implement secure transport is TLS 409 [RFC5246]. 411 The NETCONF access control model [RFC6536] provides the means to 412 restrict access for particular NETCONF or RESTCONF users to a 413 preconfigured subset of all available NETCONF or RESTCONF protocol 414 operations and content. 416 There are a number of data nodes defined in this YANG module that are 417 writable/creatable/deletable (i.e., config true, which is the 418 default). These data nodes may be considered sensitive or vulnerable 419 in some network environments. Write operations (e.g., edit-config) 420 to these data nodes without proper protection can have a negative 421 effect on network operations. These are the subtrees and data nodes 422 and their sensitivity/vulnerability: 424 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 425 /unsolicited: 427 o data node "enable" enables creation of unsolicited BFD IP single- 428 hop sessions globally, i.e. on all interfaces. See Section 6.1. 429 o data nodes local-multiplier, desired-min-tx-interval, required- 430 min-rx-interval and min-interval all impact the parameters of the 431 unsolicited BFD IP single-hop sessions. 433 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 434 /interfaces/interface/unsolicited: 436 o data node "enable" enables creation of unsolicited BFD IP single- 437 hop sessions on a specific interface. See Section 6.1. 438 o data nodes local-multiplier, desired-min-tx-interval, required- 439 min-rx-interval and min-interval all impact the parameters of the 440 unsolicited BFD IP single-hop sessions on the interface. 442 Some of the readable data nodes in this YANG module may be considered 443 sensitive or vulnerable in some network environments. It is thus 444 important to control read access (e.g., via get, get-config, or 445 notification) to these data nodes. These are the subtrees and data 446 nodes and their sensitivity/vulnerability: 448 /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh 449 /sessions/session/unsolicited: access to this information discloses 450 the role of the local system in the creation of the unsolicited BFD 451 session. 453 7. References 455 7.1. Normative References 457 [I-D.ietf-bfd-yang] 458 Rahman, R., Zheng, L., Jethanandani, M., Pallagatti, S., 459 and G. Mirsky, "YANG Data Model for Bidirectional 460 Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work 461 in progress), August 2018. 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, 465 DOI 10.17487/RFC2119, March 1997, 466 . 468 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 469 Pignataro, "The Generalized TTL Security Mechanism 470 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 471 . 473 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 474 (TLS) Protocol Version 1.2", RFC 5246, 475 DOI 10.17487/RFC5246, August 2008, 476 . 478 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 479 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 480 . 482 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 483 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 484 DOI 10.17487/RFC5881, June 2010, 485 . 487 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 488 and A. Bierman, Ed., "Network Configuration Protocol 489 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 490 . 492 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 493 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 494 . 496 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 497 Protocol (NETCONF) Access Control Model", RFC 6536, 498 DOI 10.17487/RFC6536, March 2012, 499 . 501 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 502 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 503 . 505 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 506 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 507 May 2017, . 509 7.2. Informative References 511 [I-D.ietf-idr-rs-bfd] 512 Bush, R., Haas, J., Scudder, J., Nipper, A., and C. 513 Dietzel, "Making Route Servers Aware of Data Link Failures 514 at IXPs", draft-ietf-idr-rs-bfd-09 (work in progress), 515 September 2020. 517 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 518 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 519 DOI 10.17487/RFC4271, January 2006, 520 . 522 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 523 Pallagatti, "Seamless Bidirectional Forwarding Detection 524 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 525 . 527 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 528 "Advertisement of Multiple Paths in BGP", RFC 7911, 529 DOI 10.17487/RFC7911, July 2016, 530 . 532 [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 533 "Internet Exchange BGP Route Server", RFC 7947, 534 DOI 10.17487/RFC7947, September 2016, 535 . 537 Authors' Addresses 539 Enke Chen 540 Palo Alto Networks 542 Email: enchen@paloaltonetworks.com 544 Naiming Shen 545 Zededa 547 Email: naiming@zededa.com 548 Robert Raszuk 549 NTT Network Innovations 550 940 Stewart Dr 551 Sunnyvale, CA 94085 552 USA 554 Email: robert@raszuk.net 556 Reshad Rahman 558 Email: reshad@yahoo.com