idnits 2.17.1 draft-akiya-bfd-seamless-base-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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC5880, but the abstract doesn't seem to mention this, which it should. 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 (April 17, 2014) is 3662 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) ** Downref: Normative reference to an Informational draft: draft-aldrin-bfd-seamless-use-case (ref. 'I-D.aldrin-bfd-seamless-use-case') == Outdated reference: A later version (-06) exists of draft-ietf-bfd-generic-crypto-auth-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force N. Akiya 2 Internet-Draft C. Pignataro 3 Updates: 5880 (if approved) D. Ward 4 Intended status: Standards Track Cisco Systems 5 Expires: October 19, 2014 M. Bhatia 6 Alcatel-Lucent 7 P. K. Santosh 8 Juniper Networks 9 April 17, 2014 11 Seamless Bidirectional Forwarding Detection (S-BFD) 12 draft-akiya-bfd-seamless-base-03 14 Abstract 16 This document defines a simplified mechanism to use Bidirectional 17 Forwarding Detection (BFD) with large portions of negotiation aspects 18 eliminated, thus providing benefits such as quick provisioning as 19 well as improved control and flexibility to network nodes initiating 20 the path monitoring. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 19, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Seamless BFD Overview . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. BFD Target Identifier Types . . . . . . . . . . . . . . . . . 5 66 5. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. S-BFD Discriminators . . . . . . . . . . . . . . . . . . . . 5 68 7. Reflector BFD Session . . . . . . . . . . . . . . . . . . . . 7 69 8. State Variables . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. New State Variables . . . . . . . . . . . . . . . . . . . 7 71 8.2. State Variable Initialization and Maintenance . . . . . . 8 72 9. Full Reachability Validations . . . . . . . . . . . . . . . . 8 73 9.1. Initiator Behavior . . . . . . . . . . . . . . . . . . . 8 74 9.1.1. Initiator State machine . . . . . . . . . . . . . . . 9 75 9.2. Responder Behavior . . . . . . . . . . . . . . . . . . . 10 76 9.2.1. Responder Demultiplexing . . . . . . . . . . . . . . 10 77 9.2.2. Reflector BFD Session Procedures . . . . . . . . . . 10 78 9.3. Further Packet Details . . . . . . . . . . . . . . . . . 12 79 9.4. Diagnostic Values . . . . . . . . . . . . . . . . . . . . 12 80 9.5. The Poll Sequence . . . . . . . . . . . . . . . . . . . . 13 81 9.6. Control Plane Independent (C) . . . . . . . . . . . . . . 13 82 9.7. Additional Initiator Behavior . . . . . . . . . . . . . . 13 83 9.8. Additional Responder Behavior . . . . . . . . . . . . . . 13 84 10. Partial Reachability Validations . . . . . . . . . . . . . . 14 85 11. Scaling Aspect . . . . . . . . . . . . . . . . . . . . . . . 14 86 12. Co-existence with Traditional BFD . . . . . . . . . . . . . . 15 87 13. BFD Echo . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 14. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 17. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 92 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 18.1. Normative References . . . . . . . . . . . . . . . . . . 17 94 18.2. Informative References . . . . . . . . . . . . . . . . . 17 95 Appendix A. Loop Problem . . . . . . . . . . . . . . . . . . . . 18 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 Bidirectional Forwarding Detection (BFD), [RFC5880] and related 101 documents, has efficiently generalized the failure detection 102 mechanism for multiple protocols and applications. There are some 103 improvements which can be made to better fit existing technologies. 104 There is a possibility of evolving BFD to better fit new 105 technologies. This document focuses on several aspects of BFD in 106 order to further improve efficiency, to expand failure detection 107 coverage and to allow BFD usage for wider scenarios. This document 108 extends BFD to provide solutions to use cases listed in 109 [I-D.aldrin-bfd-seamless-use-case]. Because defined mechanism 110 eliminates much of negotiation aspects of the BFD protocol, "Seamless 111 BFD" (S-BFD) has been chosen as the name for this mechanism. 113 2. Seamless BFD Overview 115 Each protocol instance (e.g. OSPF/IS-IS) allocates one or more BFD 116 discriminators on its network node, ensuring that BFD discriminators 117 allocated are unique within the network domain. Allocated BFD 118 discriminators may be advertised by the protocol. Required result is 119 that a protocol possess the knowledge of mapping between network 120 targets to BFD discriminators. Each network nodes will also create a 121 BFD session instance that listens for incoming BFD control packets 122 with "your discriminator" having protocol allocated values. The 123 listener BFD session instance, upon receiving a BFD control packet 124 targeted to one of local S-BFD discriminator values, will transmit a 125 response BFD control packet back to the sender. 127 Once above setup is complete, any network node, understanding the 128 mapping between network targets to BFD discriminators, can quickly 129 perform reachability check to these network targets by simply sending 130 BFD control packets with known BFD discriminator value as "your 131 discriminator". 133 For example: 135 <------- IS-IS Network -------> 137 +---------+ 138 | | 139 A---------B---------C---------D 140 ^ ^ 141 | | 142 SystemID SystemID 143 xxx yyy 144 BFD Discrim BFD Discrim 145 123 456 147 Figure 1: S-BFD for IS-IS Network 149 IS-IS with SystemID xxx allocates BFD discriminator 123, and 150 advertises the BFD discriminator 123 in IS-IS TLV. IS-IS with 151 SystemID yyy allocates BFD discriminator 456, and advertises the BFD 152 discriminator 456 IS-IS TLV. Both network nodes (node A and node D) 153 creates listener BFD session instance. When network node A wants to 154 check a reachability to network node D, node A can send a BFD control 155 packet, destined to node D, with "your discriminator" set as 456. If 156 listener BFD on node D receives this BFD control packet, then 157 response BFD control packet is sent back to node A, which allows node 158 A to complete the reachability test. 160 Note that a protocol may create an explicit mapping between a 161 protocol ID (e.g. System-ID, Router-ID) to a BFD discriminator. A 162 protocol may also create an explicit mapping between a network target 163 (e.g. IP address) to a BFD discriminator. A protocol may even 164 function with implicit mapping between a network target (e.g. IPv4 165 address) to a BFD discriminator, i.e. IPv4 address is used as BFD 166 discriminator value. Decisions and rules on how protocols allocate 167 and distribute BFD discriminators are outside the scope of this 168 document. 170 3. Terminology 172 The reader is expected to be familiar with the BFD, IP, MPLS and SR 173 terminology and protocol constructs. This section describes several 174 new terminology introduced by Seamless BFD. 176 o BFD Target Identifier: Network entity that is provisioned as a 177 target of Seamless BFD. 179 o BFD Target Identifier Type: Type of network entity that is 180 provisioned as a target of Seamless BFD. 182 o BFD Target Identifier Table: A table containing BFD target 183 identifier type, BFD target identifier and corresponding BFD 184 discriminator. 186 o Reflector BFD Session: A BFD session listening for incoming BFD 187 control packets destined for local BFD target identifier(s). 189 4. BFD Target Identifier Types 191 This document defines a generic mechanism where network nodes can 192 send BFD control packets to specific network targets to perform 193 various tasks. One task is to perform a reachability check (i.e 194 requesting immediate response back). Details of this task is further 195 defined in sections to follow. Further tasks (i.e. using BFD control 196 packet to request specific services from specific network nodes) may 197 be defined. Therefore, this document defines a code point for BFD 198 Target Identifier. Each locally allocated S-BFD discriminator MUST 199 be associated to BFD Target Identifier type, to allow demultiplexing 200 to a specific task or service. 202 BFD Target Identifier types: 204 Value BFD Target Identifier Type 205 ------ -------------------------- 206 0 Reserved 207 1 Network Target Discriminator 209 Procedures defined in this document are to be associated with BFD 210 Target Identifier Type 1 (Network Target Discriminator). 212 Note that IP based BFD from [RFC5885] is supported by this 213 specification, but non-IP based BFD is outside the scope of this 214 document. 216 Further identifier types are to be defined as needed basis. 218 5. UDP Port 220 S-BFD functions on a well-known UDP port: TBD1. 222 6. S-BFD Discriminators 224 Protocols (i.e. client of S-BFD) may request an arbitrary BFD 225 discriminator value, or protocols may request a specific BFD 226 discriminator value. Therefore, it is RECOMMENDED for 227 implementations to create a separate discriminator pool for S-BFD 228 sessions to minimize the collision between existing BFD sessions and 229 S-BFD sessions. In such case, incoming BFD control packets MUST be 230 demultiplexed first with UDP port to identify the discriminator table 231 to look up the session. Regardless of the approach, collision can 232 happen with following scenarios. 234 o Existing BFD session already using a discriminator value that 235 collides with specific discriminator value requested for S-BFD 236 session. 238 * Implementation SHOULD allow migrating existing BFD sessions to 239 free up the discriminator to accommodate specific discriminator 240 value requested for S-BFD session. 242 o S-BFD session already using a discriminator value, arbitrarily 243 allocated, that collides with specific discriminator value 244 requested for S-BFD session. The two S-BFD sessions are of 245 different BFD Target Identifier type. 247 * Protocol requesting arbitrary discriminator value MUST support 248 migrating to another discriminator value, and implementations 249 MUST allow migrating existing S-BFD sessions to free up the 250 discriminator to accommodate specific discriminator value 251 requested for S-BFD session. 253 o S-BFD session already using a discriminator value, arbitrary 254 allocated, that collides with specific discriminator value 255 requested for S-BFD session. The two S-BFD sessions are of same 256 BFD Target Identifier type. 258 * No action is required, as the two can share the discriminator. 260 One important characteristics of S-BFD discriminator is that it MUST 261 be network wide unique. If multiple network nodes allocated same 262 S-BFD discriminator value, then S-BFD control packets falsely 263 terminating on a wrong network node can result in reflector BFD 264 session (described in Section 7) to generate a response back, due to 265 "your discriminator" matching. This is clearly not desirable. If 266 only IP based S-BFD is concerned, then it is possible for S-BFD 267 reflector session to require demultiplexing of incoming S-BFD control 268 packet with combination of destination IP address and "your 269 discriminator". Then S-BFD discriminator only has to be unique 270 within a local node. However, S-BFD is a generic mechanism defined 271 to run on wide range of environments: IP, MPLS, Segment Routing 272 ([I-D.previdi-filsfils-isis-segment-routing]), etc. For other 273 transports like MPLS, because of the need to use non-routable IP 274 destination address, it is not possible for S-BFD reflector session 275 to demultiplex using IP destination address. With PHP, there may not 276 be any incoming label stack to aid in demultiplexing either. Thus, 277 S-BFD imposes a requirement that S-BFD discriminators MUST be network 278 wide unique. 280 7. Reflector BFD Session 282 Each network node MUST create one or more reflector BFD sessions. 283 This reflector BFD session is a session which transmits BFD control 284 packets in response to received valid locally destined BFD control 285 packets. Specifically, this reflector BFD session is to have 286 following characteristics: 288 o MUST NOT transmit any BFD control packets based on local timer 289 expiry. 291 o MUST transmit BFD control packet in response to a received valid 292 locally destined BFD control packet. 294 o MUST be capable of sending only two states: UP and ADMINDOWN. 296 One reflector BFD session MAY be responsible for handling received 297 BFD control packets targeted to all local BFD target identifiers, or 298 few reflector BFD sessions MAY each be responsible for subset of 299 local BFD target identifiers. This policy is a local matter, and is 300 outside the scope of this document. 302 Note that incoming BFD control packets destined to BFD target 303 identifier types may be IPv4, IPv6 or MPLS based. For those BFD 304 target identifier types, implementations MAY either allow the same 305 reflector BFD session to handle all incoming BFD control packets in 306 address family agnostic fashion, or setup multiple reflector BFD 307 sessions to handle incoming BFD control packets with different 308 address families. This policy is again a local matter, and is 309 outside the scope of this document. 311 8. State Variables 313 S-BFD introduces some new state variables, and modifies the usage of 314 existing ones. 316 8.1. New State Variables 318 A new state variable is added to the base specification in support of 319 S-BFD. 321 o bfd.SessionType: The type of this session. Allowable values are: 323 * SBFDInitiator: Any session on a network node that attempts to 324 perform a path monitoring to any BFD target identifier on other 325 network nodes. 327 * SBFDReflector: Any session on a network node, which receives 328 BFD control packets transmitted by an initiator and responds 329 back to initiator is referred as responder. 331 This variable MUST be initialized to the appropriate type when the 332 session is created, according to the rules in section TBD. 334 8.2. State Variable Initialization and Maintenance 336 Some state variables defined in section 6.8.1 of the BFD base 337 specification need to be initialized or manipulated differently 338 depending on the session type. 340 o bfd.DemandMode: This variable MUST be initialized to 1 for session 341 type SBFDInitiator, and MUST be initialized to 0 for session type 342 SBFDReflector. 344 9. Full Reachability Validations 346 9.1. Initiator Behavior 348 Any network node can attempt to perform a full reachability 349 validation to any BFD target identifier on other network nodes, as 350 long as destination BFD target identifier is provisioned to use this 351 mechanism. BFD control packets transmitted by the initiator is to 352 have "your discriminator" corresponding to destination BFD target 353 identifier. 355 A node that initiates a BFD control packet MAY create an active BFD 356 session to periodically send BFD control packets to a target, or a 357 BFD control packet MAY be crafted and sent out on "as needed basis" 358 (ex: BFD ping) without any session presence. In both cases, a BFD 359 instance MUST have a unique "my discriminator" value assigned. If a 360 node is to create multiple BFD instances to the same BFD target 361 identifier, then each instance MUST have separate "my discriminator" 362 values assigned. A BFD instance MUST NOT use a discriminator 363 corresponding to one of local BFD target identifiers as "my 364 discriminator". This is to prevent incoming response BFD control 365 packets ("pong" packets) having "your discriminator" as a 366 discriminator corresponding to the local BFD target identifier. 368 Below ASCII art describes high level concept of full reachability 369 validations using this mechanism. R2 reserves value XX as BFD 370 discriminator for its BFD target identifier. ASCII art shows that R1 371 and R4 performing full reachability validation to XX on R2. 373 -- md=50/yd=XX (BFD ping) --> 374 <-- md=XX/yd=50 (BFD pong) -- 376 [*] 377 R1 ---------------------- R2 ----------- R3 ----------- R4 379 | ^ 380 | | 381 | + - md=60/yd=XX (BFD ping) -- 382 + - - -md=XX/yd=60 (BFD pong) --> 384 [*] Reflector BFD session on R2. 386 Figure 2: S-BFD path monitoring 388 If BFD control packet is to be sent via IP path, then: 390 o Destination IP address MUST be an IP address corresponding to 391 target identifier. 392 o Source IP address MUST be a local IP address. 393 o IP TTL MUST be 255 for full reachability validations. Partial 394 reachability validations MAY use smaller TTL value (see 395 Section 10). 396 o Well-known UDP destination port(s) for IP based S-BFD. 398 If BFD control packet response is determined to explicitly be label 399 switched, then: 401 o BFD control packet MUST get imposed with a label stack that is 402 expected to reach the target node. 403 o MPLS TTL MUST be 255 for full reachability validations. Partial 404 reachability validations MAY use smaller TTL value (see 405 Section 10). 406 o Destination IP address MUST be 127/8 for IPv4 and 407 0:0:0:0:0:FFFF:7F00/104 for IPv6. 408 o Source IP address MUST be a local IP address. 409 o IP TTL=1. 410 o Well-known UDP destination port(s) for MPLS based S-BFD 412 9.1.1. Initiator State machine 414 The following diagram provides an overview of the initiator state 415 machine. The notation on each arc represents the state of the remote 416 system (as received in the State field in the BFD Control packet) or 417 indicates the expiration of the Detection Timer. 419 +--+ 420 ADMIN DOWN, | | 421 TIMER | V 422 +------+ UP +------+ 423 | |-------------------->| |----+ 424 | DOWN | | UP | | UP 425 | |<--------------------| |<---+ 426 +------+ ADMIN DOWN, +------+ 427 TIMER 429 Figure 3: S-BFD Initiator FSM 431 Note that the above state machine is different from the base BFD 432 specification[RFC5880]. This is because the Init state is no longer 433 applicable for the initiator of the S-BFD session. Another important 434 difference is the transition of the state machine from the Down state 435 to the Up state when a packet with State Up is received by the 436 initiator. The definitions of the states and the events have the 437 same meaning as in the base BFD specification [RFC5880]. 439 9.2. Responder Behavior 441 A network node which receives BFD control packets transmitted by an 442 initiator is referred as responder. Responder, upon reception of BFD 443 control packets, is to perform necessary relevant validations 444 described in [RFC5880]/[RFC5881]/[RFC5883]/[RFC5884]/[RFC5885]. 446 9.2.1. Responder Demultiplexing 448 When responder receives a BFD control packet, if "your discriminator" 449 value is not one of local entries in the BFD target identifier table, 450 then this packet MUST NOT be considered for this mechanism. If "your 451 discriminator" value is one of local entries in the BFD target 452 identifier table, then the packet is determined to be handled by a 453 reflector BFD session responsible for specified BFD targeted 454 identifier. If the packet was determined to be processed further for 455 this mechanism, then chosen reflector BFD session is to transmit a 456 response BFD control packet using procedures described in 457 Section 9.2.2, unless prohibited by local administrative or local 458 policy reasons. 460 9.2.2. Reflector BFD Session Procedures 462 BFD target identifier type MUST be used to determine further 463 information on how to reach back to the initiator. 465 In addition, destination IP address of received BFD control packet 466 MUST be examined to determine how to construct response BFD control 467 packet to send back to the initiator. 469 If destination IP address of received BFD control packet is not 127/8 470 for IPv4 or 0:0:0:0:0:FFFF:7F00/104 for IPv6, then: 472 o Destination IP address MUST be copied from received source IP 473 address. 474 o Source IP address MUST be copied from received destination IP 475 address if received destination IP address is a local address. 476 Otherwise local IP address MUST be used. 477 o IP TTL MUST be 255. 479 Response BFD control packet SHOULD be IP routed back, but MAY 480 explicitly be label switched. 482 If BFD control packet response is determined to be IP routed, then: 484 o Destination IP address MUST be copied from received source IP 485 address. 486 o Source IP address MUST be a local address. 487 o IP TTL MUST be 255. 489 If BFD control packet response is determined to explicitly be label 490 switched, then: 492 o BFD control packet MUST get label switched back to the initiator. 493 Determining the label stack to be imposed on a response BFD 494 control packet is outside the scope of this document. 495 o MPLS TTL MUST be 255. 496 o Destination IP address MUST be 127/8 for IPv4 and 497 0:0:0:0:0:FFFF:7F00/104 for IPv6. 498 o Source IP address MUST be a local IP address. 499 o IP TTL MUST be 1. 501 Regardless of the response type, BFD control packet being sent by the 502 responder MUST perform following procedures: 504 o Copy "my discriminator" from received "your discriminator", and 505 "your discriminator" from received "my discriminator". 506 o UDP destination port MUST be same as received UDP destination 507 port. 509 9.3. Further Packet Details 511 Further details of BFD control packets sent by initiator (ex: active 512 BFD session): 514 o Well-known UDP destination port assigned for S-BFD. 515 o UDP source port as per described in [RFC5881]/[RFC5883]/[RFC5884]/ 516 [RFC5885]. 517 o "my discriminator" assigned by local node. 518 o "your discriminator" corresponding to an identifier of target 519 node. 520 o "State" MUST be set to a value reflecting local state. 521 o "Desired Min TX Interval" MUST be set to a value reflecting local 522 desired minimum transmit interval. 523 o "Required Min RX Interval" MUST be zero. 524 o "Required Min Echo RX Interval" SHOULD be zero. 525 o "Detection Multiplier" MUST be set to a value reflecting locally 526 used multiplier value. 527 o "Demand bit (D)" MUST be set by the initiator. 529 Further details of BFD control packets sent by responder (reflector 530 BFD session): 532 o Well-known UDP destination port assigned for S-BFD. 533 o UDP source port as described in [RFC5881]/[RFC5883]/[RFC5884]/ 534 [RFC5885]. 535 o "my discriminator" MUST be copied from received "your 536 discriminator". 537 o "your discriminator" MUST be copied from received "my 538 discriminator". 539 o "State" MUST be UP or ADMINDOWN. Clarification of reflector BFD 540 session state is described in Section 9.8. 541 o "Desired Min TX Interval" MUST be copied from received "Desired 542 Min TX Interval". 543 o "Required Min RX Interval" MUST be set to a value reflecting how 544 many incoming control packets this reflector BFD session can 545 handle. 546 o "Required Min Echo RX Interval" SHOULD be set to zero. 547 o "Detection Multiplier" MUST be copied from received "Detection 548 Multiplier". 549 o "Demand bit (D)" MUST be cleared by the reflector. 551 9.4. Diagnostic Values 553 Diagnostic value in both directions MAY be set to a certain value, to 554 attempt to communicate further information to both ends. However, 555 details of such are outside the scope of this specification. 557 9.5. The Poll Sequence 559 The Poll sequence MUST operate in accordance with [RFC5880]. 561 9.6. Control Plane Independent (C) 563 Control plane independent (C) bit for BFD instances speaking to a 564 reflector BFD session MUST work according to [RFC5880]. Reflector 565 BFD session also MUST work according to [RFC5880]. Specifically, if 566 reflector BFD session implementation does not share fate with control 567 plane, then response BFD control packets transmitted MUST have 568 control plane independent (C) bit set. If reflector BFD session 569 implementation shares fate with control plane, then response BFD 570 control packets transmitted MUST NOT have control plane independent 571 (C) bit set. 573 9.7. Additional Initiator Behavior 575 o If initiator receives valid BFD control packet in response to 576 transmitted BFD control packet, then initiator SHOULD conclude 577 that packet reached intended target. 579 o When a sufficient number of BFD control packets have not arrived 580 as they should, the initiator could declare loss of reachability. 581 The criteria for declaring loss of reachability and the action 582 that would be triggered as a result are outside the scope of this 583 specification. 585 o Relating to above bullet item, it is critical for an 586 implementation to understand the latency to/from reflector BFD 587 session on target node. In other words, for very first BFD 588 control packet transmitted, an implementation MUST NOT expect 589 response BFD control packet to be received for time equivalent to 590 sum of latencies: initiator node to target node and target node 591 back to initiator node. 593 o If initiator receives a packet with D bit set, the packet MUST be 594 discarded. 596 9.8. Additional Responder Behavior 598 o BFD control packets transmitted by a reflector BFD session MUST 599 have "Required Min RX Interval" set to a value which reflects how 600 many incoming control packets this reflector BFD session can 601 handle. Responder can control how fast initiators will be sending 602 BFD control packets to self by ensuring "Required Min RX Interval" 603 reflects a value based on current load. 605 o If a reflector BFD session wishes to communicate to some or all 606 initiators that monitored BFD target identifier is "temporarily 607 out of service", then BFD control packets with "state" set to 608 ADMINDOWN are sent to those initiators. Initiators, upon 609 reception of such packets, MUST NOT conclude loss of reachability 610 to corresponding BFD target identifier, and MUST back off packet 611 transmission interval to corresponding BFD target identifier an 612 interval no faster than 1 second. If a reflector BFD session is 613 generating a response BFD control packet for BFD target identifier 614 that is in service, then "state" in response BFD control packets 615 MUST be set to UP. 617 o If a reflector receives a packet with D bit cleared, the packet 618 MUST be discarded. 620 10. Partial Reachability Validations 622 Same mechanism as described in "Full Reachability Validations" 623 section will be applied with exception of following differences on 624 initiator. 626 o When initiator wishes to perform a partial reachability validation 627 towards identifier X upto identifier Y, number of hops to 628 identifier Y is calculated. 630 o TTL value based on this calculation is used as the IP TTL or MPLS 631 TTL on top most label, and "your discriminator" of transmitted BFD 632 control packet will carry BFD discriminator corresponding to 633 target transit identifier Y. 635 o Imposed label stack or IP destination address will continue to be 636 of identifier X. 638 11. Scaling Aspect 640 This mechanism brings forth one noticeable difference in terms of 641 scaling aspect: number of BFD sessions. This specification 642 eliminates the need for egress nodes to have fully active BFD 643 sessions when only one side desires to perform reachability 644 validations. With introduction of reflector BFD concept, egress no 645 longer is required to create any active BFD session per path/LSP 646 basis. Due to this, total number of BFD sessions in a network is 647 reduced. 649 If traditional BFD technology was used on a network comprised of N 650 nodes, and each node monitored M unidirectional paths/LSPs, then 651 total number of BFD sessions in such network will be: 653 (((N - 1) x M) x 2) 655 Assuming that each network node creates one reflector BFD session to 656 handle all local BFD target identifiers, then total number of BFD 657 sessions in same scenario will be: 659 (((N - 1) x M) + N) 661 12. Co-existence with Traditional BFD 663 This mechanism has no issues being deployed with traditional BFDs 664 ([RFC5881]/[RFC5883]/[RFC5884]/[RFC5885]) because BFD discriminators 665 which allow this mechanism to function are explicitly reserved and 666 separate UDP port values are used with S-BFD. 668 13. BFD Echo 670 BFD echo is outside the scope of this document. 672 14. Security Considerations 674 Same security considerations as [RFC5880], [RFC5881], [RFC5883], 675 [RFC5884] and [RFC5885] apply to this document. 677 Additionally, implementing the following measures will strengthen 678 security aspects of the mechanism described by this document. 680 o Implementations MUST provide filtering capability based on source 681 IP addresses or source node segment IDs of received BFD control 682 packets: [RFC2827]. 684 o Implementations MUST NOT act on received BFD control packets 685 containing Martian addresses as source IP addresses. 687 o Implementations MUST ensure response target IP addresses or node 688 segment IDs are reachable. 690 o Initiator MAY pick crypto sequence number based on authentication 691 mode configured. 693 o The reflector MUST NOT look at the crypto sequence number before 694 accepting the packet. 696 o Reflector MAY look at the Key ID 697 [I-D.ietf-bfd-generic-crypto-auth] in the incoming packet and 698 verify the authentication data. 700 o Reflector MUST accept the packet if authentication is successful. 702 o Reflector MUST compute the Authentication data and MUST use the 703 same sequence number that it received in the S-BFD packet that it 704 is responding to. 706 o Initiator MUST accept the S-BFD packet if it either comes with the 707 same sequence number as it had sent or its within the window that 708 it finds acceptable (described in detail in 709 [I-D.ietf-bfd-generic-crypto-auth]) 711 Using the above method, 713 o Reflectors continue to remain stateless despite using security. 715 o Reflectors are not susceptible to replay attacks as they always 716 respond to S-BFD packets irrespective of the sequence number 717 carried. 719 o An attacker cannot impersonate the Reflector since the Initiator 720 will only accept S-BFD packets that come with the sequence number 721 that it had originally used when sending the S-BFD packet. 723 15. IANA Considerations 725 BFD Target Identifier types: 727 Value BFD Target Identifier Type 728 ------ -------------------------- 729 0 Reserved 730 1 Network Target Discriminator 732 New UDP port number, TBD1, will be requested for S-BFD. 734 16. Acknowledgements 736 Authors would like to thank Jeffrey Haas for performing thorough 737 reviews and providing number of suggestions. Authors would like to 738 thank Girija Raghavendra Rao, Marc Binderberger, Les Ginsberg, 739 Srihari Raghavan, Vanitha Neelamegam and Vengada Prasad Govindan from 740 Cisco Systems for providing valuable comments. 742 17. Contributing Authors 744 Tarek Saad 745 Cisco Systems 746 Email: tsaad@cisco.com 748 Siva Sivabalan 749 Cisco Systems 750 Email: msiva@cisco.com 752 Nagendra Kumar 753 Cisco Systems 754 Email: naikumar@cisco.com 756 Mallik Mudigonda 757 Cisco Systems 758 Email: mmudigon@cisco.com 760 Sam Aldrin 761 Huawei Technologies 762 Email: aldrin.ietf@gmail.com 764 18. References 766 18.1. Normative References 768 [I-D.aldrin-bfd-seamless-use-case] 769 Aldrin, S., Bhatia, M., Mirsky, G., Kumar, N., and S. 770 Matsushima, "Seamless Bidirectional Forwarding Detection 771 (BFD) Use Case", draft-aldrin-bfd-seamless-use-case-01 772 (work in progress), March 2014. 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 778 (BFD)", RFC 5880, June 2010. 780 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 781 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 782 2010. 784 [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 785 (BFD) for Multihop Paths", RFC 5883, June 2010. 787 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 788 "Bidirectional Forwarding Detection (BFD) for MPLS Label 789 Switched Paths (LSPs)", RFC 5884, June 2010. 791 18.2. Informative References 793 [I-D.ietf-bfd-generic-crypto-auth] 794 Bhatia, M., Manral, V., and D. Zhang, "BFD Generic 795 Cryptographic Authentication", draft-ietf-bfd-generic- 796 crypto-auth-05 (work in progress), October 2013. 798 [I-D.previdi-filsfils-isis-segment-routing] 799 Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M., 800 Decraene, B., Litkowski, S., Milojevic, I., Shakir, R., 801 Ytti, S., Henderickx, W., and J. Tantsura, "Segment 802 Routing with IS-IS Routing Protocol", draft-previdi- 803 filsfils-isis-segment-routing-02 (work in progress), March 804 2013. 806 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 807 Defeating Denial of Service Attacks which employ IP Source 808 Address Spoofing", BCP 38, RFC 2827, May 2000. 810 [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 811 Detection (BFD) for the Pseudowire Virtual Circuit 812 Connectivity Verification (VCCV)", RFC 5885, June 2010. 814 Appendix A. Loop Problem 816 Consider a scenario where we have two nodes and both are S-BFD 817 capable. 819 Node A (IP 1.1.1.1) ---------------- Node B (IP 2.2.2.2) 820 | 821 | 822 Man in the Middle (MiM) 824 Assume node A reserved a discriminator 0x01010101 for target 825 identifier 1.1.1.1 and has a reflector session in listening mode. 826 Similarly node B reserved a discriminator 0x02020202 for its target 827 identifier 2.2.2.2 and also has a reflector session in listening 828 mode. 830 Suppose MiM sends a spoofed packet with MyDisc = 0x01010101, YourDisc 831 = 0x02020202, source IP as 1.1.1.1 and dest IP as 2.2.2.2. When this 832 packet reaches Node B, the reflector session on Node B will swap the 833 discriminators and IP addresses of the received packet and reflect it 834 back, since YourDisc of the received packet matched with reserved 835 discriminator of Node B. The reflected packet that reached Node A 836 will have MyDdisc=0x02020202 and YourDisc=0x01010101. Since YourDisc 837 of the received packet matched the reserved discriminator of Node A, 838 Node A will swap the discriminators and reflects the packet back to 839 Node B. Since reflectors MUST set the TTL of the reflected packets to 840 255, the above scenario will result in an infinite loop with just one 841 malicious packet injected from MiM. 843 FYI: Packet fields do not carry any direction information, i.e., if 844 this is Ping packet or reply packet. 846 Solutions 848 The current proposals to avoid the loop problem are: 850 o Overload "D" bit (Demand mode bit): Initiator always sets the 'D' 851 bit and reflector clears it. This way we can identify if a 852 received packet was a reflected packet and avoid reflecting it 853 back. However this changes the interpretation of 'D' bit. 855 o Use of State field in the BFD control packets: Initiator will 856 always send packets with State set to "DOWN" and reflector will 857 send back packets with state field set to "UP. Reflectors will 858 never reflect any received packets with state as "UP". However 859 the only issue is the use of state field differently i.e. state in 860 the S-BFD control packet from initiator does not reflect the local 861 state which is anyway not significant at reflector. 863 o Use of local discriminator as My Disc at reflector: Reflector will 864 always fill in My Discriminator with a locally allocated 865 discriminator value (not reserved discriminators) and will not 866 copy it from the received packet. 868 Authors' Addresses 870 Nobo Akiya 871 Cisco Systems 873 Email: nobo@cisco.com 875 Carlos Pignataro 876 Cisco Systems 878 Email: cpignata@cisco.com 880 Dave Ward 881 Cisco Systems 883 Email: wardd@cisco.com 885 Manav Bhatia 886 Alcatel-Lucent 888 Email: manav.bhatia@alcatel-lucent.com 889 Santosh 890 Juniper Networks 892 Email: santoshpk@juniper.net