idnits 2.17.1 draft-ietf-bfd-base-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (January 5, 2010) is 5224 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 RFC: RFC 1321 (ref. 'MD5') ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. 'SHA1') -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) Summary: 4 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 D. Katz 3 Internet Draft Juniper Networks 4 Intended status: Proposed Standard D. Ward 5 Juniper Networks 6 Expires: July, 2010 January 5, 2010 8 Bidirectional Forwarding Detection 9 draft-ietf-bfd-base-10.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the BSD License. 47 Abstract 49 This document describes a protocol intended to detect faults in the 50 bidirectional path between two forwarding engines, including 51 interfaces, data link(s), and to the extent possible the forwarding 52 engines themselves, with potentially very low latency. It operates 53 independently of media, data protocols, and routing protocols. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1 Addressing and Session Establishment . . . . . . . . . . . 6 67 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 6 68 4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7 69 4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 70 4.2 Simple Password Authentication Section Format . . . . . 12 71 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 72 Section Format . . . . . . . . . . . . . . . . . . . . . 13 73 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 74 Section Format . . . . . . . . . . . . . . . . . . . . . 14 75 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 15 76 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 16 77 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 78 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 17 79 6.3 Demultiplexing and the Discriminator Fields . . . . . . 19 80 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 20 81 6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 20 82 6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 21 83 6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 22 84 6.7.1 Enabling and Disabling Authentication . . . . . . 23 85 6.7.2 Simple Password Authentication . . . . . . . . . . 24 86 6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 25 87 6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 26 88 6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28 89 6.8.1 State Variables . . . . . . . . . . . . . . . . . 29 90 6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32 91 6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32 92 6.8.4 Calculating the Detection Time . . . . . . . . . . 34 93 6.8.5 Detecting Failures with the Echo Function . . . . 35 94 6.8.6 Reception of BFD Control Packets . . . . . . . . . 35 95 6.8.7 Transmitting BFD Control Packets . . . . . . . . . 37 96 6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 41 97 6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 41 98 6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 41 99 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 42 100 6.8.12 Detect Multiplier Change . . . . . . . . . . . . 42 101 6.8.13 Enabling or Disabling the Echo Function . . . . . 42 102 6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 42 103 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 42 104 6.8.16 Administrative Control . . . . . . . . . . . . . 43 105 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43 106 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 44 107 7. Operational Considerations . . . . . . . . . . . . . . . . . 45 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46 109 9. Security Considerations . . . . . . . . . . . . . . . . . . 47 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . 48 111 10.1 Normative References . . . . . . . . . . . . . . . . . 48 112 10.2 Informative References . . . . . . . . . . . . . . . . 49 113 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 49 114 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 115 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 50 117 Changes from the previous draft . . . . . . . . . . . . . . . . 51 119 1. Introduction 121 An increasingly important feature of networking equipment is the 122 rapid detection of communication failures between adjacent systems, 123 in order to more quickly establish alternative paths. Detection can 124 come fairly quickly in certain circumstances when data link hardware 125 comes into play (such as SONET alarms.) However, there are media 126 that do not provide this kind of signaling (such as Ethernet), and 127 some media may not detect certain kinds of failures in the path, for 128 example, failing interfaces or forwarding engine components. 130 Networks use relatively slow "Hello" mechanisms, usually in routing 131 protocols, to detect failures when there is no hardware signaling to 132 help out. The time to detect failures ("Detection Times") available 133 in the existing protocols are no better than a second, which is far 134 too long for some applications and represents a great deal of lost 135 data at gigabit rates. Furthermore, routing protocol Hellos are of 136 no help when those routing protocols are not in use, and the 137 semantics of detection are subtly different--they detect a failure in 138 the path between the two routing protocol engines. 140 The goal of BFD is to provide low-overhead, short-duration detection 141 of failures in the path between adjacent forwarding engines, 142 including the interfaces, data link(s), and to the extent possible 143 the forwarding engines themselves. 145 An additional goal is to provide a single mechanism that can be used 146 for liveness detection over any media, at any protocol layer, with a 147 wide range of Detection Times and overhead, to avoid a proliferation 148 of different methods. 150 This document specifies the details of the base protocol. The use of 151 some mechanisms are application dependent and are specified in a 152 separate series of application documents. These issues are so noted. 154 Note that many of the exact mechanisms are implementation dependent 155 and will not affect interoperability, and are thus outside the scope 156 of this specification. Those issues are so noted. 158 2. Design 160 BFD is designed to detect failures in communication with a forwarding 161 plane next hop. It is intended to be implemented in some component 162 of the forwarding engine of a system, in cases where the forwarding 163 and control engines are separated. This not only binds the protocol 164 more to the forwarding plane, but decouples the protocol from the 165 fate of the routing protocol engine, making it useful in concert with 166 various "graceful restart" mechanisms for those protocols. BFD may 167 also be implemented in the control engine, though doing so may 168 preclude the detection of some kinds of failures. 170 BFD operates on top of any data protocol (network layer, link layer, 171 tunnels, etc.) being forwarded between two systems. It is always 172 run in a unicast, point-to-point mode. BFD packets are carried as 173 the payload of whatever encapsulating protocol is appropriate for the 174 medium and network. BFD may be running at multiple layers in a 175 system. The context of the operation of any particular BFD session 176 is bound to its encapsulation. 178 BFD can provide failure detection on any kind of path between 179 systems, including direct physical links, virtual circuits, tunnels, 180 MPLS LSPs, multihop routed paths, and unidirectional links (so long 181 as there is some return path, of course.) Multiple BFD sessions can 182 be established between the same pair of systems when multiple paths 183 between them are present in at least one direction, even if a lesser 184 number of paths are available in the other direction (multiple 185 parallel unidirectional links or MPLS LSPs, for example.) 187 The BFD state machine implements a three-way handshake, both when 188 establishing a BFD session and when tearing it down for any reason, 189 to ensure that both systems are aware of the state change. 191 BFD can be abstracted as a simple service. The service primitives 192 provided by BFD are to create, destroy, and modify a session, given 193 the destination address and other parameters. BFD in return provides 194 a signal to its clients indicating when the BFD session goes up or 195 down. 197 3. Protocol Overview 199 BFD is a simple hello protocol that in many respects is similar to 200 the detection components of well-known routing protocols. A pair of 201 systems transmit BFD packets periodically over each path between the 202 two systems, and if a system stops receiving BFD packets for long 203 enough, some component in that particular bidirectional path to the 204 neighboring system is assumed to have failed. Under some conditions, 205 systems may negotiate to not send periodic BFD packets in order to 206 reduce overhead. 208 A path is only declared to be operational when two-way communication 209 has been established between systems, though this does not preclude 210 the use of unidirectional links. 212 A separate BFD session is created for each communications path and 213 data protocol in use between two systems. 215 Each system estimates how quickly it can send and receive BFD packets 216 in order to come to an agreement with its neighbor about how rapidly 217 detection of failure will take place. These estimates can be 218 modified in real time in order to adapt to unusual situations. This 219 design also allows for fast systems on a shared medium with a slow 220 system to be able to more rapidly detect failures between the fast 221 systems while allowing the slow system to participate to the best of 222 its ability. 224 3.1. Addressing and Session Establishment 226 A BFD session is established based on the needs of the application 227 that will be making use of it. It is up to the application to 228 determine the need for BFD, and the addresses to use--there is no 229 discovery mechanism in BFD. For example, an OSPF [OSPF] 230 implementation may request a BFD session to be established to a 231 neighbor discovered using the OSPF Hello protocol. 233 3.2. Operating Modes 235 BFD has two operating modes which may be selected, as well as an 236 additional function that can be used in combination with the two 237 modes. 239 The primary mode is known as Asynchronous mode. In this mode, the 240 systems periodically send BFD Control packets to one another, and if 241 a number of those packets in a row are not received by the other 242 system, the session is declared to be down. 244 The second mode is known as Demand mode. In this mode, it is assumed 245 that a system has an independent way of verifying that it has 246 connectivity to the other system. Once a BFD session is established, 247 such a system may ask the other system to stop sending BFD Control 248 packets, except when the system feels the need to verify connectivity 249 explicitly, in which case a short sequence of BFD Control packets is 250 exchanged, and then the far system quiesces. Demand mode may operate 251 independently in each direction, or simultaneously. 253 An adjunct to both modes is the Echo function. When the Echo 254 function is active, a stream of BFD Echo packets is transmitted in 255 such a way as to have the other system loop them back through its 256 forwarding path. If a number of packets of the echoed data stream 257 are not received, the session is declared to be down. The Echo 258 function may be used with either Asynchronous or Demand modes. Since 259 the Echo function is handling the task of detection, the rate of 260 periodic transmission of Control packets may be reduced (in the case 261 of Asynchronous mode) or eliminated completely (in the case of Demand 262 mode.) 264 Pure asynchronous mode is advantageous in that it requires half as 265 many packets to achieve a particular Detection Time as does the Echo 266 function. It is also used when the Echo function cannot be supported 267 for some reason. 269 The Echo function has the advantage of truly testing only the 270 forwarding path on the remote system. This may reduce round-trip 271 jitter and thus allow more aggressive Detection Times, as well as 272 potentially detecting some classes of failure that might not 273 otherwise be detected. 275 The Echo function may be enabled individually in each direction. It 276 is enabled in a particular direction only when the system that loops 277 the Echo packets back signals that it will allow it, and when the 278 system that sends the Echo packets decides it wishes to. 280 Demand mode is useful in situations where the overhead of a periodic 281 protocol might prove onerous, such as a system with a very large 282 number of BFD sessions. It is also useful when the Echo function is 283 being used symmetrically. Demand mode has the disadvantage that 284 Detection Times are essentially driven by the heuristics of the 285 system implementation and are not known to the BFD protocol. Demand 286 mode may not be used when the path round trip time is greater than 287 the desired Detection Time, or the protocol will fail to work 288 properly. See section 6.6 for more details. 290 4. BFD Control Packet Format 292 4.1. Generic BFD Control Packet Format 294 BFD Control packets are sent in an encapsulation appropriate to the 295 environment. The specific encapsulation is outside of the scope of 296 this specification. See the appropriate application document for 297 encapsulation details. 299 The BFD Control packet has a Mandatory Section and an optional 300 Authentication Section. The format of the Authentication Section, if 301 present, is dependent on the type of authentication in use. 303 The Mandatory Section of a BFD Control packet has the following 304 format: 306 0 1 2 3 307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | My Discriminator | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Your Discriminator | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Desired Min TX Interval | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Required Min RX Interval | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Required Min Echo RX Interval | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 An optional Authentication Section MAY be present: 324 0 1 2 3 325 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Auth Type | Auth Len | Authentication Data... | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Version (Vers) 332 The version number of the protocol. This document defines 333 protocol version 1. 335 Diagnostic (Diag) 337 A diagnostic code specifying the local system's reason for the 338 last change in session state. Values are: 340 0 -- No Diagnostic 341 1 -- Control Detection Time Expired 342 2 -- Echo Function Failed 343 3 -- Neighbor Signaled Session Down 344 4 -- Forwarding Plane Reset 345 5 -- Path Down 346 6 -- Concatenated Path Down 347 7 -- Administratively Down 348 8 -- Reverse Concatenated Path Down 349 9-31 -- Reserved for future use 351 This field allows remote systems to determine the reason that the 352 previous session failed, for example. 354 State (Sta) 356 The current BFD session state as seen by the transmitting system. 357 Values are: 359 0 -- AdminDown 360 1 -- Down 361 2 -- Init 362 3 -- Up 364 Poll (P) 366 If set, the transmitting system is requesting verification of 367 connectivity, or of a parameter change, and is expecting a packet 368 with the Final (F) bit in reply. If clear, the transmitting 369 system is not requesting verification. 371 Final (F) 373 If set, the transmitting system is responding to a received BFD 374 Control packet that had the Poll (P) bit set. If clear, the 375 transmitting system is not responding to a Poll. 377 Control Plane Independent (C) 379 If set, the transmitting system's BFD implementation does not 380 share fate with its control plane (in other words, BFD is 381 implemented in the forwarding plane and can continue to function 382 through disruptions in the control plane.) If clear, the 383 transmitting system's BFD implementation shares fate with its 384 control plane. 386 The use of this bit is application dependent and is outside the 387 scope of this specification. See specific application 388 specifications for details. 390 Authentication Present (A) 392 If set, the Authentication Section is present and the session is 393 to be authenticated (see section 6.7 for details). 395 Demand (D) 397 If set, Demand mode is active in the transmitting system (the 398 system wishes to operate in Demand mode, knows that the session is 399 up in both directions, and is directing the remote system to cease 400 the periodic transmission of BFD Control packets.) If clear, 401 Demand mode is not active in the transmitting system. 403 Multipoint (M) 405 This bit is reserved for future point-to-multipoint extensions to 406 BFD. It MUST be zero on both transmit and receipt. 408 Detect Mult 410 Detection time multiplier. The negotiated transmit interval, 411 multiplied by this value, provides the Detection Time for the 412 receiving system in Asynchronous mode. 414 Length 416 Length of the BFD Control packet, in bytes. 418 My Discriminator 420 A unique, nonzero discriminator value generated by the 421 transmitting system, used to demultiplex multiple BFD sessions 422 between the same pair of systems. 424 Your Discriminator 426 The discriminator received from the corresponding remote system. 427 This field reflects back the received value of My Discriminator, 428 or is zero if that value is unknown. 430 Desired Min TX Interval 432 This is the minimum interval, in microseconds, that the local 433 system would like to use when transmitting BFD Control packets, 434 less any jitter applied (see section 6.8.2). The value zero is 435 reserved. 437 Required Min RX Interval 439 This is the minimum interval, in microseconds, between received 440 BFD Control packets that this system is capable of supporting, 441 less any jitter applied by the sender (see section 6.8.2). If 442 this value is zero, the transmitting system does not want the 443 remote system to send any periodic BFD Control packets. 445 Required Min Echo RX Interval 447 This is the minimum interval, in microseconds, between received 448 BFD Echo packets that this system is capable of supporting, less 449 any jitter applied by the sender (see section 6.8.9). If this 450 value is zero, the transmitting system does not support the 451 receipt of BFD Echo packets. 453 Auth Type 455 The authentication type in use, if the Authentication Present (A) 456 bit is set. 458 0 - Reserved 459 1 - Simple Password 460 2 - Keyed MD5 461 3 - Meticulous Keyed MD5 462 4 - Keyed SHA1 463 5 - Meticulous Keyed SHA1 464 6-255 - Reserved for future use 466 Auth Len 468 The length, in bytes, of the authentication section, including the 469 Auth Type and Auth Len fields. 471 4.2. Simple Password Authentication Section Format 473 If the Authentication Present (A) bit is set in the header, and the 474 Authentication Type field contains 1 (Simple Password), the 475 Authentication Section has the following format: 477 0 1 2 3 478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Auth Type | Auth Len | Auth Key ID | Password... | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | ... | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Auth Type 487 The Authentication Type, which in this case is 1 (Simple 488 Password.) 490 Auth Len 492 The length of the Authentication Section, in bytes. For Simple 493 Password authentication, the length is equal to the password 494 length plus three. 496 Auth Key ID 498 The authentication key ID in use for this packet. This allows 499 multiple keys to be active simultaneously. 501 Password 503 The simple password in use on this session. The password is a 504 binary string, and MUST be from 1 to 16 bytes in length. The 505 password MUST be encoded and configured according to section 506 6.7.2. 508 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 510 The use of MD5-based authentication is strongly discouraged. 511 However, it is documented here for compatibility with existing 512 implementations. 514 If the Authentication Present (A) bit is set in the header, and the 515 Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous 516 Keyed MD5), the Authentication Section has the following format: 518 0 1 2 3 519 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Auth Type | Auth Len | Auth Key ID | Reserved | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Sequence Number | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Auth Key/Digest... | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | ... | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Auth Type 532 The Authentication Type, which in this case is 2 (Keyed MD5) or 3 533 (Meticulous Keyed MD5). 535 Auth Len 537 The length of the Authentication Section, in bytes. For Keyed MD5 538 and Meticulous Keyed MD5 authentication, the length is 24. 540 Auth Key ID 542 The authentication key ID in use for this packet. This allows 543 multiple keys to be active simultaneously. 545 Reserved 547 This byte MUST be set to zero on transmit, and ignored on receipt. 549 Sequence Number 551 The Sequence Number for this packet. For Keyed MD5 552 Authentication, this value is incremented occasionally. For 553 Meticulous Keyed MD5 Authentication, this value is incremented for 554 each successive packet transmitted for a session. This provides 555 protection against replay attacks. 557 Auth Key/Digest 559 This field carries the 16 byte MD5 digest for the packet. When 560 the digest is calculated, the shared MD5 key is stored in this 561 field. The shared key MUST be encoded and configured to section 562 6.7.3. The shared key MUST be 16 bytes in length. 564 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 566 If the Authentication Present (A) bit is set in the header, and the 567 Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous 568 Keyed SHA1), the Authentication Section has the following format: 570 0 1 2 3 571 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Auth Type | Auth Len | Auth Key ID | Reserved | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Sequence Number | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Auth Key/Hash... | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | ... | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Auth Type 584 The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 585 (Meticulous Keyed SHA1). 587 Auth Len 589 The length of the Authentication Section, in bytes. For Keyed 590 SHA1 and Meticulous Keyed SHA1 authentication, the length is 28. 592 Auth Key ID 594 The authentication key ID in use for this packet. This allows 595 multiple keys to be active simultaneously. 597 Reserved 599 This byte MUST be set to zero on transmit, and ignored on receipt. 601 Sequence Number 603 The Sequence Number for this packet. For Keyed SHA1 604 Authentication, this value is incremented occasionally. For 605 Meticulous Keyed SHA1 Authentication, this value is incremented 606 for each successive packet transmitted for a session. This 607 provides protection against replay attacks. 609 Auth Key/Hash 611 This field carries the 20 byte SHA1 hash for the packet. When the 612 hash is calculated, the shared SHA1 key is stored in this field. 613 The shared key MUST be encoded and configured to section 6.7.4. 614 The shared key MUST be 20 bytes in length. 616 5. BFD Echo Packet Format 618 BFD Echo packets are sent in an encapsulation appropriate to the 619 environment. See the appropriate application documents for the 620 specifics of particular environments. 622 The payload of a BFD Echo packet is a local matter, since only the 623 sending system ever processes the content. The only requirement is 624 that sufficient information is included to demultiplex the received 625 packet to the correct BFD session after it is looped back to the 626 sender. The contents are otherwise outside the scope of this 627 specification. 629 Some form of authentication SHOULD be included, since Echo packets 630 may be spoofed. 632 6. Elements of Procedure 634 This section discusses the normative requirements of the protocol in 635 order to achieve interoperability. It is important for implementors 636 to enforce only the requirements specified in this section, as 637 misguided pedantry has been proven by experience to adversely affect 638 interoperability. 640 Remember that all references of the form "bfd.Xx" refer to internal 641 state variables (defined in section 6.8.1), whereas all references to 642 "the Xxx field" refer to fields in the protocol packets themselves 643 (defined in section 4). 645 6.1. Overview 647 A system may take either an Active role or a Passive role in session 648 initialization. A system taking the Active role MUST send BFD 649 Control packets for a particular session, regardless of whether it 650 has received any BFD packets for that session. A system taking the 651 Passive role MUST NOT begin sending BFD packets for a particular 652 session until it has received a BFD packet for that session, and thus 653 has learned the remote system's discriminator value. At least one 654 system MUST take the Active role (possibly both.) The role that a 655 system takes is specific to the application of BFD, and is outside 656 the scope of this specification. 658 A session begins with the periodic, slow transmission of BFD Control 659 packets. When bidirectional communication is achieved, the BFD 660 session comes Up. 662 Once the BFD session is Up, a system can choose to start the Echo 663 function if it desires to and the other system signals that it will 664 allow it. The rate of transmission of Control packets is typically 665 kept low when the Echo function is active. 667 If the Echo function is not active, the transmission rate of Control 668 packets may be increased to a level necessary to achieve the 669 Detection Time requirements for the session. 671 Once the session is up, a system may signal that it has entered 672 Demand mode, and the transmission of BFD Control packets by the 673 remote system ceases. Other means of implying connectivity are used 674 to keep the session alive. If either system wishes to verify 675 bidirectional connectivity, it can initiate a short exchange of BFD 676 Control packets (a "Poll Sequence"; see section 6.5) to do so. 678 If Demand mode is not active, and no Control packets are received in 679 the calculated Detection Time (see section 6.8.4), the session is 680 declared Down. This is signaled to the remote end via the State 681 (Sta) field in outgoing packets. 683 If sufficient Echo packets are lost, the session is declared down in 684 the same manner. See section 6.8.5. 686 If Demand mode is active and no appropriate Control packets are 687 received in response to a Poll Sequence, the session is declared down 688 in the same manner. See section 6.6. 690 If the session goes down, the transmission of Echo packets (if any) 691 ceases, and the transmission of Control packets goes back to the slow 692 rate. 694 Once a session has been declared down, it cannot come back up until 695 the remote end first signals that it is down (by leaving the Up 696 state), thus implementing a three-way handshake. 698 A session MAY be kept administratively down by entering the AdminDown 699 state and sending an explanatory diagnostic code in the Diagnostic 700 field. 702 6.2. BFD State Machine 704 The BFD state machine is quite straightforward. There are three 705 states through which a session normally proceeds, two for 706 establishing a session (Init and Up) and one for tearing down a 707 session (Down.) This allows a three-way handshake for both session 708 establishment and session teardown (assuring that both systems are 709 aware of all session state changes.) A fourth state (AdminDown) 710 exists so that a session can be administratively put down 711 indefinitely. 713 Each system communicates its session state in the State (Sta) field 714 in the BFD Control packet, and that received state in combination 715 with the local session state drives the state machine. 717 Down state means that the session is down (or has just been created.) 718 A session remains in Down state until the remote system indicates 719 that it agrees that the session is down by sending a BFD Control 720 packet with the State field set to anything other than Up. If that 721 packet signals Down state, the session advances to Init state; if 722 that packet signals Init state, the session advances to Up state. 723 Semantically, Down state indicates that the forwarding path is 724 unavailable, and that appropriate actions should be taken by the 725 applications monitoring the state of the BFD session. A system MAY 726 hold a session in Down state indefinitely (by simply refusing to 727 advance the session state.) This may be done for operational or 728 administrative reasons, among others. 730 Init state means that the remote system is communicating, and the 731 local system desires to bring the session up, but the remote system 732 does not yet realize it. A session will remain in Init state until 733 either a BFD Control Packet is received that is signaling Init or Up 734 state (in which case the session advances to Up state) or until the 735 Detection Time expires, meaning that communication with the remote 736 system has been lost (in which case the session advances to Down 737 state.) 739 Up state means that the BFD session has successfully been 740 established, and implies that connectivity between the systems is 741 working. The session will remain in the Up state until either 742 connectivity fails, or the session is taken down administratively. 743 If either the remote system signals Down state, or the Detection Time 744 expires, the session advances to Down state. 746 AdminDown state means that the session is being held administratively 747 down. This causes the remote system to enter Down state, and remain 748 there until the local system exits AdminDown state. AdminDown state 749 has no semantic implications for the availability of the forwarding 750 path. 752 The following diagram provides an overview of the state machine. 753 Transitions involving AdminDown state are deleted for clarity (but 754 are fully specified in sections 6.8.6 and 6.8.16.) The notation on 755 each arc represents the state of the remote system (as received in 756 the State field in the BFD Control packet) or indicates the 757 expiration of the Detection Timer. 759 +--+ 760 | | UP, ADMIN DOWN, TIMER 761 | V 762 DOWN +------+ INIT 763 +------------| |------------+ 764 | | DOWN | | 765 | +-------->| |<--------+ | 766 | | +------+ | | 767 | | | | 768 | | ADMIN DOWN,| | 769 | |ADMIN DOWN, DOWN,| | 770 | |TIMER TIMER| | 771 V | | V 772 +------+ +------+ 773 +----| | | |----+ 774 DOWN| | INIT |--------------------->| UP | |INIT, UP 775 +--->| | INIT, UP | |<---+ 776 +------+ +------+ 778 6.3. Demultiplexing and the Discriminator Fields 780 Since multiple BFD sessions may be running between two systems, there 781 needs to be a mechanism for demultiplexing received BFD packets to 782 the proper session. 784 Each system MUST choose an opaque discriminator value that identifies 785 each session, and which MUST be unique among all BFD sessions on the 786 system. The local discriminator is sent in the My Discriminator 787 field in the BFD Control packet, and is echoed back in the Your 788 Discriminator field of packets sent from the remote end. 790 Once the remote end echoes back the local discriminator, all further 791 received packets are demultiplexed based on the Your Discriminator 792 field only (which means that, among other things, the source address 793 field can change or the interface over which the packets are received 794 can change, but the packets will still be associated with the proper 795 session.) 797 The method of demultiplexing the initial packets (in which Your 798 Discriminator is zero) is application-dependent, and is thus outside 799 the scope of this specification. 801 Note that it is permissible for a system to change its discriminator 802 during a session without affecting the session state, since only that 803 system uses its discriminator for demultiplexing purposes (by having 804 the other system reflect it back.) The implications on an 805 implementation for changing the discriminator value is outside the 806 scope of this specification. 808 6.4. The Echo Function and Asymmetry 810 The Echo function can be run independently in each direction between 811 a pair of systems. For whatever reason, a system may advertise that 812 it is willing to receive (and loop back) Echo packets, but may not 813 wish to ever send any. The fact that a system is sending Echo 814 packets is not directly signaled to the system looping them back. 816 When a system is using the Echo function, it is advantageous to 817 choose a sedate reception rate for Control packets, since liveness 818 detection is being handled by the Echo packets. This can be 819 controlled by manipulating the Required Min RX Interval field (see 820 section 6.8.3.) 822 If the Echo function is only being run in one direction, the system 823 not running the Echo function will more likely wish to receive fairly 824 rapid Control packets in order to achieve its desired Detection Time. 825 Since BFD allows independent transmission rates in each direction, 826 this is easily accomplished. 828 A system SHOULD otherwise advertise the lowest value of Required Min 829 RX Interval and Required Min Echo RX Interval that it can under the 830 circumstances, to give the other system more freedom in choosing its 831 transmission rate. Note that a system is committing to be able to 832 receive both streams of packets at the rate it advertises, so this 833 should be taken into account when choosing the values to advertise. 835 6.5. The Poll Sequence 837 A Poll Sequence is an exchange of BFD Control packets that is used in 838 some circumstances to ensure that the remote system is aware of 839 parameter changes. It is also used in Demand mode (see section 6.6) 840 to validate bidirectional connectivity. 842 A Poll Sequence consists of a system sending periodic BFD Control 843 packets with the Poll (P) bit set. When the other system receives a 844 Poll, it immediately transmits a BFD Control packet with the Final 845 (F) bit set, independent of any periodic BFD Control packets it may 846 be sending (see section 6.8.7). When the system sending the Poll 847 sequence receives a packet with Final, the Poll Sequence is 848 terminated, and any subsequent BFD Control packets are sent with the 849 Poll bit cleared. A BFD Control packet MUST NOT have both the Poll 850 (P) and Final (F) bits set. 852 If periodic BFD Control packets are already being sent (the remote 853 system is not in Demand mode), the Poll Sequence MUST be performed by 854 setting the Poll (P) bit on those scheduled periodic transmissions; 855 additional packets MUST NOT be sent. 857 After a Poll Sequence is terminated, the system requesting the Poll 858 Sequence will cease the periodic transmission of BFD Control packets 859 if the remote end is in Demand mode; otherwise it will return to the 860 periodic transmission of BFD Control packets with the Poll (P) bit 861 clear. 863 Typically, the entire sequence consists of a single packet in each 864 direction, though packet losses or relatively long packet latencies 865 may result in multiple Poll packets to be sent before the sequence 866 terminates. 868 6.6. Demand Mode 870 Demand mode is requested independently in each direction by virtue of 871 a system setting the Demand (D) bit in its BFD Control packets. The 872 system receiving the Demand bit ceases the periodic transmission of 873 BFD Control packets. If both systems are operating in Demand mode, 874 no periodic BFD Control packets will flow in either direction. 876 Demand mode requires that some other mechanism is used to imply 877 continuing connectivity between the two systems. The mechanism used 878 does not have to be the same in both directions, and is outside of 879 the scope of this specification. One possible mechanism is the 880 receipt of traffic from the remote system; another is the use of the 881 Echo function. 883 When a system in Demand mode wishes to verify bidirectional 884 connectivity, it initiates a Poll Sequence (see section 6.5). If no 885 response is received to a Poll, the Poll is repeated until the 886 Detection Time expires, at which point the session is declared to be 887 down. Note that if Demand mode is operating only on the local 888 system, the Poll Sequence is performed by simply setting the Poll (P) 889 bit in regular periodic BFD Control packets, as required by section 890 6.5. 892 The Detection Time in Demand mode is calculated differently than in 893 Asynchronous mode; it is based on the transmit rate of the local 894 system, rather than the transmit rate of the remote system. This 895 ensures that the Poll Sequence mechanism works properly. See section 896 6.8.4 for more details. 898 Note that the Poll mechanism will always fail unless the negotiated 899 Detection Time is greater than the round trip time between the two 900 systems. Enforcement of this constraint is outside the scope of this 901 specification. 903 Demand mode MAY be enabled or disabled at any time, independently in 904 each direction, by setting or clearing the Demand (D) bit in the BFD 905 Control packet, without affecting the BFD session state. Note that 906 the Demand bit MUST NOT be set unless both systems perceive the 907 session to be Up (the local system thinks the session is Up, and the 908 remote system last reported Up state in the State (Sta) field of the 909 BFD Control packet.) 911 When the transmitted value of the Demand (D) bit is to be changed, 912 the transmitting system MUST initiate a Poll Sequence in conjunction 913 with changing the bit in order to ensure that both systems are aware 914 of the change. 916 If Demand mode is active on either or both systems, a Poll Sequence 917 MUST be initiated whenever the contents of the next BFD Control 918 packet to be sent would be different than the contents of the 919 previous packet, with the exception of the Poll (P) and Final (F) 920 bits. This ensures that parameter changes are transmitted to the 921 remote system and that the remote system acknowledges these changes. 923 Because the underlying detection mechanism is unspecified, and may 924 differ between the two systems, the overall Detection Time 925 characteristics of the path will not be fully known to either system. 926 The total Detection Time for a particular system is the sum of the 927 time prior to the initiation of the Poll Sequence, plus the 928 calculated Detection Time. 930 Note that if Demand mode is enabled in only one direction, continuous 931 bidirectional connectivity verification is lost (only connectivity in 932 the direction from the system in Demand mode to the other system will 933 be verified.) Resolving the issue of one system requesting Demand 934 mode while the other requires continuous bidirectional connectivity 935 verification is outside the scope of this specification. 937 6.7. Authentication 939 An optional Authentication Section MAY be present in the BFD Control 940 packet. In its generic form, the purpose of the Authentication 941 Section is to carry all necessary information, based on the 942 authentication type in use, to allow the receiving system to 943 determine the validity of the received packet. The exact mechanism 944 depends on the authentication type in use, but in general the 945 transmitting system will put information in the Authentication 946 Section that vouches for the packet's validity, and the receiving 947 system will examine the Authentication Section and either accept the 948 packet for further processing, or discard it. 950 The same authentication type, and any keys or other necessary 951 information, obviously must be in use by the two systems. The 952 negotiation of authentication type, key exchange, etc. are all 953 outside the scope of this specification and are expected to be 954 performed by means outside of the protocol. 956 Note that in the subsections below, to "accept" a packet means only 957 that the packet has passed authentication; it may in fact be 958 discarded for other reasons as described in the general packet 959 reception rules described in section 6.8.6. 961 Implementations supporting authentication MUST support both types of 962 SHA1 authentication. Other forms of authentication are optional. 964 6.7.1. Enabling and Disabling Authentication 966 It may be desirable to enable or disable authentication on a session 967 without disturbing the session state. The exact mechanism for doing 968 so is outside the scope of this specification. However, it is useful 969 to point out some issues in supporting this mechanism. 971 In a simple implementation, a BFD session will fail when 972 authentication is either turned on or turned off, because the packet 973 acceptance rules essentially require the local and remote machines to 974 do so in a more or less synchronized fashion (within the Detection 975 Time)--a packet with authentication will only be accepted if 976 authentication is "in use" (and likewise packets without 977 authentication. 979 One possible approach is to build an implementation such that 980 authentication is configured, but not considered "in use" until the 981 first packet containing a matching authentication section is received 982 (providing the necessary synchronization.) Likewise, authentication 983 could be configured off, but still considered "in use" until the 984 receipt of the first packet without the authentication section. 986 In order to avoid security risks, implementations using this method 987 SHOULD only allow the authentication state to be changed at most once 988 without some form of intervention (so that authentication cannot be 989 turned on and off repeatedly simply based on the receipt of BFD 990 Control packets from remote systems.) Unless it is desired to enable 991 or disable authentication, an implementation SHOULD NOT allow the 992 authentication state to change based on the receipt of BFD Control 993 packets. 995 6.7.2. Simple Password Authentication 997 The most straightforward (and weakest) form of authentication is 998 Simple Password Authentication. In this method of authentication, 999 one or more Passwords (with corresponding Key IDs) are configured in 1000 each system and one of these Password/ID pairs is carried in each BFD 1001 Control packet. The receiving system accepts the packet if the 1002 Password and Key ID matches one of the Password/ID pairs configured 1003 in that system. 1005 Transmission Using Simple Password Authentication 1007 The currently selected password and Key ID for the session MUST be 1008 stored in the Authentication Section of each outgoing BFD Control 1009 packet. The Auth Type field MUST be set to 1 (Simple Password.) 1010 The Auth Len field MUST be set to the proper length (4 to 19 1011 bytes). 1013 The password is a binary string, and MUST be 1 to 16 bytes in 1014 length. All implementations MUST support the configuration of any 1015 arbitrary binary string to ensure interoperability. Other 1016 configuration methods MAY be supported. 1018 Reception Using Simple Password Authentication 1020 If the received BFD Control packet does not contain an 1021 Authentication Section, or the Auth Type is not 1 (Simple 1022 Password), then the received packet MUST be discarded. 1024 If the Auth Key ID field does not match the ID of a configured 1025 password, the received packet MUST be discarded. 1027 If the Auth Len field is not equal to the length of the password 1028 selected by the Key ID, plus three, the packet MUST be discarded. 1030 If the Password field does not match the password selected by the 1031 Key ID, the packet MUST be discarded. 1033 Otherwise, the packet MUST be accepted. 1035 6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 1037 The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are 1038 very similar to those used in other protocols. In these methods of 1039 authentication, one or more secret keys (with corresponding Key IDs) 1040 are configured in each system. One of the Keys is included in an MD5 1041 [MD5] digest calculated over the outgoing BFD Control packet, but the 1042 Key itself is not carried in the packet. To help avoid replay 1043 attacks, a sequence number is also carried in each packet. For Keyed 1044 MD5, the sequence number is occasionally incremented. For Meticulous 1045 Keyed MD5, the sequence number is incremented on every packet. 1047 The receiving system accepts the packet if the Key ID matches one of 1048 the configured Keys, an MD5 digest including the selected key matches 1049 that carried in the packet, and if the sequence number is greater 1050 than or equal to the last sequence number received (for Keyed MD5), 1051 or strictly greater than the last sequence number received (for 1052 Meticulous Keyed MD5.) 1054 Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication 1056 The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous 1057 Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key 1058 ID field MUST be set to the ID of the current authentication key. 1059 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1061 The authentication key value is a binary string of 16 bytes, and 1062 MUST be placed into the Auth Key/Digest field. All 1063 implementations MUST support the configuration of any arbitrary 1064 binary string to ensure interoperability. Other configuration 1065 methods MAY be supported. 1067 An MD5 digest MUST be calculated over the entire BFD control 1068 packet. The resulting digest MUST be stored in the Auth 1069 Key/Digest field prior to transmission (replacing the secret key, 1070 which MUST NOT be carried in the packet.) 1072 For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular 1073 fashion (when treated as an unsigned 32 bit value.) 1074 bfd.XmitAuthSeq SHOULD be incremented when the session state 1075 changes, or when the transmitted BFD Control packet carries 1076 different contents than the previously transmitted packet. The 1077 decision as to when to increment bfd.XmitAuthSeq is outside the 1078 scope of this specification. See the section entitled "Security 1079 Considerations" below for a discussion. 1081 For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a 1082 circular fashion (when treated as an unsigned 32 bit value.) 1084 Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication 1086 If the received BFD Control packet does not contain an 1087 Authentication Section, or the Auth Type is not correct (2 for 1088 Keyed MD5, or 3 for Meticulous Keyed MD5), then the received 1089 packet MUST be discarded. 1091 If the Auth Key ID field does not match the ID of a configured 1092 authentication key, the received packet MUST be discarded. 1094 If the Auth Len field is not equal to 24, the packet MUST be 1095 discarded. 1097 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1098 Keyed MD5, if the Sequence Number lies outside of the range of 1099 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1100 treated as an unsigned 32 bit circular number space), the received 1101 packet MUST be discarded. For Meticulous Keyed MD5, if the 1102 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1103 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1104 unsigned 32 bit circular number space, the received packet MUST be 1105 discarded. 1107 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1108 1, bfd.RcvAuthSeq MUST be set to the value of the received 1109 Sequence Number field. 1111 Replace the contents of the Auth Key/Digest field with the 1112 authentication key selected by the received Auth Key ID field. If 1113 the MD5 digest of the entire BFD Control packet is equal to the 1114 received value of the Auth Key/Digest field, the received packet 1115 MUST be accepted. Otherwise (the digest does not match the Auth 1116 Key/Digest field) the received packet MUST be discarded. 1118 6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1120 The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms 1121 are very similar to those used in other protocols. In these methods 1122 of authentication, one or more secret keys (with corresponding Key 1123 IDs) are configured in each system. One of the Keys is included in a 1124 SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but 1125 the Key itself is not carried in the packet. To help avoid replay 1126 attacks, a sequence number is also carried in each packet. For Keyed 1127 SHA1, the sequence number is occasionally incremented. For 1128 Meticulous Keyed SHA1, the sequence number is incremented on every 1129 packet. 1131 The receiving system accepts the packet if the Key ID matches one of 1132 the configured Keys, a SHA1 hash including the selected key matches 1133 that carried in the packet, and if the sequence number is greater 1134 than or equal to the last sequence number received (for Keyed SHA1), 1135 or strictly greater than the last sequence number received (for 1136 Meticulous Keyed SHA1.) 1138 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 1139 Authentication 1141 The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous 1142 Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key 1143 ID field MUST be set to the ID of the current authentication key. 1144 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1146 The authentication key value is a binary string of 20 bytes, and 1147 MUST be placed into the Auth Key/Hash field. All implementations 1148 MUST support the configuration of any arbitrary binary string to 1149 ensure interoperability. Other configuration methods MAY be 1150 supported. 1152 A SHA1 hash MUST be calculated over the entire BFD control packet. 1153 The resulting hash MUST be stored in the Auth Key/Hash field prior 1154 to transmission (replacing the secret key, which MUST NOT be 1155 carried in the packet.) 1157 For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular 1158 fashion (when treated as an unsigned 32 bit value.) 1159 bfd.XmitAuthSeq SHOULD be incremented when the session state 1160 changes, or when the transmitted BFD Control packet carries 1161 different contents than the previously transmitted packet. The 1162 decision as to when to increment bfd.XmitAuthSeq is outside the 1163 scope of this specification. See the section entitled "Security 1164 Considerations" below for a discussion. 1166 For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in 1167 a circular fashion (when treated as an unsigned 32 bit value.) 1169 Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1171 If the received BFD Control packet does not contain an 1172 Authentication Section, or the Auth Type is not correct (4 for 1173 Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received 1174 packet MUST be discarded. 1176 If the Auth Key ID field does not match the ID of a configured 1177 authentication key, the received packet MUST be discarded. 1179 If the Auth Len field is not equal to 28, the packet MUST be 1180 discarded. 1182 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1183 Keyed SHA1, if the Sequence Number lies outside of the range of 1184 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1185 treated as an unsigned 32 bit circular number space), the received 1186 packet MUST be discarded. For Meticulous Keyed SHA1, if the 1187 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1188 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1189 unsigned 32 bit circular number space, the received packet MUST be 1190 discarded. 1192 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1193 1, bfd.RcvAuthSeq MUST be set to the value of the received 1194 Sequence Number field, and the received packet MUST be accepted. 1196 Replace the contents of the Auth Key/Hash field with the 1197 authentication key selected by the received Auth Key ID field. If 1198 the SHA1 hash of the entire BFD Control packet is equal to the 1199 received value of the Auth Key/Hash field, the received packet 1200 MUST be accepted. Otherwise (the hash does not match the Auth 1201 Key/Hash field) the received packet MUST be discarded. 1203 6.8. Functional Specifics 1205 The following section of this specification is normative. The means 1206 by which this specification is achieved is outside the scope of this 1207 specification. 1209 When a system is said to have "the Echo function active," it means 1210 that the system is sending BFD Echo packets, implying that the 1211 session is Up and the other system has signaled its willingness to 1212 loop back Echo packets. 1214 When the local system is said to have "Demand mode active," it means 1215 that bfd.DemandMode is 1 in the local system (see section 6.8.1), the 1216 session is Up, and the remote system is signaling that the session is 1217 in state Up. 1219 When the remote system is said to have "Demand mode active," it means 1220 that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D) 1221 bit in the last received BFD Control packet), the session is Up, and 1222 the remote system is signaling that the session is in state Up. 1224 6.8.1. State Variables 1226 A minimum amount of information about a session needs to be tracked 1227 in order to achieve the elements of procedure described here. The 1228 following is a set of state variables that are helpful in describing 1229 the mechanisms of BFD. Any means of tracking this state may be used 1230 so long as the protocol behaves as described. 1232 When the text refers to initializing a state variable, this takes 1233 place only at the time that the session (and the corresponding state 1234 variables) is created. The state variables are subsequently 1235 manipulated by the state machine and are never reinitialized, even if 1236 the session fails and is reestablished. 1238 Once session state is created, and at least one BFD Control packet is 1239 received from the remote end, it MUST be preserved for at least one 1240 Detection Time (see section 6.8.4) subsequent to the receipt of the 1241 last BFD Control packet, regardless of the session state. This 1242 preserves timing parameters in case the session flaps. A system MAY 1243 preserve session state longer than this. The preservation or 1244 destruction of session state when no BFD Control packets for this 1245 session have been received from the remote system is outside the 1246 scope of this specification. 1248 All state variables in this specification are of the form "bfd.Xx" 1249 and should not be confused with fields carried in the protocol 1250 packets, which are always spelled out to match the names in section 1251 4. 1253 bfd.SessionState 1255 The perceived state of the session (Init, Up, Down, or 1256 AdminDown.) The exact action taken when the session state 1257 changes is outside the scope of this specification, though it 1258 is expected that this state change (particularly to and from Up 1259 state) is reported to other components of the system. This 1260 variable MUST be initialized to Down. 1262 bfd.RemoteSessionState 1264 The session state last reported by the remote system in the 1265 State (Sta) field of the BFD Control packet. This variable 1266 MUST be initialized to Down. 1268 bfd.LocalDiscr 1270 The local discriminator for this BFD session, used to uniquely 1271 identify it. It MUST be unique across all BFD sessions on this 1272 system, and nonzero. It SHOULD be set to a random (but still 1273 unique) value to improve security. The value is otherwise 1274 outside the scope of this specification. 1276 bfd.RemoteDiscr 1278 The remote discriminator for this BFD session. This is the 1279 discriminator chosen by the remote system, and is totally 1280 opaque to the local system. This MUST be initialized to zero. 1281 If a period of a Detection Time passes without the receipt of a 1282 valid, authenticated BFD packet from the remote system, this 1283 variable MUST be set to zero. 1285 bfd.LocalDiag 1287 The diagnostic code specifying the reason for the most recent 1288 change in the local session state. This MUST be initialized to 1289 zero (No Diagnostic.) 1291 bfd.DesiredMinTxInterval 1293 The minimum interval, in microseconds, between transmitted BFD 1294 Control packets that this system would like to use at the 1295 current time, less any jitter applied (see section 6.8.2). The 1296 actual interval is negotiated between the two systems. This 1297 MUST be initialized to a value of at least one second 1298 (1,000,000 microseconds) according to the rules described in 1299 section 6.8.3. The setting of this variable is otherwise 1300 outside the scope of this specification. 1302 bfd.RequiredMinRxInterval 1304 The minimum interval, in microseconds, between received BFD 1305 Control packets that this system requires, less any jitter 1306 applied by the sender (see section 6.8.2). The setting of this 1307 variable is outside the scope of this specification. A value 1308 of zero means that this system does not want to receive any 1309 periodic BFD Control packets. See section 6.8.18 for details. 1311 bfd.RemoteMinRxInterval 1313 The last value of Required Min RX Interval received from the 1314 remote system in a BFD Control packet. This variable MUST be 1315 initialized to 1. 1317 bfd.DemandMode 1319 Set to 1 if the local system wishes to use Demand mode, or 0 if 1320 not. 1322 bfd.RemoteDemandMode 1324 Set to 1 if the remote system wishes to use Demand mode, or 0 1325 if not. This is the value of the Demand (D) bit in the last 1326 received BFD Control packet. This variable MUST be initialized 1327 to zero. 1329 bfd.DetectMult 1331 The desired Detection Time multiplier for BFD Control packets 1332 on the local system. The negotiated Control packet 1333 transmission interval, multiplied by this variable, will be the 1334 Detection Time for this session (as seen by the remote system.) 1335 This variable MUST be a nonzero integer, and is otherwise 1336 outside the scope of this specification. See section 6.8.4 for 1337 further information. 1339 bfd.AuthType 1341 The authentication type in use for this session, as defined in 1342 section 4.1, or zero if no authentication is in use. 1344 bfd.RcvAuthSeq 1346 A 32 bit unsigned integer containing the last sequence number 1347 for keyed MD5 or SHA1 authentication that was received. The 1348 initial value is unimportant. 1350 bfd.XmitAuthSeq 1352 A 32 bit unsigned integer containing the next sequence number 1353 for keyed MD5 or SHA1 authentication to be transmitted. This 1354 variable MUST be initialized to a random 32 bit value. 1356 bfd.AuthSeqKnown 1358 Set to 1 if the next sequence number for keyed MD5 or SHA1 1359 authentication expected to be received is known, or 0 if it is 1360 not known. This variable MUST be initialized to zero. 1362 This variable MUST be set to zero after no packets have been 1363 received on this session for at least twice the Detection Time. 1364 This ensures that the sequence number can be resynchronized if 1365 the remote system restarts. 1367 6.8.2. Timer Negotiation 1369 The time values used to determine BFD packet transmission intervals 1370 and the session Detection Time are continuously negotiated, and thus 1371 may be changed at any time. The negotiation and time values are 1372 independent in each direction for each session. 1374 Each system reports in the BFD Control packet how rapidly it would 1375 like to transmit BFD packets, as well as how rapidly it is prepared 1376 to receive them. This allows either system to unilaterally determine 1377 the maximum packet rate (minimum interval) in both directions. 1379 See section 6.8.7 for the details of packet transmission timing and 1380 negotiation. 1382 6.8.3. Timer Manipulation 1384 The time values used to determine BFD packet transmission intervals 1385 and the session Detection Time may be modified at any time without 1386 affecting the state of the session. When the timer parameters are 1387 changed for any reason, the requirements of this section apply. 1389 If either bfd.DesiredMinTxInterval is changed or 1390 bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be 1391 initiated (see section 6.5). If the timing is such that a system 1392 receiving a Poll Sequence wishes to change the parameters described 1393 in this paragraph, the new parameter values MAY be carried in packets 1394 with the Final (F) bit set, even if the Poll Sequence has not yet 1395 been sent. 1397 If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, 1398 the actual transmission interval used MUST NOT change until the Poll 1399 Sequence described above has terminated. This is to ensure that the 1400 remote system updates its Detection Time before the transmission 1401 interval increases. 1403 If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, 1404 the previous value of bfd.RequiredMinRxInterval MUST be used when 1405 calculating the Detection Time for the remote system until the Poll 1406 Sequence described above has terminated. This is to ensure that the 1407 remote system is transmitting packets at the higher rate (and those 1408 packets are being received) prior to the Detection Time being 1409 reduced. 1411 When bfd.SessionState is not Up, the system MUST set 1412 bfd.DesiredMinTxInterval to a value of not less than one second 1413 (1,000,000 microseconds.) This is intended to ensure that the 1414 bandwidth consumed by BFD sessions that are not Up is negligible, 1415 particularly in the case where a neighbor may not be running BFD. 1417 If the local system reduces its transmit interval due to 1418 bfd.RemoteMinRxInterval being reduced (the remote system has 1419 advertised a reduced value in Required Min RX Interval), and the 1420 remote system is not in Demand mode, the local system MUST honor the 1421 new interval immediately. In other words, the local system cannot 1422 wait longer than the new interval between the previous packet 1423 transmission and the next one. If this interval has already passed 1424 since the last transmission (because the new interval is 1425 significantly shorter), the local system MUST send the next periodic 1426 BFD Control packet as soon as practicable. 1428 When the Echo function is active, a system SHOULD set 1429 bfd.RequiredMinRxInterval to a value of not less than one second 1430 (1,000,000 microseconds.) This is intended to keep received BFD 1431 Control traffic at a negligible level, since the actual detection 1432 function is being performed using BFD Echo packets. 1434 In any case other than those explicitly called out above, timing 1435 parameter changes MUST be effected immediately (changing the 1436 transmission rate and/or the Detection Time). 1438 Note that the Poll Sequence mechanism is ambiguous if more than one 1439 parameter change is made that would require its use, and those 1440 multiple changes are spread across multiple packets (since the 1441 semantics of the returning Final are unclear.) Therefore, if 1442 multiple changes are made that require the use of a Poll Sequence, 1443 there are three choices: 1) they MUST be communicated in a single 1444 BFD Control packet (so the semantics of the Final reply are clear), 1445 or 2) sufficient time must have transpired since the Poll Sequence 1446 was completed to disambiguate the situation (at least a round trip 1447 time since the last Poll was transmitted) prior to the initiation of 1448 another Poll Sequence, or 3) an additional BFD Control packet with 1449 the Final (F) bit *clear* MUST be received after the Poll Sequence 1450 has completed prior to the initiation of another Poll Sequence (this 1451 option is not available when Demand mode is active.) 1453 6.8.4. Calculating the Detection Time 1455 The Detection Time (the period of time without receiving BFD packets 1456 after which the session is determined to have failed) is not carried 1457 explicitly in the protocol. Rather, it is calculated independently 1458 in each direction by the receiving system based on the negotiated 1459 transmit interval and the detection multiplier. Note that there may 1460 be different Detection Times in each direction. 1462 The calculation of the Detection Time is slightly different when in 1463 Demand mode versus Asynchronous mode. 1465 In Asynchronous mode, the Detection Time calculated in the local 1466 system is equal to the value of Detect Mult received from the remote 1467 system, multiplied by the agreed transmit interval of the remote 1468 system (the greater of bfd.RequiredMinRxInterval and the last 1469 received Desired Min TX Interval.) The Detect Mult value is (roughly 1470 speaking, due to jitter) the number of packets that have to be missed 1471 in a row to declare the session to be down. 1473 If Demand mode is not active, and a period of time equal to the 1474 Detection Time passes without receiving a BFD Control packet from the 1475 remote system, and bfd.SessionState is Init or Up, the session has 1476 gone down--the local system MUST set bfd.SessionState to Down and 1477 bfd.LocalDiag to 1 (Control Detection Time Expired.) 1479 In Demand mode, the Detection Time calculated in the local system is 1480 equal to bfd.DetectMult, multiplied by the agreed transmit interval 1481 of the local system (the greater of bfd.DesiredMinTxInterval and 1482 bfd.RemoteMinRxInterval.) bfd.DetectMult is (roughly speaking, due 1483 to jitter) the number of packets that have to be missed in a row to 1484 declare the session to be down. 1486 If Demand mode is active, and a period of time equal to the Detection 1487 Time passes after the initiation of a Poll Sequence (the transmission 1488 of the first BFD Control packet with the Poll bit set), the session 1489 has gone down--the local system MUST set bfd.SessionState to Down, 1490 and bfd.LocalDiag to 1 (Control Detection Time Expired.) 1492 (Note that a packet is considered to have been received, for the 1493 purposes of Detection Time expiration, only if it has not been 1494 "discarded" according to the rules of section 6.8.6.) 1496 6.8.5. Detecting Failures with the Echo Function 1498 When the Echo function is active and a sufficient number of Echo 1499 packets have not arrived as they should, the session has gone 1500 down--the local system MUST set bfd.SessionState to Down, and 1501 bfd.LocalDiag to 2 (Echo Function Failed.) 1503 The means by which the Echo function failures are detected is outside 1504 of the scope of this specification. Any means which will detect a 1505 communication failure is acceptable. 1507 6.8.6. Reception of BFD Control Packets 1509 When a BFD Control packet is received, the following procedure MUST 1510 be followed, in the order specified. If the packet is discarded 1511 according to these rules, processing of the packet MUST cease at that 1512 point. 1514 If the version number is not correct (1), the packet MUST be 1515 discarded. 1517 If the Length field is less than the minimum correct value (24 if 1518 the A bit is clear, or 26 if the A bit is set), the packet MUST be 1519 discarded. 1521 If the Length field is greater than the payload of the 1522 encapsulating protocol, the packet MUST be discarded. 1524 If the Detect Mult field is zero, the packet MUST be discarded. 1526 If the Multipoint (M) bit is nonzero, the packet MUST be 1527 discarded. 1529 If the My Discriminator field is zero, the packet MUST be 1530 discarded. 1532 If the Your Discriminator field is nonzero, it MUST be used to 1533 select the session with which this BFD packet is associated. If 1534 no session is found, the packet MUST be discarded. 1536 If the Your Discriminator field is zero and the State field is not 1537 Down or AdminDown, the packet MUST be discarded. 1539 If the Your Discriminator field is zero, the session MUST be 1540 selected based on some combination of other fields, possibly 1541 including source addressing information, the My Discriminator 1542 field, and the interface over which the packet was received. The 1543 exact method of selection is application-specific and is thus 1544 outside the scope of this specification. If a matching session is 1545 not found, a new session MAY be created, or the packet MAY be 1546 discarded. This choice is outside the scope of this 1547 specification. 1549 If the A bit is set and no authentication is in use (bfd.AuthType 1550 is zero), the packet MUST be discarded. 1552 If the A bit is clear and authentication is in use (bfd.AuthType 1553 is nonzero), the packet MUST be discarded. 1555 If the A bit is set, the packet MUST be authenticated under the 1556 rules of section 6.7, based on the authentication type in use 1557 (bfd.AuthType.) This may cause the packet to be discarded. 1559 Set bfd.RemoteDiscr to the value of My Discriminator. 1561 Set bfd.RemoteState to the value of the State (Sta) field. 1563 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 1565 Set bfd.RemoteMinRxInterval to the value of Required Min RX 1566 Interval. 1568 If the Required Min Echo RX Interval field is zero, the 1569 transmission of Echo packets, if any, MUST cease. 1571 If a Poll Sequence is being transmitted by the local system and 1572 the Final (F) bit in the received packet is set, the Poll Sequence 1573 MUST be terminated. 1575 Update the transmit interval as described in section 6.8.2. 1577 Update the Detection Time as described in section 6.8.4. 1579 If bfd.SessionState is AdminDown 1580 Discard the packet 1582 If received state is AdminDown 1583 If bfd.SessionState is not Down 1584 Set bfd.LocalDiag to 3 (Neighbor signaled 1585 session down) 1586 Set bfd.SessionState to Down 1588 Else 1590 If bfd.SessionState is Down 1591 If received State is Down 1592 Set bfd.SessionState to Init 1593 Else if received State is Init 1594 Set bfd.SessionState to Up 1596 Else if bfd.SessionState is Init 1597 If received State is Init or Up 1598 Set bfd.SessionState to Up 1600 Else (bfd.SessionState is Up) 1601 If received State is Down 1602 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1603 Set bfd.SessionState to Down 1605 Check to see if Demand mode should become active or not (see 1606 section 6.6). 1608 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and 1609 bfd.RemoteSessionState is Up, Demand mode is active on the remote 1610 system and the local system MUST cease the periodic transmission 1611 of BFD Control packets (see section 6.8.7.) 1613 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 1614 bfd.RemoteSessionState is not Up, Demand mode is not active on the 1615 remote system and the local system MUST send periodic BFD Control 1616 packets (see section 6.8.7.) 1618 If the Poll (P) bit is set, send a BFD Control packet to the 1619 remote system with the Poll (P) bit clear, and the Final (F) bit 1620 set (see section 6.8.7.) 1622 If the packet was not discarded, it has been received for purposes 1623 of the Detection Time expiration rules in section 6.8.4. 1625 6.8.7. Transmitting BFD Control Packets 1627 With the exceptions listed in the remainder of this section, a system 1628 MUST NOT transmit BFD Control packets at an interval less than the 1629 larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less 1630 applied jitter (see below). In other words, the system reporting the 1631 slower rate determines the transmission rate. 1633 The periodic transmission of BFD Control packets MUST be jittered on 1634 a per-packet basis by up to 25%, that is, the interval MUST be 1635 reduced by a random value of 0 to 25%, in order to avoid self- 1636 synchronization with other systems on the same subnetwork. Thus, the 1637 average interval between packets will be roughly 12.5% less than that 1638 negotiated. 1640 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 1641 Control packets MUST be no more than 90% of the negotiated 1642 transmission interval, and MUST be no less than 75% of the negotiated 1643 transmission interval. This is to ensure that, on the remote system, 1644 the calculated Detection Time does not pass prior to the receipt of 1645 the next BFD Control packet. 1647 The transmit interval MUST be recalculated whenever 1648 bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval 1649 changes, and is equal to the greater of those two values. See 1650 sections 6.8.2 and 6.8.3 for details on transmit timers. 1652 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 1653 zero and the system is taking the Passive role. 1655 A system MUST NOT periodically transmit BFD Control packets if 1656 bfd.RemoteMinRxInterval is zero. 1658 A system MUST NOT periodically transmit BFD Control packets if Demand 1659 mode is active on the remote system (bfd.RemoteDemandMode is 1, 1660 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 1661 Sequence is not being transmitted. 1663 If a BFD Control packet is received with the Poll (P) bit set to 1, 1664 the receiving system MUST transmit a BFD Control packet with the Poll 1665 (P) bit clear and the Final (F) bit set as soon as practicable, 1666 without respect to the transmission timer or any other transmission 1667 limitations, without respect to the session state, and without 1668 respect to whether Demand mode is active on either system. A system 1669 MAY limit the rate at which such packets are transmitted. If rate 1670 limiting is in effect, the advertised value of Desired Min TX 1671 Interval MUST be greater than or equal to the interval between 1672 transmitted packets imposed by the rate limiting function. 1674 A system MUST NOT set the Demand (D) bit unless bfd.DemandMode is 1, 1675 bfd.SessionState is Up, and bfd.RemoteSessionState is Up. 1677 A BFD Control packet SHOULD be transmitted during the interval 1678 between periodic Control packet transmissions when the contents of 1679 that packet would differ from that in the previously transmitted 1680 packet (other than the Poll and Final bits) in order to more rapidly 1681 communicate a change in state. 1683 The contents of transmitted BFD Control packets MUST be set as 1684 follows: 1686 Version 1688 Set to the current version number (1). 1690 Diagnostic (Diag) 1692 Set to bfd.LocalDiag. 1694 State (Sta) 1696 Set to the value indicated by bfd.SessionState. 1698 Poll (P) 1700 Set to 1 if the local system is sending a Poll Sequence, or 0 if 1701 not. 1703 Final (F) 1705 Set to 1 if the local system is responding to a Control packet 1706 received with the Poll (P) bit set, or 0 if not. 1708 Control Plane Independent (C) 1710 Set to 1 if the local system's BFD implementation is independent 1711 of the control plane (it can continue to function through a 1712 disruption of the control plane.) 1714 Authentication Present (A) 1716 Set to 1 if authentication is in use on this session (bfd.AuthType 1717 is nonzero), or 0 if not. 1719 Demand (D) 1721 Set to bfd.DemandMode if bfd.SessionState is Up and 1722 bfd.RemoteSessionState is Up. Otherwise it is set to 0. 1724 Multipoint (M) 1726 Set to 0. 1728 Detect Mult 1730 Set to bfd.DetectMult. 1732 Length 1734 Set to the appropriate length, based on the fixed header length 1735 (24) plus any Authentication Section. 1737 My Discriminator 1739 Set to bfd.LocalDiscr. 1741 Your Discriminator 1743 Set to bfd.RemoteDiscr. 1745 Desired Min TX Interval 1747 Set to bfd.DesiredMinTxInterval. 1749 Required Min RX Interval 1751 Set to bfd.RequiredMinRxInterval. 1753 Required Min Echo RX Interval 1755 Set to the minimum required Echo packet receive interval for this 1756 session. If this field is set to zero, the local system is 1757 unwilling or unable to loop back BFD Echo packets to the remote 1758 system, and the remote system will not send Echo packets. 1760 Authentication Section 1762 Included and set according to the rules in section 6.7 if 1763 authentication is in use (bfd.AuthType is nonzero.) Otherwise 1764 this section is not present. 1766 6.8.8. Reception of BFD Echo Packets 1768 A received BFD Echo packet MUST be demultiplexed to the appropriate 1769 session for processing. A means of detecting missing Echo packets 1770 MUST be implemented, which most likely involves processing of the 1771 Echo packets that are received. The processing of received Echo 1772 packets is otherwise outside the scope of this specification. 1774 6.8.9. Transmission of BFD Echo Packets 1776 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 1777 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 1778 Control packet received from the remote system contains a nonzero 1779 value in Required Min Echo RX Interval. 1781 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 1782 interval between transmitted BFD Echo packets MUST NOT be less than 1783 the value advertised by the remote system in Required Min Echo RX 1784 Interval, except as follows: 1786 A 25% jitter MAY be applied to the rate of transmission, such that 1787 the actual interval MAY be between 75% and 100% of the advertised 1788 value. A single BFD Echo packet MAY be transmitted between 1789 normally scheduled Echo transmission intervals. 1791 The transmission of BFD Echo packets is otherwise outside the scope 1792 of this specification. 1794 6.8.10. Min Rx Interval Change 1796 When it is desired to change the rate at which BFD Control packets 1797 arrive from the remote system, bfd.RequiredMinRxInterval can be 1798 changed at any time to any value. The new value will be transmitted 1799 in the next outgoing Control packet, and the remote system will 1800 adjust accordingly. See section 6.8.3 for further requirements. 1802 6.8.11. Min Tx Interval Change 1804 When it is desired to change the rate at which BFD Control packets 1805 are transmitted to the remote system (subject to the requirements of 1806 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1807 any time to any value. The rules in section 6.8.3 apply. 1809 6.8.12. Detect Multiplier Change 1811 When it is desired to change the detect multiplier, the value of 1812 bfd.DetectMult can be changed to any nonzero value. The new value 1813 will be transmitted with the next BFD Control packet, and the use of 1814 a Poll Sequence is not necessary. See section 6.6 for additional 1815 requirements. 1817 6.8.13. Enabling or Disabling The Echo Function 1819 If it is desired to start or stop the transmission of BFD Echo 1820 packets, this MAY be done at any time (subject to the transmission 1821 requirements detailed in section 6.8.9.) 1823 If it is desired to enable or disable the looping back of received 1824 BFD Echo packets, this MAY be done at any time by changing the value 1825 of Required Min Echo RX Interval to zero or nonzero in outgoing BFD 1826 Control packets. 1828 6.8.14. Enabling or Disabling Demand Mode 1830 If it is desired to start or stop Demand mode, this MAY be done at 1831 any time by setting bfd.DemandMode to the proper value. Demand mode 1832 will subsequently become active under the rules described in section 1833 6.6. 1835 If Demand mode is no longer active on the remote system, the local 1836 system MUST begin transmitting periodic BFD Control packets as 1837 described in section 6.8.7. 1839 6.8.15. Forwarding Plane Reset 1841 When the forwarding plane in the local system is reset for some 1842 reason, such that the remote system can no longer rely on the local 1843 forwarding state, the local system MUST set bfd.LocalDiag to 4 1844 (Forwarding Plane Reset), and set bfd.SessionState to Down. 1846 6.8.16. Administrative Control 1848 There may be circumstances where it is desirable to administratively 1849 enable or disable a BFD session. When this is desired, the following 1850 procedure MUST be followed: 1852 If enabling session 1853 Set bfd.SessionState to Down 1855 Else 1856 Set bfd.SessionState to AdminDown 1857 Set bfd.LocalDiag to an appropriate value 1858 Cease the transmission of BFD Echo packets 1860 If signaling is received from outside BFD that the underlying path 1861 has failed, an implementation MAY administratively disable the 1862 session with the diagnostic Path Down. 1864 Other scenarios MAY use the diagnostic Administratively Down. 1866 BFD Control packets SHOULD be transmitted for at least a Detection 1867 Time after transitioning to AdminDown state in order to ensure that 1868 the remote system is aware of the state change. BFD Control packets 1869 MAY be transmitted indefinitely after transitioning to AdminDown 1870 state in order to maintain session state in each system (see section 1871 6.8.18 below.) 1873 6.8.17. Concatenated Paths 1875 If the path being monitored by BFD is concatenated with other paths 1876 (connected end-to-end in series), it may be desirable to propagate 1877 the indication of a failure of one of those paths across the BFD 1878 session (providing an interworking function for liveness monitoring 1879 between BFD and other technologies.) 1881 Two diagnostic codes are defined for this purpose: Concatenated Path 1882 Down and Reverse Concatenated Path Down. The first propagates 1883 forward path failures (in which the concatenated path fails in the 1884 direction toward the interworking system), and the second propagates 1885 reverse path failures (in which the concatenated path fails in the 1886 direction away from the interworking system, assuming a bidirectional 1887 link.) 1889 A system MAY signal one of these failure states by simply setting 1890 bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD 1891 session is not taken down. If Demand mode is not active on the 1892 remote system, no other action is necessary, as the diagnostic code 1893 will be carried via the periodic transmission of BFD Control packets. 1894 If Demand mode is active on the remote system (the local system is 1895 not transmitting periodic BFD Control packets), a Poll Sequence MUST 1896 be initiated to ensure that the diagnostic code is transmitted. Note 1897 that if the BFD session subsequently fails, the diagnostic code will 1898 be overwritten with a code detailing the cause of the failure. It is 1899 up to the interworking agent to perform the above procedure again, 1900 once the BFD session reaches Up state, if the propagation of the 1901 concatenated path failure is to resume. 1903 6.8.18. Holding Down Sessions 1905 A system MAY choose to prevent a BFD session from being established. 1906 One possible reason might be to manage the rate at which sessions are 1907 established. This can be done by holding the session in Down or 1908 AdminDown state, as appropriate. 1910 There are two related mechanisms that are available to help with this 1911 task. First, a system is REQUIRED to maintain session state 1912 (including timing parameters), even when a session is down, until a 1913 Detection Time has passed without the receipt of any BFD Control 1914 packets. This means that a system may take down a session and 1915 transmit an arbitrarily large value in the Required Min RX Interval 1916 field to control the rate at which it receives packets. 1918 Additionally, a system MAY transmit a value of zero for Required Min 1919 RX Interval to indicate that the remote system should send no packets 1920 whatsoever. 1922 So long as the local system continues to transmit BFD Control 1923 packets, the remote system is obligated to obey the value carried in 1924 Required Min RX Interval. If the remote system does not receive any 1925 BFD Control packets for a Detection Time, it SHOULD reset 1926 bfd.RemoteMinRxInterval to its initial value of 1 (per section 6.8.1, 1927 since it is no longer required to maintain previous session state) 1928 and then can transmit at its own rate. 1930 7. Operational Considerations 1932 BFD is likely to be deployed as a critical part of network 1933 infrastructure. As such, care should be taken to avoid disruption. 1935 Obviously, any mechanism that blocks BFD packets, such as firewalls 1936 or other policy processes, will cause BFD to fail. 1938 Mechanisms that control packet scheduling, such as policers, traffic 1939 shapers, priority queueing, etc., have the potential of impacting BFD 1940 operations if the Detection Time is similar in scale to the scheduled 1941 packet transmit or receive rate. The delivery of BFD packets is 1942 time-critical, relative to the magnitude of the Detection Time, so 1943 this may need to be taken into account in implementation and 1944 deployment, particularly when very short Detection Times are to be 1945 used. 1947 When BFD is used across multiple hops, a congestion control mechanism 1948 MUST be implemented, and when congestion is detected, the BFD 1949 implementation MUST reduce the amount of traffic it generates. The 1950 exact mechanism used is outside the scope of this specification, and 1951 the requirements of this mechanism may differ depending on how BFD is 1952 deployed, and how it interacts with other parts of the system (for 1953 example, exponential backoff may not be appropriate in cases where 1954 routing protocols are interacting closely with BFD.) 1956 Note that "congestion" is not only a traffic phenomenon, but also a 1957 computational one. It is possible for systems with a large number of 1958 BFD sessions and/or very short packet intervals to become CPU-bound. 1959 As such, a congestion control algorithm SHOULD be used even across 1960 single hops in order to avoid the possibility of catastrophic system 1961 collapse, as such failures have been seen repeatedly in other 1962 periodic hello-based protocols. 1964 The mechanisms for detecting congestion are outside the scope of this 1965 specification, but may include the detection of lost BFD Control 1966 packets (by virtue of holes in the authentication sequence number 1967 space, or by BFD session failure) or other means. 1969 The mechanisms for reducing BFD's traffic load are the control of the 1970 local and remote packet transmission rate via the Min RX Interval and 1971 Min TX Interval fields. 1973 Note that any mechanism that increases the transmit or receive 1974 intervals will increase the Detection Time for the session. 1976 It is worth noting that a single BFD session does not consume a large 1977 amount of bandwidth. An aggressive session that achieves a detection 1978 time of 50 milliseconds, by using a transmit interval of 16.7 1979 milliseconds and a detect multiplier of 3, will generate 60 packets 1980 per second. The maximum length of each packet on the wire is on the 1981 order of 100 bytes, for a total of around 48 kilobits per second of 1982 bandwidth consumption in each direction. 1984 8. IANA Considerations 1986 This document defines two registries to be administered by IANA. The 1987 first is entitled "BFD Diagnostic Codes" (see section 4.1). Initial 1988 values for the BFD Diagnostic Code registry are given below. Further 1989 assignments are to be made through Expert Review [IANA- 1990 CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name 1991 and its associated value. 1993 Value BFD Diagnostic Code Name 1994 ----- ------------------------ 1995 0 No Diagnostic 1996 1 Control Detection Time Expired 1997 2 Echo Function Failed 1998 3 Neighbor Signaled Session Down 1999 4 Forwarding Plane Reset 2000 5 Path Down 2001 6 Concatenated Path Down 2002 7 Administratively Down 2003 8 Reverse Concatenated Path Down 2004 9-31 Unassigned 2006 The second registry is entitled "BFD Authentication Types" (see section 2007 4.1). Initial values for the BFD Authentication Type registry are given 2008 below. Further assignments are to be made through Expert Review 2009 [IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type 2010 Code name and its associated value. 2012 Value BFD Authentication Type Name 2013 ----- ---------------------------- 2014 0 Reserved 2015 1 Simple Password 2016 2 Keyed MD5 2017 3 Meticulous Keyed MD5 2018 4 Keyed SHA1 2019 5 Meticulous Keyed SHA1 2020 6-255 Unassigned 2022 9. Security Considerations 2024 As BFD may be tied into the stability of the network infrastructure 2025 (such as routing protocols), the effects of an attack on a BFD 2026 session may be very serious: a link may be falsely declared to be 2027 down, or falsely declared to be up; in either case, the effect is 2028 denial-of-service. 2030 An attacker who is in complete control of the link between the 2031 systems can easily drop all BFD packets but forward everything else 2032 (causing the link to be falsely declared down), or forward only the 2033 BFD packets but nothing else (causing the link to be falsely declared 2034 up). This attack cannot be prevented by BFD. 2036 To mitigate threats from less capable attackers, BFD specifies two 2037 mechanisms to prevent spoofing of BFD Control packets. The 2038 Generalized TTL Security Mechanism [GTSM] uses the TTL or Hop Count 2039 to prevent off-link attackers from spoofing packets. The 2040 Authentication Section authenticates the BFD Control packets. These 2041 mechanisms are described in more detail below. 2043 When a BFD session is directly connected across a single link 2044 (physical, or a secure tunnel such as IPsec), the TTL or Hop Count 2045 MUST be set to the maximum on transmit, and checked to be equal to 2046 the maximum value on reception (and the packet dropped if this is not 2047 the case.) See [GTSM] for more information on this technique. If 2048 BFD is run across multiple hops or an insecure tunnel (such as GRE), 2049 the Authentication Section SHOULD be utilized. 2051 The level of security provided by the Authentication Section varies 2052 based on the authentication type used. Simple Password 2053 authentication is obviously only as secure as the secrecy of the 2054 passwords used, and should be considered only if the BFD session is 2055 guaranteed to be run over an infrastructure not subject to packet 2056 interception. Its chief advantage is that it minimizes the 2057 computational effort required for authentication. 2059 Keyed MD5 authentication is much stronger than Simple Password 2060 authentication since the keys cannot be discerned by intercepting 2061 packets. It is vulnerable to replay attacks in between increments of 2062 the sequence number. The sequence number can be incremented as 2063 seldom (or as often) as desired, trading off resistance to replay 2064 attacks with the computational effort required for authentication. 2066 Meticulous Keyed MD5 authentication is stronger yet, as it requires 2067 the sequence number to be incremented for every packet. Replay 2068 attack vulnerability is reduced due to the requirement that the 2069 sequence number must be incremented on every packet, the window size 2070 of acceptable packets is small, and the initial sequence number is 2071 randomized. There is still a window of attack at the beginning of 2072 the session while the sequence number is being determined. This 2073 authentication scheme requires an MD5 calculation on every packet 2074 transmitted and received. 2076 Using SHA1 is believed to have stronger security properties than MD5. 2077 All comments about MD5 in this section also apply to SHA1. 2079 Both Keyed MD5/SHA1 and Meticulous Keyed MD5/SHA1 use the "secret 2080 suffix" construction (also called "append only") in which the shared 2081 secret key is appended to the data before calculating the hash, 2082 instead of the more common HMAC construction [HMAC]. This 2083 construction is believed to be appropriate for BFD, but designers of 2084 any additional authentication mechanisms for BFD are encouraged to 2085 read [HMAC] and its references. 2087 If both systems randomize their Local Discriminator values at the 2088 beginning of a session, replay attacks may be further mitigated, 2089 regardless of the authentication type in use. Since the Local 2090 Discriminator may be changed at any time during a session, this 2091 mechanism may also help mitigate attacks. 2093 The security implications of the use of BFD Echo packets are 2094 dependent on how those packets are defined, since their structure is 2095 local to the transmittiong system and outside the scope of this 2096 specification. The risks are essentially the same as those of BFD 2097 Control packets. [GTSM] could be applied in this case, though the 2098 TTL/Hop Count will be decremented by 1 in the course of echoing the 2099 packet, so spoofing is possible from one hop away. The use of 2100 cryptographic authentication can mitigate the risk of spoofing. 2102 10. References 2104 10.1. Normative References 2106 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 2107 (GTSM)", RFC 5082, October 2007. 2109 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 2110 Requirement Levels", RFC 2119, March 1997. 2112 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 2113 1992. 2115 [SHA1] Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, 2116 September 2001. 2118 10.2. Informative References 2120 [HMAC] Krawczyk, H., et al, "HMAC: Keyed-Hashing for Message 2121 Authentication", RFC 2104, February, 1997. 2123 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 2124 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2125 5226, May 2008. 2127 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 2129 Backward Compatibility (Non-Normative) 2131 Although Version 0 of this document is unlikely to have been deployed 2132 widely, some implementors may wish to have a backward compatibility 2133 mechanism. Note that any mechanism may be potentially used that does 2134 not alter the protocol definition, so interoperability should not be 2135 an issue. 2137 The suggested mechanism described here has the property that it will 2138 converge on version 1 if both systems implement it, even if one 2139 system is upgraded from version 0 within a Detection Time. It will 2140 interoperate with a system that implements only one version (or is 2141 configured to support only one version.) A system should obviously 2142 not perform this function if it is configured to or is only capable 2143 of using a single version. 2145 A BFD session will enter a "negotiation holddown" if it is configured 2146 for automatic versioning and either has just started up, or the 2147 session has been manually cleared. The session is set to AdminDown 2148 state and Version 1. During the holddown period, which lasts for one 2149 Detection Time, the system sends BFD Control packets as usual, but 2150 ignores received packets. After the holddown time is complete, the 2151 state transitions to Down and normal operation resumes. 2153 When a system is not in holddown, if it doing automatic versioning 2154 and is currently using Version 1, if any Version 0 packet is received 2155 for the session, it switches immediately to Version 0. If it is 2156 currently using Version 0 and a Version 1 packet is received that 2157 indicates that the neighbor is in state AdminDown, it switches to 2158 Version 1. If using Version 0 and a Version 1 packet is received 2159 indicating a state other than AdminDown, the packet is ignored (per 2160 spec.) 2161 If the version being used is changed, the session goes down as 2162 appropriate for the new version (Down state for Version 1 or Failing 2163 state for Version 0.) 2165 Contributors 2167 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 2168 significant contributors to this document. 2170 Acknowledgments 2172 This document was inspired by (and is intended to replace) the 2173 Protocol Liveness Protocol draft, written by Kireeti Kompella. 2175 Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 2176 et al. 2178 The authors would also like to thank Mike Shand, John Scudder, 2179 Stewart Bryant, Pekka Savola, Richard Spencer, and Pasi Eronen for 2180 their substantive input. 2182 The authors would also like to thank Owen Wheeler for hosting 2183 teleconferences between the authors of this specification and 2184 multiple vendors in order address implementation and clarity issues. 2186 Authors' Addresses 2188 Dave Katz 2189 Juniper Networks 2190 1194 N. Mathilda Ave. 2191 Sunnyvale, California 94089-1206 USA 2192 Phone: +1-408-745-2000 2193 Email: dkatz@juniper.net 2195 Dave Ward 2196 Juniper Networks 2197 1194 N. Mathilda Ave. 2198 Sunnyvale, California 94089-1206 USA 2199 Phone: +1-408-745-2000 2200 Email: dward@juniper.net 2202 Changes from the Previous Draft 2204 The primary technical change is to make the jitter of transmitted 2205 packets a MUST rather than a SHOULD, in order to make congestion 2206 detection possible. More comprehensive text on congestion control 2207 was added. Configuration requirements for passwords and secret keys 2208 was clarified. Text describing packet transmission was consolidated. 2209 The minimal required authentication was clarified. The requirement 2210 to maintain state after a BFD session failure was clarified. The 2211 Security Considerations section was expanded. All other changes are 2212 purely editorial in nature. 2214 This document expires in July, 2010.