idnits 2.17.1 draft-ietf-bfd-seamless-base-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5880, updated by this document, for RFC5378 checks: 2004-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 19, 2015) is 3231 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 (-19) exists of draft-ietf-bfd-multipoint-06 == Outdated reference: A later version (-08) exists of draft-ietf-bfd-seamless-use-case-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force N. Akiya 3 Internet-Draft Big Switch Networks 4 Updates: 5880 (if approved) C. Pignataro 5 Intended status: Standards Track D. Ward 6 Expires: December 21, 2015 Cisco Systems 7 M. Bhatia 8 Ionos Networks 9 S. Pallagatti 10 Juniper Networks 11 June 19, 2015 13 Seamless Bidirectional Forwarding Detection (S-BFD) 14 draft-ietf-bfd-seamless-base-05 16 Abstract 18 This document defines a simplified mechanism to use Bidirectional 19 Forwarding Detection (BFD) with large portions of negotiation aspects 20 eliminated, thus providing benefits such as quick provisioning as 21 well as improved control and flexibility to network nodes initiating 22 the path monitoring. 24 This document updates RFC5880. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 21, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Seamless BFD Overview . . . . . . . . . . . . . . . . . . . . 4 69 4. S-BFD Discriminators . . . . . . . . . . . . . . . . . . . . 5 70 4.1. S-BFD Discriminator Uniqueness . . . . . . . . . . . . . 5 71 4.2. Discriminator Pools . . . . . . . . . . . . . . . . . . . 6 72 5. Reflector BFD Session . . . . . . . . . . . . . . . . . . . . 7 73 6. State Variables . . . . . . . . . . . . . . . . . . . . . . . 7 74 6.1. New State Variables . . . . . . . . . . . . . . . . . . . 7 75 6.2. State Variable Initialization and Maintenance . . . . . . 8 76 7. S-BFD Procedures . . . . . . . . . . . . . . . . . . . . . . 8 77 7.1. Demultiplexing of S-BFD Control Packet . . . . . . . . . 8 78 7.2. Initiator Procedures . . . . . . . . . . . . . . . . . . 9 79 7.2.1. SBFDInitiator State Machine . . . . . . . . . . . . . 10 80 7.2.2. Transmission of S-BFD Control Packet by SBFDInitiator 10 81 7.3. Responder Procedures . . . . . . . . . . . . . . . . . . 12 82 7.3.1. Responder Demultiplexing . . . . . . . . . . . . . . 12 83 7.3.2. Transmission of S-BFD Control Packet by SBFDReflector 13 84 7.4. Diagnostic Values . . . . . . . . . . . . . . . . . . . . 14 85 7.5. The Poll Sequence . . . . . . . . . . . . . . . . . . . . 14 86 7.6. Control Plane Independent (C) . . . . . . . . . . . . . . 15 87 7.7. Additional SBFDInitiator Behaviors . . . . . . . . . . . 15 88 7.8. Additional SBFDReflector Behaviors . . . . . . . . . . . 15 89 8. Scaling Aspect . . . . . . . . . . . . . . . . . . . . . . . 16 90 9. Co-existence with Classical BFD Sessions . . . . . . . . . . 16 91 10. S-BFD Echo Function . . . . . . . . . . . . . . . . . . . . . 16 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 93 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 95 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 96 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 98 15.2. Informative References . . . . . . . . . . . . . . . . . 19 99 Appendix A. Loop Problem . . . . . . . . . . . . . . . . . . . . 20 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 102 1. Introduction 104 Bidirectional Forwarding Detection (BFD), [RFC5880] and related 105 documents, has efficiently generalized the failure detection 106 mechanism for multiple protocols and applications. There are some 107 improvements which can be made to better fit existing technologies. 108 There is a possibility of evolving BFD to better fit new 109 technologies. This document focuses on several aspects of BFD in 110 order to further improve efficiency, to expand failure detection 111 coverage and to allow BFD usage for wider scenarios. This document 112 extends BFD to provide solutions to use cases listed in 113 [I-D.ietf-bfd-seamless-use-case]. 115 One key aspect of the mechanism described in this document eliminates 116 the time between a network node wanting to perform a continuity test 117 and completing the continuity test. In traditional BFD terms, the 118 initial state changes from DOWN to UP are virtually nonexistent. 119 Removal of this seam (i.e., time delay) in BFD provides applications 120 a smooth and continuous operational experience. Therefore, "Seamless 121 BFD" (S-BFD) has been chosen as the name for this mechanism. 123 2. Terminology 125 The reader is expected to be familiar with the BFD, IP and MPLS 126 terminologies and protocol constructs. This section describes 127 several new terminologies introduced by S-BFD. 129 o Classical BFD - BFD session types based on [RFC5880]. 131 o S-BFD - Seamless BFD. 133 o S-BFD control packet - a BFD control packet for the S-BFD 134 mechanism. 136 o S-BFD echo packet - a BFD echo packet for the S-BFD mechanism. 138 o S-BFD packet - a BFD control packet or a BFD echo packet. 140 o Entity - a function on a network node that S-BFD mechanism allows 141 remote network nodes to perform continuity test to. An entity can 142 be abstract (e.g., reachability) or specific (e.g., IP addresses, 143 router-IDs, functions). 145 o SBFDInitiator - an S-BFD session on a network node that performs a 146 continuity test to a remote entity by sending S-BFD packets. 148 o SBFDReflector - an S-BFD session on a network node that listens 149 for incoming S-BFD control packets to local entities and generates 150 response S-BFD control packets. 152 o Reflector BFD session - synonymous with SBFDReflector. 154 o S-BFD discriminator - a BFD discriminator allocated for a local 155 entity and is being listened by an SBFDReflector. 157 o BFD discriminator - a BFD discriminator allocated for an 158 SBFDInitiator. 160 o Initiator - a network node hosting an SBFDInitiator. 162 o Responder - a network node hosting an SBFDReflector. 164 Below figure describes the relationship between S-BFD terminologies. 166 +---------------------+ +------------------------+ 167 | Initiator | | Responder | 168 | +-----------------+ | | +-----------------+ | 169 | | SBFDInitiator |---S-BFD ctrl pkt----->| SBFDReflector | | 170 | | +-------------+ |<--S-BFD ctrl pkt------| +-------------+ | | 171 | | | BFD discrim | | | | | |S-BFD discrim| | | 172 | | | | |---S-BFD echo pkt---+ | | | | | 173 | | +-------------+ | | | | | +----------^--+ | | 174 | +-----------------+<-------------------+ +------------|----+ | 175 | | | | | 176 | | | +---v----+ | 177 | | | | Entity | | 178 | | | +--------+ | 179 +---------------------+ +------------------------+ 181 Figure 1: S-BFD Terminology Relationship 183 3. Seamless BFD Overview 185 An S-BFD module on each network node allocates one or more S-BFD 186 discriminators for local entities, and creates a reflector BFD 187 session. Allocated S-BFD discriminators may be advertised by 188 applications (e.g., OSPF/IS-IS). Required result is that 189 applications, on other network nodes, possess the knowledge of the 190 mapping from remote entities to S-BFD discriminators. The reflector 191 BFD session is to, upon receiving an S-BFD control packet targeted to 192 one of local S-BFD discriminator values, transmit a response S-BFD 193 control packet back to the initiator. 195 Once above setup is complete, any network nodes, having the knowledge 196 of the mapping from a remote entity to an S-BFD discriminator, can 197 quickly perform a continuity test to the remote entity by simply 198 sending S-BFD control packets with corresponding S-BFD discriminator 199 value in the "your discriminator" field. 201 For example: 203 <------- IS-IS Network -------> 205 +---------+ 206 | | 207 A---------B---------C---------D 208 ^ ^ 209 | | 210 SystemID SystemID 211 xxx yyy 212 BFD Discrim BFD Discrim 213 123 456 215 Figure 2: S-BFD for IS-IS Network 217 The IS-IS with SystemID xxx (node A) allocates an S-BFD discriminator 218 123, and advertises the S-BFD discriminator 123 in an IS-IS TLV. The 219 IS-IS with SystemID yyy (node D) allocates an S-BFD discriminator 220 456, and advertises the S-BFD discriminator 456 in an IS-IS TLV. A 221 reflector BFD session is created on both network nodes (node A and 222 node D). When network node A wants to check the reachability to 223 network node D, node A can send an S-BFD control packet, destined to 224 node D, with "your discriminator" field set to 456. When the 225 reflector BFD session on node D receives this S-BFD control packet, 226 then response S-BFD control packet is sent back to node A, which 227 allows node A to complete the continuity test. 229 4. S-BFD Discriminators 231 4.1. S-BFD Discriminator Uniqueness 233 One important characteristics of an S-BFD discriminator is that it 234 MUST be unique within an administrative domain. If multiple network 235 nodes allocated a same S-BFD discriminator value, then S-BFD control 236 packets falsely terminating on a wrong network node can result in a 237 reflector BFD session to generate a response back, due to "your 238 discriminator" matching. This is clearly not desirable. If only IP 239 based S-BFD is considered, then it is possible for the reflector BFD 240 session to require demultiplexing of incoming S-BFD control packets 241 with combination of destination IP address and "your discriminator". 242 Then S-BFD discriminator only has to be unique within a local node. 243 However, S-BFD is a generic mechanism defined to run on wide range of 244 environments: IP, MPLS, etc. For other transports like MPLS, because 245 of the need to use non-routable IP destination address, it is not 246 possible for reflector BFD session to demultiplex using IP 247 destination address. With PHP, there may not be any incoming label 248 stack to aid in demultiplexing either. Thus, S-BFD imposes a 249 requirement that S-BFD discriminators MUST be unique within an 250 administrative domain. 252 4.2. Discriminator Pools 254 This subsection describes a discriminator pool implementation 255 technique to minimize S-BFD discriminator collisions. The result 256 will allow an implementation to better satisfy the S-BFD 257 discriminator uniqueness requirement defined in Section 4.1. 259 o SBFDInitiator is to allocate a discriminator from the BFD 260 discriminator pool. If the system also supports classical BFD 261 that runs on [RFC5880], then the BFD discriminator pool SHOULD be 262 shared by SBFDInitiator sessions and classical BFD sessions. 264 o SBFDReflector is to allocate a discriminator from the S-BFD 265 discriminator pool. The S-BFD discriminator pool SHOULD be a 266 separate pool than the BFD discriminator pool. 268 Remainder of this subsection describes the reasons for above 269 suggestions. 271 Locally allocated S-BFD discriminator values for entities, listened 272 by SBFDReflector sessions, may be arbitrary allocated or derived from 273 values provided by applications. These values may be protocol IDs 274 (e.g., System-ID, Router-ID) or network targets (e.g., IP address). 275 To avoid derived S-BFD discriminator values already being assigned to 276 other BFD sessions (i.e., SBFDInitiator sessions and classical BFD 277 sessions), it is RECOMMENDED that discriminator pool for 278 SBFDReflector sessions be separate from other BFD sessions. 280 Even when following the separate discriminator pool approach, 281 collision is still possible between one S-BFD application to another 282 S-BFD application, that may be using different values and algorithms 283 to derive S-BFD discriminator values. If the two applications are 284 using S-BFD for a same purpose (e.g., network reachability), then the 285 colliding S-BFD discriminator value can be shared. If the two 286 applications are using S-BFD for a different purpose, then the 287 collision must be addressed. How such collisions are addressed is 288 outside the scope of this document. 290 5. Reflector BFD Session 292 Each network node creates one or more reflector BFD sessions. This 293 reflector BFD session is a session which transmits S-BFD control 294 packets in response to received S-BFD control packets with "your 295 discriminator" having S-BFD discriminators allocated for local 296 entities. Specifically, this reflector BFD session is to have 297 following characteristics: 299 o MUST NOT transmit any S-BFD packets based on local timer expiry. 301 o MUST transmit an S-BFD control packet in response to a received 302 S-BFD control packet having a valid S-BFD discriminator in the 303 "your discriminator" field, unless prohibited by local policies 304 (e.g., administrative, security, rate-limiter, etc). 306 o MUST be capable of sending only two states: UP and ADMINDOWN. 308 One reflector BFD session may be responsible for handling received 309 S-BFD control packets targeted to all locally allocated S-BFD 310 discriminators, or few reflector BFD sessions may each be responsible 311 for subset of locally allocated S-BFD discriminators. This policy is 312 a local matter, and is outside the scope of this document. 314 Note that incoming S-BFD control packets may be IPv4, IPv6 or MPLS 315 based. How such S-BFD control packets reach an appropriate reflector 316 BFD session is also a local matter, and is outside the scope of this 317 document. 319 6. State Variables 321 S-BFD introduces new state variables, and modifies the usage of 322 existing ones. 324 6.1. New State Variables 326 A new state variable is added to the base specification in support of 327 S-BFD. 329 o bfd.SessionType: This is a variable introduced by 330 [I-D.ietf-bfd-multipoint] and describes the type of this session. 331 Allowable values for S-BFD sessions are: 333 * SBFDInitiator - an S-BFD session on a network node that 334 performs a continuity test to a target entity by sending S-BFD 335 packets. 337 * SBFDReflector - an S-BFD session on a network node that listens 338 for incoming S-BFD control packets to local entities and 339 generates response S-BFD control packets. 341 bfd.SessionType variable MUST be initialized to the appropriate type 342 when an S-BFD session is created. 344 6.2. State Variable Initialization and Maintenance 346 Some state variables defined in section 6.8.1 of the BFD base 347 specification need to be initialized or manipulated differently 348 depending on the session type. 350 o bfd.DemandMode: This variable MUST be initialized to 1 for session 351 type SBFDInitiator, and MUST be initialized to 0 for session type 352 SBFDReflector. 354 7. S-BFD Procedures 356 7.1. Demultiplexing of S-BFD Control Packet 358 S-BFD packet MUST be demultiplexed with lower layer information 359 (e.g., dedicated destination UDP port, associated channel type). 360 Following procedure SHOULD be executed on both initiator and 361 reflector. 363 If S-BFD packet 365 If S-BFD packet is for SBFDReflector 367 Packet MUST be looked up to locate a corresponding 368 SBFDReflector session based on the value from the "your 369 discriminator" field in the table describing S-BFD 370 discriminators. 372 Else 374 Packet MUST be looked up to locate a corresponding 375 SBFDInitiator session or classical BFD session based on the 376 value from the "your discriminator" field in the table 377 describing BFD discriminators. 379 If session is SBFDInitiator 380 Destination of the packet (i.e., destination IP address) 381 SHOULD be validated to be for self. 383 Else 385 Packet MUST be discarded 387 Else 389 Procedure described in [RFC5880] MUST be applied. 391 More details on S-BFD control packet demultiplexing are described in 392 relevant S-BFD data plane documents. 394 7.2. Initiator Procedures 396 S-BFD control packets transmitted by an SBFDInitiator MUST set "your 397 discriminator" field to an S-BFD discriminator corresponding to the 398 remote entity. 400 Every SBFDInitiator MUST have a locally unique "my discriminator" 401 allocated from the BFD discriminator pool. 403 Below ASCII art describes high level concept of continuity test using 404 S-BFD. R2 allocates XX as the S-BFD discriminator for its network 405 reachability purpose, and advertises XX to neighbors. ASCII art 406 shows R1 and R4 performing a continuity test to R2. 408 +--- md=50/yd=XX (ping) ----+ 409 | | 410 |+-- md=XX/yd=50 (pong) --+ | 411 || | | 412 |v | v 413 R1 ==================== R2[*] ========= R3 ========= R4 414 | ^ |^ 415 | | || 416 | +-- md=60/yd=XX (ping) --+| 417 | | 418 +---- md=XX/yd=60 (pong) ---+ 420 [*] Reflector BFD session on R2. 421 === Links connecting network nodes. 422 --- S-BFD control packet traversal. 424 Figure 3: S-BFD Continuity Test 426 7.2.1. SBFDInitiator State Machine 428 An SBFDInitiator may be a persistent session on the initiator with a 429 timer for S-BFD control packet transmissions (stateful 430 SBFDInitiator). An SBFDInitiator may also be a module, a script or a 431 tool on the initiator that transmits one or more S-BFD control 432 packets "when needed" (stateless SBFDInitiator). For stateless 433 SBFDInitiators, a complete BFD state machine may not be applicable. 434 For stateful SBFDInitiators, the states and the state machine 435 described in [RFC5880] will not function due to SBFDReflector session 436 only sending UP and ADMINDOWN states (i.e., SBFDReflector session 437 does not send INIT state). The following diagram provides the 438 RECOMMENDED state machine for stateful SBFDInitiators. The notation 439 on each arc represents the state of the SBFDInitiator (as received in 440 the State field in the S-BFD control packet) or indicates the 441 expiration of the Detection Timer. 443 +--+ 444 ADMIN DOWN, | | 445 TIMER | V 446 +------+ UP +------+ 447 | |-------------------->| |----+ 448 | DOWN | | UP | | UP 449 | |<--------------------| |<---+ 450 +------+ ADMIN DOWN, +------+ 451 TIMER 453 Figure 4: SBFDInitiator FSM 455 Note that the above state machine is different from the base BFD 456 specification[RFC5880]. This is because the INIT state is no longer 457 applicable for the SBFDInitiator. Another important difference is 458 the transition of the state machine from the DOWN state to the UP 459 state when a packet with State UP is received by the SBFDInitiator. 460 The definitions of the states and the events have the same meaning as 461 in the base BFD specification [RFC5880]. 463 7.2.2. Transmission of S-BFD Control Packet by SBFDInitiator 465 Contents of S-BFD control packets sent by an SBFDInitiator MUST be 466 set as follows: 468 Version 470 Set to the current version number (1). 472 Diagnostic (Diag) 473 MAY be set to appropriate value for communicating with peer. 475 State (Sta) 477 Set to the value indicated by local state. 479 Poll (P) 481 Set to 1 if the local system is sending a Poll Sequence. 483 Final (F) 485 Set to 1 if the local system is responding to a Control packet 486 received with the Poll (P) bit set, or 0 if not. 488 Control Plane Independent (C) 490 Set to 1 if the local system's BFD implementation is 491 independent of the control plane (it can continue to function 492 through a disruption of the control plane.) 494 Authentication Present (A) 496 Set to 1 if authentication is in use on this session 497 (bfd.AuthType is nonzero), or 0 if not. 499 Demand (D) 501 MUST be set always. 503 Multipoint (M) 505 MUST be set to 0. 507 Detect Mult 509 MUST be set to a value describing locally used multiplier 510 value. 512 Length 514 Set to the appropriate length, based on the fixed header length 515 (24) plus any Authentication Section. 517 My Discriminator 519 Set to value assigned by local node. 521 Your Discriminator 523 Set to value corresponding to remote entity. 525 Desired Min TX Interval 527 MUST be set to a value describing local desired minimum 528 transmit interval. 530 Required Min RX Interval 532 MUST be set to 0. 534 Required Min Echo RX Interval 536 MUST be set to 0. 538 7.3. Responder Procedures 540 A network node which receives S-BFD control packets transmitted by an 541 initiator is referred as responder. The responder, upon reception of 542 S-BFD control packets, is to perform necessary relevant validations 543 described in [RFC5880], [RFC5881], [RFC5883], [RFC5884] and 544 [RFC5885]. 546 7.3.1. Responder Demultiplexing 548 S-BFD packet MUST be demultiplexed with lower layer information 549 (e.g., dedicated destination UDP port, associated channel type). 550 Following procedure SHOULD be executed by responder: 552 If "your discriminator" not one of the entry allocated for local 553 entities 555 Packet MUST NOT be considered for this mechanism. 557 Else 559 Packet is determined to be handled by a reflector BFD session 560 responsible for that S-BFD discriminator. 562 If local policy allows (e.g., administrative, security, rate- 563 limiter, etc) 565 Chosen reflector BFD session SHOULD transmit a response BFD 566 control packet using procedures described in Section 7.3.2. 568 7.3.2. Transmission of S-BFD Control Packet by SBFDReflector 570 Contents of S-BFD control packets sent by an SBFDReflector MUST be 571 set as follows: 573 Version 575 Set to the current version number (1). 577 Diagnostic (Diag) 579 MAY be set to appropriate value for communicating with peer. 581 State (Sta) 583 MUST be set to UP or ADMINDOWN. Clarification of reflector BFD 584 session state is described in Section 7.8. 586 Poll (P) 588 Set to 1 if the local system is sending a Poll Sequence, or 0 589 if not. 591 Final (F) 593 Set to 1 if the local system is responding to a Control packet 594 received with the Poll (P) bit set, or 0 if not. 596 Control Plane Independent (C) 598 Set to 1 if the local system's BFD implementation is 599 independent of the control plane (it can continue to function 600 through a disruption of the control plane.) 602 Authentication Present (A) 604 Set to 1 if authentication is in use on this session 605 (bfd.AuthType is nonzero), or 0 if not. 607 Demand (D) 609 MUST be cleared. 611 Multipoint (M) 613 MUST be set to 0. 615 Detect Mult 616 MUST be copied from received "Detection Multiplier". 618 Length 620 Set to the appropriate length, based on the fixed header length 621 (24) plus any Authentication Section. 623 My Discriminator 625 MUST be copied from received "your discriminator". 627 Your Discriminator 629 MUST be copied from received "my discriminator". 631 Desired Min TX Interval 633 MUST be copied from received "Desired Min TX Interval". 635 Required Min RX Interval 637 MUST be set to a value describing how many incoming control 638 packets this reflector BFD session can handle. Further details 639 are described in Section 7.8. 641 Required Min Echo RX Interval 643 If device supports looping back S-BFD echo packets 645 MUST set non-zero value desired by local device. 647 Else 649 MUST be set to 0. 651 7.4. Diagnostic Values 653 Diagnostic value in both directions MAY be set to a certain value, to 654 attempt to communicate further information to both ends. However, 655 details of such are outside the scope of this specification. 657 7.5. The Poll Sequence 659 Poll sequence MAY be used in both directions. The Poll sequence MUST 660 operate in accordance with [RFC5880]. An SBFDReflector MAY use the 661 Poll sequence to slow down that rate at which S-BFD control packets 662 are generated from an SBFDInitiator. This is done by the 663 SBFDReflector using procedures described in Section 7.8 and setting 664 the Poll (P) bit in the reflected S-BFD control packet. The 665 SBFDInitiator is to then send the next S-BFD control packet with the 666 Final (F) bit set. If an SBFDReflector receives an S-BFD control 667 packet with Poll (P) bit set, then the SBFDReflector MUST respond 668 with an S-BFD control packet with Poll (P) bit cleared and Final (F) 669 bit set. 671 7.6. Control Plane Independent (C) 673 Control plane independent (C) bit for an SBFDInitiator sending S-BFD 674 control packets to a reflector BFD session MUST work according to 675 [RFC5880]. Reflector BFD session also MUST work according to 676 [RFC5880]. Specifically, if reflector BFD session implementation 677 does not share fate with control plane, then response S-BFD control 678 packets transmitted MUST have control plane independent (C) bit set. 679 If reflector BFD session implementation shares fate with control 680 plane, then response S-BFD control packets transmitted MUST NOT have 681 control plane independent (C) bit set. 683 7.7. Additional SBFDInitiator Behaviors 685 o If the SBFDInitiator receives a valid S-BFD control packet in 686 response to transmitted S-BFD control packet to a remote entity, 687 then the SBFDInitiator SHOULD conclude that S-BFD control packet 688 reached the intended remote entity. 690 o When a sufficient number of S-BFD packets have not arrived as they 691 should, the SBFDInitiator SHOULD declare loss of reachability to 692 the remote entity. The criteria for declaring loss of 693 reachability and the action that would be triggered as a result 694 are outside the scope of this document. 696 o Relating to above bullet item, it is critical for an 697 implementation to understand the latency to/from the reflector BFD 698 session on the responder. In other words, for very first S-BFD 699 packet transmitted by the SBFDInitiator, an implementation MUST 700 NOT expect response S-BFD packet to be received for time 701 equivalent to sum of latencies: initiator to responder and 702 responder back to initiator. 704 o If the SBFDInitiator receives an S-BFD control packet with Demand 705 (D) bit set, the packet MUST be discarded. 707 7.8. Additional SBFDReflector Behaviors 709 o S-BFD control packets transmitted by the SBFDReflector MUST have 710 "Required Min RX Interval" set to a value which expresses how many 711 incoming S-BFD control packets this SBFDReflector can handle. The 712 SBFDReflector can control how fast SBFInitiators will be sending 713 S-BFD control packets to self by ensuring "Required Min RX 714 Interval" indicates a value based on the current load. 716 o If the SBFDReflector wishes to communicate to some or all 717 SBFDInitiators that monitored local entity is "temporarily out of 718 service", then S-BFD control packets with "state" set to ADMINDOWN 719 are sent to those SBFDInitiators. The SBFDInitiators, upon 720 reception of such packets, MUST NOT conclude loss of reachability 721 to corresponding remote entity, and MUST back off packet 722 transmission interval for the remote entity to an interval no 723 faster than 1 second. If the SBFDReflector is generating a 724 response S-BFD control packet for a local entity that is in 725 service, then "state" in response BFD control packets MUST be set 726 to UP. 728 o If an SBFDReflector receives an S-BFD control packet with Demand 729 (D) bit cleared, the packet MUST be discarded. 731 8. Scaling Aspect 733 This mechanism brings forth one noticeable difference in terms of 734 scaling aspect: number of SBFDReflector. This specification 735 eliminates the need for egress nodes to have fully active BFD 736 sessions when only one side desires to perform continuity tests. 737 With introduction of reflector BFD concept, egress no longer is 738 required to create any active BFD session per path/LSP/function 739 basis. Due to this, total number of BFD sessions in a network is 740 reduced. 742 9. Co-existence with Classical BFD Sessions 744 Initial packet demultiplexing requirement is described in 745 Section 7.1. Because of this, S-BFD mechanism can co-exist with 746 classical BFD sessions. 748 10. S-BFD Echo Function 750 The concept of the S-BFD Echo function is similar to the BFD Echo 751 function described in [RFC5880]. S-BFD echo packets have the 752 destination of self, thus S-BFD echo packets are self-generated and 753 self-terminated after traversing a link/path. S-BFD echo packets are 754 expected to u-turn on the target node in the data plane and MUST NOT 755 be processed by any reflector BFD sessions on the target node. 757 When using the S-BFD Echo function, it is RECOMMENDED that: 759 o Both S-BFD control packets and S-BFD echo packets be sent. 761 o Both S-BFD control packets and S-BFD echo packets have the same 762 semantics in the forward direction to reach the target node. 764 In other words, it is not preferable to send just S-BFD echo packets 765 without also sending S-BFD control packets. There are two reasons 766 behind this suggestion: 768 o S-BFD control packets can verify the reachability to intended 769 target node, which allows one to have confidence that S-BFD echo 770 packets are u-turning on the expected target node. 772 o S-BFD control packets can detect when the target node is going out 773 of service (i.e., via receiving back ADMINDOWN state). 775 The usage of the "Required Min Echo RX Interval" field is described 776 in Section 7.2.2 and Section 7.3.2. Because of the stateless nature 777 of SBFDReflector sessions, a value specified the "Required Min Echo 778 RX Interval" field in both directions is not very meaningful. Thus 779 it is RECOMMENDED that the "Required Min Echo RX Interval" field 780 simply be set to zero in both directions. 782 Following aspects of S-BFD Echo functions are left as implementation 783 details, and are outside the scope of this document: 785 o Format of the S-BFD echo packet (e.g., data beyond UDP header). 787 o Procedures on when and how to use the S-BFD Echo function. 789 11. Security Considerations 791 Same security considerations as [RFC5880], [RFC5881], [RFC5883], 792 [RFC5884] and [RFC5885] apply to this document. Additionally, 793 implementing the following measures will strengthen security aspects 794 of the mechanism described by this document: 796 o SBFDInitiator MAY pick crypto sequence number based on 797 authentication mode configured. 799 o SBFDReflector MUST NOT look at the crypto sequence number before 800 accepting the packet. 802 o SBFDReflector MAY look at the Key ID 803 [I-D.ietf-bfd-generic-crypto-auth] in the incoming packet and 804 verify the authentication data. 806 o SBFDReflector MUST accept the packet if authentication is 807 successful. 809 o SBFDReflector MUST compute the Authentication data and MUST use 810 the same sequence number that it received in the S-BFD control 811 packet that it is responding to. 813 o SBFDInitiator MUST accept the S-BFD control packet if it either 814 comes with the same sequence number as it had sent or it's within 815 the window that it finds acceptable (described in detail in 816 [I-D.ietf-bfd-generic-crypto-auth]) 818 Using the above method, 820 o SBFDReflector continue to remain stateless despite using security. 822 o SBFDReflector are not susceptible to replay attacks as they always 823 respond to S-BFD control packets irrespective of the sequence 824 number carried. 826 o An attacker cannot impersonate the responder since the 827 SBFDInitiator will only accept S-BFD control packets that come 828 with the sequence number that it had originally used when sending 829 the S-BFD control packet. 831 12. IANA Considerations 833 No action is required by IANA for this document. 835 13. Acknowledgements 837 Authors would like to thank Jeffrey Haas, Greg Mirsky and Marc 838 Binderberger for performing thorough reviews and providing number of 839 suggestions. Authors would like to thank Girija Raghavendra Rao, Les 840 Ginsberg, Srihari Raghavan, Vanitha Neelamegam and Vengada Prasad 841 Govindan from Cisco Systems for providing valuable comments. Authors 842 would also like to thank John E. Drake and Pablo Frank for providing 843 comments and suggestions. 845 14. Contributing Authors 847 Tarek Saad 848 Cisco Systems 849 Email: tsaad@cisco.com 851 Siva Sivabalan 852 Cisco Systems 853 Email: msiva@cisco.com 855 Nagendra Kumar 856 Cisco Systems 857 Email: naikumar@cisco.com 859 Mallik Mudigonda 860 Cisco Systems 861 Email: mmudigon@cisco.com 863 Sam Aldrin 864 Google 865 Email: aldrin.ietf@gmail.com 867 15. References 869 15.1. Normative References 871 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 872 Requirement Levels", BCP 14, RFC 2119, March 1997. 874 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 875 (BFD)", RFC 5880, June 2010. 877 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 878 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 879 2010. 881 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 882 (BFD) for Multihop Paths", RFC 5883, June 2010. 884 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 885 "Bidirectional Forwarding Detection (BFD) for MPLS Label 886 Switched Paths (LSPs)", RFC 5884, June 2010. 888 15.2. Informative References 890 [I-D.ietf-bfd-generic-crypto-auth] 891 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 892 "BFD Generic Cryptographic Authentication", draft-ietf- 893 bfd-generic-crypto-auth-06 (work in progress), April 2014. 895 [I-D.ietf-bfd-multipoint] 896 Katz, D., Ward, D., and J. Networks, "BFD for Multipoint 897 Networks", draft-ietf-bfd-multipoint-06 (work in 898 progress), May 2015. 900 [I-D.ietf-bfd-seamless-use-case] 901 Bhatia, M., Matsushima, S., Mirsky, G., and N. Kumar, 902 "Seamless Bidirectional Forwarding Detection (BFD) Use 903 Case", draft-ietf-bfd-seamless-use-case-02 (work in 904 progress), April 2015. 906 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 907 Detection (BFD) for the Pseudowire Virtual Circuit 908 Connectivity Verification (VCCV)", RFC 5885, June 2010. 910 Appendix A. Loop Problem 912 Consider a scenario where we have two nodes and both are S-BFD 913 capable. 915 Node A (IP 192.0.2.1) ----------------- Node B (IP 192.0.2.2) 916 | 917 | 918 Man in the Middle (MiM) 920 Assume node A reserved a discriminator 0x01010101 for target 921 identifier 192.0.2.1 and has a reflector session in listening mode. 922 Similarly node B reserved a discriminator 0x02020202 for its target 923 identifier 192.0.2.2 and also has a reflector session in listening 924 mode. 926 Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, YourDisc 927 = 0x02020202, source IP as 192.0.2.1 and dest IP as 192.0.2.2. When 928 this packet reaches Node B, the reflector session on Node B will swap 929 the discriminators and IP addresses of the received packet and 930 reflect it back, since YourDisc of the received packet matched with 931 reserved discriminator of Node B. The reflected packet that reached 932 Node A will have MyDdisc=0x02020202 and YourDisc=0x01010101. Since 933 YourDisc of the received packet matched the reserved discriminator of 934 Node A, Node A will swap the discriminators and reflects the packet 935 back to Node B. Since reflectors MUST set the TTL of the reflected 936 packets to 255, the above scenario will result in an infinite loop 937 with just one malicious packet injected from MiM. 939 FYI: Packet fields do not carry any direction information, i.e., if 940 this is Ping packet or reply packet. 942 Solutions 944 The current proposals to avoid the loop problem are: 946 o Overload "D" bit (Demand mode bit): Initiator always sets the 'D' 947 bit and reflector clears it. This way we can identify if a 948 received packet was a reflected packet and avoid reflecting it 949 back. However this changes the interpretation of 'D' bit. 951 o Use of State field in the BFD control packets: Initiator will 952 always send packets with State set to DOWN and reflector will send 953 back packets with state field set to UP. Reflectors will never 954 reflect any received packets with state as UP. However the only 955 issue is the use of state field differently i.e., state in the 956 S-BFD control packet from initiator does not reflect the local 957 state which is anyway not significant at reflector. 959 o Use of local discriminator as My Disc at reflector: Reflector will 960 always fill in My Discriminator with a locally allocated 961 discriminator value (not reserved discriminators) and will not 962 copy it from the received packet. 964 Authors' Addresses 966 Nobo Akiya 967 Big Switch Networks 969 Email: nobo.akiya.dev@gmail.com 971 Carlos Pignataro 972 Cisco Systems 974 Email: cpignata@cisco.com 976 Dave Ward 977 Cisco Systems 979 Email: wardd@cisco.com 981 Manav Bhatia 982 Ionos Networks 984 Email: manav@ionosnetworks.com 986 Santosh Pallagatti 987 Juniper Networks 989 Email: santoshpk@juniper.net