idnits 2.17.1 draft-ietf-bfd-base-11.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 14, 2010) is 5178 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 14, 2010 8 Bidirectional Forwarding Detection 9 draft-ietf-bfd-base-11.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 . . . . . . . . . 38 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 . . . . . . . . . . . . . 42 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 . . . . . . . . . . . . . 43 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 . . . . . . . . . . . . . . . . . . . . . . . . 49 111 10.1 Normative References . . . . . . . . . . . . . . . . . 49 112 10.2 Informative References . . . . . . . . . . . . . . . . 49 113 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 49 114 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 115 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 51 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, padded to 16 bytes with trailing zero bytes if needed. The 562 shared key MUST be encoded and configured to section 6.7.3. 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 padded to a length of 20 bytes with trailing zero bytes if needed. 614 The shared key MUST be encoded and configured to section 6.7.4. 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. For interoperability, the management interface by which 1015 the password is configured MUST accept ASCII strings, and SHOULD 1016 also allow for the configuration of any arbitrary binary string in 1017 hexadecimal form. Other configuration methods MAY be supported. 1019 Reception Using Simple Password Authentication 1021 If the received BFD Control packet does not contain an 1022 Authentication Section, or the Auth Type is not 1 (Simple 1023 Password), then the received packet MUST be discarded. 1025 If the Auth Key ID field does not match the ID of a configured 1026 password, the received packet MUST be discarded. 1028 If the Auth Len field is not equal to the length of the password 1029 selected by the Key ID, plus three, the packet MUST be discarded. 1031 If the Password field does not match the password selected by the 1032 Key ID, the packet MUST be discarded. 1034 Otherwise, the packet MUST be accepted. 1036 6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 1038 The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are 1039 very similar to those used in other protocols. In these methods of 1040 authentication, one or more secret keys (with corresponding Key IDs) 1041 are configured in each system. One of the Keys is included in an MD5 1042 [MD5] digest calculated over the outgoing BFD Control packet, but the 1043 Key itself is not carried in the packet. To help avoid replay 1044 attacks, a sequence number is also carried in each packet. For Keyed 1045 MD5, the sequence number is occasionally incremented. For Meticulous 1046 Keyed MD5, the sequence number is incremented on every packet. 1048 The receiving system accepts the packet if the Key ID matches one of 1049 the configured Keys, an MD5 digest including the selected key matches 1050 that carried in the packet, and if the sequence number is greater 1051 than or equal to the last sequence number received (for Keyed MD5), 1052 or strictly greater than the last sequence number received (for 1053 Meticulous Keyed MD5.) 1055 Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication 1057 The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous 1058 Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key 1059 ID field MUST be set to the ID of the current authentication key. 1060 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1062 The authentication key value is a binary string of up to 16 bytes, 1063 and MUST be placed into the Auth Key/Digest field, padded with 1064 trailing zero bytes as necessary. For interoperability, the 1065 management interface by which the key is configured MUST accept 1066 ASCII strings, and SHOULD also allow for the configuration of any 1067 arbitrary binary string in hexadecimal form. Other configuration 1068 methods MAY be supported. 1070 An MD5 digest MUST be calculated over the entire BFD control 1071 packet. The resulting digest MUST be stored in the Auth 1072 Key/Digest field prior to transmission (replacing the secret key, 1073 which MUST NOT be carried in the packet.) 1075 For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular 1076 fashion (when treated as an unsigned 32 bit value.) 1077 bfd.XmitAuthSeq SHOULD be incremented when the session state 1078 changes, or when the transmitted BFD Control packet carries 1079 different contents than the previously transmitted packet. The 1080 decision as to when to increment bfd.XmitAuthSeq is outside the 1081 scope of this specification. See the section entitled "Security 1082 Considerations" below for a discussion. 1084 For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a 1085 circular fashion (when treated as an unsigned 32 bit value.) 1087 Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication 1089 If the received BFD Control packet does not contain an 1090 Authentication Section, or the Auth Type is not correct (2 for 1091 Keyed MD5, or 3 for Meticulous Keyed MD5), then the received 1092 packet MUST be discarded. 1094 If the Auth Key ID field does not match the ID of a configured 1095 authentication key, the received packet MUST be discarded. 1097 If the Auth Len field is not equal to 24, the packet MUST be 1098 discarded. 1100 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1101 Keyed MD5, if the Sequence Number lies outside of the range of 1102 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1103 treated as an unsigned 32 bit circular number space), the received 1104 packet MUST be discarded. For Meticulous Keyed MD5, if the 1105 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1106 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1107 unsigned 32 bit circular number space, the received packet MUST be 1108 discarded. 1110 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1111 1, bfd.RcvAuthSeq MUST be set to the value of the received 1112 Sequence Number field. 1114 Replace the contents of the Auth Key/Digest field with the 1115 authentication key selected by the received Auth Key ID field. If 1116 the MD5 digest of the entire BFD Control packet is equal to the 1117 received value of the Auth Key/Digest field, the received packet 1118 MUST be accepted. Otherwise (the digest does not match the Auth 1119 Key/Digest field) the received packet MUST be discarded. 1121 6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1123 The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms 1124 are very similar to those used in other protocols. In these methods 1125 of authentication, one or more secret keys (with corresponding Key 1126 IDs) are configured in each system. One of the Keys is included in a 1127 SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but 1128 the Key itself is not carried in the packet. To help avoid replay 1129 attacks, a sequence number is also carried in each packet. For Keyed 1130 SHA1, the sequence number is occasionally incremented. For 1131 Meticulous Keyed SHA1, the sequence number is incremented on every 1132 packet. 1134 The receiving system accepts the packet if the Key ID matches one of 1135 the configured Keys, a SHA1 hash including the selected key matches 1136 that carried in the packet, and if the sequence number is greater 1137 than or equal to the last sequence number received (for Keyed SHA1), 1138 or strictly greater than the last sequence number received (for 1139 Meticulous Keyed SHA1.) 1141 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 1142 Authentication 1144 The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous 1145 Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key 1146 ID field MUST be set to the ID of the current authentication key. 1147 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1149 The authentication key value is a binary string of up to 20 bytes, 1150 and MUST be placed into the Auth Key/Hash field, padding with 1151 trailing zero bytes as necessary. For interoperability, the 1152 management interface by which the key is configured MUST accept 1153 ASCII strings, and SHOULD also allow for the configuration of any 1154 arbitrary binary string in hexadecimal form. Other configuration 1155 methods MAY be supported. 1157 A SHA1 hash MUST be calculated over the entire BFD control packet. 1158 The resulting hash MUST be stored in the Auth Key/Hash field prior 1159 to transmission (replacing the secret key, which MUST NOT be 1160 carried in the packet.) 1162 For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular 1163 fashion (when treated as an unsigned 32 bit value.) 1164 bfd.XmitAuthSeq SHOULD be incremented when the session state 1165 changes, or when the transmitted BFD Control packet carries 1166 different contents than the previously transmitted packet. The 1167 decision as to when to increment bfd.XmitAuthSeq is outside the 1168 scope of this specification. See the section entitled "Security 1169 Considerations" below for a discussion. 1171 For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in 1172 a circular fashion (when treated as an unsigned 32 bit value.) 1174 Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1176 If the received BFD Control packet does not contain an 1177 Authentication Section, or the Auth Type is not correct (4 for 1178 Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received 1179 packet MUST be discarded. 1181 If the Auth Key ID field does not match the ID of a configured 1182 authentication key, the received packet MUST be discarded. 1184 If the Auth Len field is not equal to 28, the packet MUST be 1185 discarded. 1187 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1188 Keyed SHA1, if the Sequence Number lies outside of the range of 1189 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1190 treated as an unsigned 32 bit circular number space), the received 1191 packet MUST be discarded. For Meticulous Keyed SHA1, if the 1192 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1193 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1194 unsigned 32 bit circular number space, the received packet MUST be 1195 discarded. 1197 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1198 1, bfd.RcvAuthSeq MUST be set to the value of the received 1199 Sequence Number field, and the received packet MUST be accepted. 1201 Replace the contents of the Auth Key/Hash field with the 1202 authentication key selected by the received Auth Key ID field. If 1203 the SHA1 hash of the entire BFD Control packet is equal to the 1204 received value of the Auth Key/Hash field, the received packet 1205 MUST be accepted. Otherwise (the hash does not match the Auth 1206 Key/Hash field) the received packet MUST be discarded. 1208 6.8. Functional Specifics 1210 The following section of this specification is normative. The means 1211 by which this specification is achieved is outside the scope of this 1212 specification. 1214 When a system is said to have "the Echo function active," it means 1215 that the system is sending BFD Echo packets, implying that the 1216 session is Up and the other system has signaled its willingness to 1217 loop back Echo packets. 1219 When the local system is said to have "Demand mode active," it means 1220 that bfd.DemandMode is 1 in the local system (see section 6.8.1), the 1221 session is Up, and the remote system is signaling that the session is 1222 in state Up. 1224 When the remote system is said to have "Demand mode active," it means 1225 that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D) 1226 bit in the last received BFD Control packet), the session is Up, and 1227 the remote system is signaling that the session is in state Up. 1229 6.8.1. State Variables 1231 A minimum amount of information about a session needs to be tracked 1232 in order to achieve the elements of procedure described here. The 1233 following is a set of state variables that are helpful in describing 1234 the mechanisms of BFD. Any means of tracking this state may be used 1235 so long as the protocol behaves as described. 1237 When the text refers to initializing a state variable, this takes 1238 place only at the time that the session (and the corresponding state 1239 variables) is created. The state variables are subsequently 1240 manipulated by the state machine and are never reinitialized, even if 1241 the session fails and is reestablished. 1243 Once session state is created, and at least one BFD Control packet is 1244 received from the remote end, it MUST be preserved for at least one 1245 Detection Time (see section 6.8.4) subsequent to the receipt of the 1246 last BFD Control packet, regardless of the session state. This 1247 preserves timing parameters in case the session flaps. A system MAY 1248 preserve session state longer than this. The preservation or 1249 destruction of session state when no BFD Control packets for this 1250 session have been received from the remote system is outside the 1251 scope of this specification. 1253 All state variables in this specification are of the form "bfd.Xx" 1254 and should not be confused with fields carried in the protocol 1255 packets, which are always spelled out to match the names in section 1256 4. 1258 bfd.SessionState 1260 The perceived state of the session (Init, Up, Down, or 1261 AdminDown.) The exact action taken when the session state 1262 changes is outside the scope of this specification, though it 1263 is expected that this state change (particularly to and from Up 1264 state) is reported to other components of the system. This 1265 variable MUST be initialized to Down. 1267 bfd.RemoteSessionState 1269 The session state last reported by the remote system in the 1270 State (Sta) field of the BFD Control packet. This variable 1271 MUST be initialized to Down. 1273 bfd.LocalDiscr 1275 The local discriminator for this BFD session, used to uniquely 1276 identify it. It MUST be unique across all BFD sessions on this 1277 system, and nonzero. It SHOULD be set to a random (but still 1278 unique) value to improve security. The value is otherwise 1279 outside the scope of this specification. 1281 bfd.RemoteDiscr 1283 The remote discriminator for this BFD session. This is the 1284 discriminator chosen by the remote system, and is totally 1285 opaque to the local system. This MUST be initialized to zero. 1286 If a period of a Detection Time passes without the receipt of a 1287 valid, authenticated BFD packet from the remote system, this 1288 variable MUST be set to zero. 1290 bfd.LocalDiag 1292 The diagnostic code specifying the reason for the most recent 1293 change in the local session state. This MUST be initialized to 1294 zero (No Diagnostic.) 1296 bfd.DesiredMinTxInterval 1298 The minimum interval, in microseconds, between transmitted BFD 1299 Control packets that this system would like to use at the 1300 current time, less any jitter applied (see section 6.8.2). The 1301 actual interval is negotiated between the two systems. This 1302 MUST be initialized to a value of at least one second 1303 (1,000,000 microseconds) according to the rules described in 1304 section 6.8.3. The setting of this variable is otherwise 1305 outside the scope of this specification. 1307 bfd.RequiredMinRxInterval 1309 The minimum interval, in microseconds, between received BFD 1310 Control packets that this system requires, less any jitter 1311 applied by the sender (see section 6.8.2). The setting of this 1312 variable is outside the scope of this specification. A value 1313 of zero means that this system does not want to receive any 1314 periodic BFD Control packets. See section 6.8.18 for details. 1316 bfd.RemoteMinRxInterval 1318 The last value of Required Min RX Interval received from the 1319 remote system in a BFD Control packet. This variable MUST be 1320 initialized to 1. 1322 bfd.DemandMode 1324 Set to 1 if the local system wishes to use Demand mode, or 0 if 1325 not. 1327 bfd.RemoteDemandMode 1329 Set to 1 if the remote system wishes to use Demand mode, or 0 1330 if not. This is the value of the Demand (D) bit in the last 1331 received BFD Control packet. This variable MUST be initialized 1332 to zero. 1334 bfd.DetectMult 1336 The desired Detection Time multiplier for BFD Control packets 1337 on the local system. The negotiated Control packet 1338 transmission interval, multiplied by this variable, will be the 1339 Detection Time for this session (as seen by the remote system.) 1340 This variable MUST be a nonzero integer, and is otherwise 1341 outside the scope of this specification. See section 6.8.4 for 1342 further information. 1344 bfd.AuthType 1346 The authentication type in use for this session, as defined in 1347 section 4.1, or zero if no authentication is in use. 1349 bfd.RcvAuthSeq 1351 A 32 bit unsigned integer containing the last sequence number 1352 for keyed MD5 or SHA1 authentication that was received. The 1353 initial value is unimportant. 1355 bfd.XmitAuthSeq 1357 A 32 bit unsigned integer containing the next sequence number 1358 for keyed MD5 or SHA1 authentication to be transmitted. This 1359 variable MUST be initialized to a random 32 bit value. 1361 bfd.AuthSeqKnown 1363 Set to 1 if the next sequence number for keyed MD5 or SHA1 1364 authentication expected to be received is known, or 0 if it is 1365 not known. This variable MUST be initialized to zero. 1367 This variable MUST be set to zero after no packets have been 1368 received on this session for at least twice the Detection Time. 1369 This ensures that the sequence number can be resynchronized if 1370 the remote system restarts. 1372 6.8.2. Timer Negotiation 1374 The time values used to determine BFD packet transmission intervals 1375 and the session Detection Time are continuously negotiated, and thus 1376 may be changed at any time. The negotiation and time values are 1377 independent in each direction for each session. 1379 Each system reports in the BFD Control packet how rapidly it would 1380 like to transmit BFD packets, as well as how rapidly it is prepared 1381 to receive them. This allows either system to unilaterally determine 1382 the maximum packet rate (minimum interval) in both directions. 1384 See section 6.8.7 for the details of packet transmission timing and 1385 negotiation. 1387 6.8.3. Timer Manipulation 1389 The time values used to determine BFD packet transmission intervals 1390 and the session Detection Time may be modified at any time without 1391 affecting the state of the session. When the timer parameters are 1392 changed for any reason, the requirements of this section apply. 1394 If either bfd.DesiredMinTxInterval is changed or 1395 bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be 1396 initiated (see section 6.5). If the timing is such that a system 1397 receiving a Poll Sequence wishes to change the parameters described 1398 in this paragraph, the new parameter values MAY be carried in packets 1399 with the Final (F) bit set, even if the Poll Sequence has not yet 1400 been sent. 1402 If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, 1403 the actual transmission interval used MUST NOT change until the Poll 1404 Sequence described above has terminated. This is to ensure that the 1405 remote system updates its Detection Time before the transmission 1406 interval increases. 1408 If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, 1409 the previous value of bfd.RequiredMinRxInterval MUST be used when 1410 calculating the Detection Time for the remote system until the Poll 1411 Sequence described above has terminated. This is to ensure that the 1412 remote system is transmitting packets at the higher rate (and those 1413 packets are being received) prior to the Detection Time being 1414 reduced. 1416 When bfd.SessionState is not Up, the system MUST set 1417 bfd.DesiredMinTxInterval to a value of not less than one second 1418 (1,000,000 microseconds.) This is intended to ensure that the 1419 bandwidth consumed by BFD sessions that are not Up is negligible, 1420 particularly in the case where a neighbor may not be running BFD. 1422 If the local system reduces its transmit interval due to 1423 bfd.RemoteMinRxInterval being reduced (the remote system has 1424 advertised a reduced value in Required Min RX Interval), and the 1425 remote system is not in Demand mode, the local system MUST honor the 1426 new interval immediately. In other words, the local system cannot 1427 wait longer than the new interval between the previous packet 1428 transmission and the next one. If this interval has already passed 1429 since the last transmission (because the new interval is 1430 significantly shorter), the local system MUST send the next periodic 1431 BFD Control packet as soon as practicable. 1433 When the Echo function is active, a system SHOULD set 1434 bfd.RequiredMinRxInterval to a value of not less than one second 1435 (1,000,000 microseconds.) This is intended to keep received BFD 1436 Control traffic at a negligible level, since the actual detection 1437 function is being performed using BFD Echo packets. 1439 In any case other than those explicitly called out above, timing 1440 parameter changes MUST be effected immediately (changing the 1441 transmission rate and/or the Detection Time). 1443 Note that the Poll Sequence mechanism is ambiguous if more than one 1444 parameter change is made that would require its use, and those 1445 multiple changes are spread across multiple packets (since the 1446 semantics of the returning Final are unclear.) Therefore, if 1447 multiple changes are made that require the use of a Poll Sequence, 1448 there are three choices: 1) they MUST be communicated in a single 1449 BFD Control packet (so the semantics of the Final reply are clear), 1450 or 2) sufficient time must have transpired since the Poll Sequence 1451 was completed to disambiguate the situation (at least a round trip 1452 time since the last Poll was transmitted) prior to the initiation of 1453 another Poll Sequence, or 3) an additional BFD Control packet with 1454 the Final (F) bit *clear* MUST be received after the Poll Sequence 1455 has completed prior to the initiation of another Poll Sequence (this 1456 option is not available when Demand mode is active.) 1458 6.8.4. Calculating the Detection Time 1460 The Detection Time (the period of time without receiving BFD packets 1461 after which the session is determined to have failed) is not carried 1462 explicitly in the protocol. Rather, it is calculated independently 1463 in each direction by the receiving system based on the negotiated 1464 transmit interval and the detection multiplier. Note that there may 1465 be different Detection Times in each direction. 1467 The calculation of the Detection Time is slightly different when in 1468 Demand mode versus Asynchronous mode. 1470 In Asynchronous mode, the Detection Time calculated in the local 1471 system is equal to the value of Detect Mult received from the remote 1472 system, multiplied by the agreed transmit interval of the remote 1473 system (the greater of bfd.RequiredMinRxInterval and the last 1474 received Desired Min TX Interval.) The Detect Mult value is (roughly 1475 speaking, due to jitter) the number of packets that have to be missed 1476 in a row to declare the session to be down. 1478 If Demand mode is not active, and a period of time equal to the 1479 Detection Time passes without receiving a BFD Control packet from the 1480 remote system, and bfd.SessionState is Init or Up, the session has 1481 gone down--the local system MUST set bfd.SessionState to Down and 1482 bfd.LocalDiag to 1 (Control Detection Time Expired.) 1484 In Demand mode, the Detection Time calculated in the local system is 1485 equal to bfd.DetectMult, multiplied by the agreed transmit interval 1486 of the local system (the greater of bfd.DesiredMinTxInterval and 1487 bfd.RemoteMinRxInterval.) bfd.DetectMult is (roughly speaking, due 1488 to jitter) the number of packets that have to be missed in a row to 1489 declare the session to be down. 1491 If Demand mode is active, and a period of time equal to the Detection 1492 Time passes after the initiation of a Poll Sequence (the transmission 1493 of the first BFD Control packet with the Poll bit set), the session 1494 has gone down--the local system MUST set bfd.SessionState to Down, 1495 and bfd.LocalDiag to 1 (Control Detection Time Expired.) 1497 (Note that a packet is considered to have been received, for the 1498 purposes of Detection Time expiration, only if it has not been 1499 "discarded" according to the rules of section 6.8.6.) 1501 6.8.5. Detecting Failures with the Echo Function 1503 When the Echo function is active and a sufficient number of Echo 1504 packets have not arrived as they should, the session has gone 1505 down--the local system MUST set bfd.SessionState to Down, and 1506 bfd.LocalDiag to 2 (Echo Function Failed.) 1508 The means by which the Echo function failures are detected is outside 1509 of the scope of this specification. Any means which will detect a 1510 communication failure is acceptable. 1512 6.8.6. Reception of BFD Control Packets 1514 When a BFD Control packet is received, the following procedure MUST 1515 be followed, in the order specified. If the packet is discarded 1516 according to these rules, processing of the packet MUST cease at that 1517 point. 1519 If the version number is not correct (1), the packet MUST be 1520 discarded. 1522 If the Length field is less than the minimum correct value (24 if 1523 the A bit is clear, or 26 if the A bit is set), the packet MUST be 1524 discarded. 1526 If the Length field is greater than the payload of the 1527 encapsulating protocol, the packet MUST be discarded. 1529 If the Detect Mult field is zero, the packet MUST be discarded. 1531 If the Multipoint (M) bit is nonzero, the packet MUST be 1532 discarded. 1534 If the My Discriminator field is zero, the packet MUST be 1535 discarded. 1537 If the Your Discriminator field is nonzero, it MUST be used to 1538 select the session with which this BFD packet is associated. If 1539 no session is found, the packet MUST be discarded. 1541 If the Your Discriminator field is zero and the State field is not 1542 Down or AdminDown, the packet MUST be discarded. 1544 If the Your Discriminator field is zero, the session MUST be 1545 selected based on some combination of other fields, possibly 1546 including source addressing information, the My Discriminator 1547 field, and the interface over which the packet was received. The 1548 exact method of selection is application-specific and is thus 1549 outside the scope of this specification. If a matching session is 1550 not found, a new session MAY be created, or the packet MAY be 1551 discarded. This choice is outside the scope of this 1552 specification. 1554 If the A bit is set and no authentication is in use (bfd.AuthType 1555 is zero), the packet MUST be discarded. 1557 If the A bit is clear and authentication is in use (bfd.AuthType 1558 is nonzero), the packet MUST be discarded. 1560 If the A bit is set, the packet MUST be authenticated under the 1561 rules of section 6.7, based on the authentication type in use 1562 (bfd.AuthType.) This may cause the packet to be discarded. 1564 Set bfd.RemoteDiscr to the value of My Discriminator. 1566 Set bfd.RemoteState to the value of the State (Sta) field. 1568 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 1570 Set bfd.RemoteMinRxInterval to the value of Required Min RX 1571 Interval. 1573 If the Required Min Echo RX Interval field is zero, the 1574 transmission of Echo packets, if any, MUST cease. 1576 If a Poll Sequence is being transmitted by the local system and 1577 the Final (F) bit in the received packet is set, the Poll Sequence 1578 MUST be terminated. 1580 Update the transmit interval as described in section 6.8.2. 1582 Update the Detection Time as described in section 6.8.4. 1584 If bfd.SessionState is AdminDown 1585 Discard the packet 1587 If received state is AdminDown 1588 If bfd.SessionState is not Down 1589 Set bfd.LocalDiag to 3 (Neighbor signaled 1590 session down) 1591 Set bfd.SessionState to Down 1593 Else 1595 If bfd.SessionState is Down 1596 If received State is Down 1597 Set bfd.SessionState to Init 1598 Else if received State is Init 1599 Set bfd.SessionState to Up 1601 Else if bfd.SessionState is Init 1602 If received State is Init or Up 1603 Set bfd.SessionState to Up 1605 Else (bfd.SessionState is Up) 1606 If received State is Down 1607 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1608 Set bfd.SessionState to Down 1610 Check to see if Demand mode should become active or not (see 1611 section 6.6). 1613 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and 1614 bfd.RemoteSessionState is Up, Demand mode is active on the remote 1615 system and the local system MUST cease the periodic transmission 1616 of BFD Control packets (see section 6.8.7.) 1618 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 1619 bfd.RemoteSessionState is not Up, Demand mode is not active on the 1620 remote system and the local system MUST send periodic BFD Control 1621 packets (see section 6.8.7.) 1623 If the Poll (P) bit is set, send a BFD Control packet to the 1624 remote system with the Poll (P) bit clear, and the Final (F) bit 1625 set (see section 6.8.7.) 1627 If the packet was not discarded, it has been received for purposes 1628 of the Detection Time expiration rules in section 6.8.4. 1630 6.8.7. Transmitting BFD Control Packets 1632 With the exceptions listed in the remainder of this section, a system 1633 MUST NOT transmit BFD Control packets at an interval less than the 1634 larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less 1635 applied jitter (see below). In other words, the system reporting the 1636 slower rate determines the transmission rate. 1638 The periodic transmission of BFD Control packets MUST be jittered on 1639 a per-packet basis by up to 25%, that is, the interval MUST be 1640 reduced by a random value of 0 to 25%, in order to avoid self- 1641 synchronization with other systems on the same subnetwork. Thus, the 1642 average interval between packets will be roughly 12.5% less than that 1643 negotiated. 1645 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 1646 Control packets MUST be no more than 90% of the negotiated 1647 transmission interval, and MUST be no less than 75% of the negotiated 1648 transmission interval. This is to ensure that, on the remote system, 1649 the calculated Detection Time does not pass prior to the receipt of 1650 the next BFD Control packet. 1652 The transmit interval MUST be recalculated whenever 1653 bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval 1654 changes, and is equal to the greater of those two values. See 1655 sections 6.8.2 and 6.8.3 for details on transmit timers. 1657 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 1658 zero and the system is taking the Passive role. 1660 A system MUST NOT periodically transmit BFD Control packets if 1661 bfd.RemoteMinRxInterval is zero. 1663 A system MUST NOT periodically transmit BFD Control packets if Demand 1664 mode is active on the remote system (bfd.RemoteDemandMode is 1, 1665 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 1666 Sequence is not being transmitted. 1668 If a BFD Control packet is received with the Poll (P) bit set to 1, 1669 the receiving system MUST transmit a BFD Control packet with the Poll 1670 (P) bit clear and the Final (F) bit set as soon as practicable, 1671 without respect to the transmission timer or any other transmission 1672 limitations, without respect to the session state, and without 1673 respect to whether Demand mode is active on either system. A system 1674 MAY limit the rate at which such packets are transmitted. If rate 1675 limiting is in effect, the advertised value of Desired Min TX 1676 Interval MUST be greater than or equal to the interval between 1677 transmitted packets imposed by the rate limiting function. 1679 A system MUST NOT set the Demand (D) bit unless bfd.DemandMode is 1, 1680 bfd.SessionState is Up, and bfd.RemoteSessionState is Up. 1682 A BFD Control packet SHOULD be transmitted during the interval 1683 between periodic Control packet transmissions when the contents of 1684 that packet would differ from that in the previously transmitted 1685 packet (other than the Poll and Final bits) in order to more rapidly 1686 communicate a change in state. 1688 The contents of transmitted BFD Control packets MUST be set as 1689 follows: 1691 Version 1693 Set to the current version number (1). 1695 Diagnostic (Diag) 1697 Set to bfd.LocalDiag. 1699 State (Sta) 1701 Set to the value indicated by bfd.SessionState. 1703 Poll (P) 1705 Set to 1 if the local system is sending a Poll Sequence, or 0 if 1706 not. 1708 Final (F) 1710 Set to 1 if the local system is responding to a Control packet 1711 received with the Poll (P) bit set, or 0 if not. 1713 Control Plane Independent (C) 1715 Set to 1 if the local system's BFD implementation is independent 1716 of the control plane (it can continue to function through a 1717 disruption of the control plane.) 1719 Authentication Present (A) 1721 Set to 1 if authentication is in use on this session (bfd.AuthType 1722 is nonzero), or 0 if not. 1724 Demand (D) 1726 Set to bfd.DemandMode if bfd.SessionState is Up and 1727 bfd.RemoteSessionState is Up. Otherwise it is set to 0. 1729 Multipoint (M) 1731 Set to 0. 1733 Detect Mult 1735 Set to bfd.DetectMult. 1737 Length 1739 Set to the appropriate length, based on the fixed header length 1740 (24) plus any Authentication Section. 1742 My Discriminator 1744 Set to bfd.LocalDiscr. 1746 Your Discriminator 1748 Set to bfd.RemoteDiscr. 1750 Desired Min TX Interval 1752 Set to bfd.DesiredMinTxInterval. 1754 Required Min RX Interval 1756 Set to bfd.RequiredMinRxInterval. 1758 Required Min Echo RX Interval 1760 Set to the minimum required Echo packet receive interval for this 1761 session. If this field is set to zero, the local system is 1762 unwilling or unable to loop back BFD Echo packets to the remote 1763 system, and the remote system will not send Echo packets. 1765 Authentication Section 1767 Included and set according to the rules in section 6.7 if 1768 authentication is in use (bfd.AuthType is nonzero.) Otherwise 1769 this section is not present. 1771 6.8.8. Reception of BFD Echo Packets 1773 A received BFD Echo packet MUST be demultiplexed to the appropriate 1774 session for processing. A means of detecting missing Echo packets 1775 MUST be implemented, which most likely involves processing of the 1776 Echo packets that are received. The processing of received Echo 1777 packets is otherwise outside the scope of this specification. 1779 6.8.9. Transmission of BFD Echo Packets 1781 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 1782 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 1783 Control packet received from the remote system contains a nonzero 1784 value in Required Min Echo RX Interval. 1786 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 1787 interval between transmitted BFD Echo packets MUST NOT be less than 1788 the value advertised by the remote system in Required Min Echo RX 1789 Interval, except as follows: 1791 A 25% jitter MAY be applied to the rate of transmission, such that 1792 the actual interval MAY be between 75% and 100% of the advertised 1793 value. A single BFD Echo packet MAY be transmitted between 1794 normally scheduled Echo transmission intervals. 1796 The transmission of BFD Echo packets is otherwise outside the scope 1797 of this specification. 1799 6.8.10. Min Rx Interval Change 1801 When it is desired to change the rate at which BFD Control packets 1802 arrive from the remote system, bfd.RequiredMinRxInterval can be 1803 changed at any time to any value. The new value will be transmitted 1804 in the next outgoing Control packet, and the remote system will 1805 adjust accordingly. See section 6.8.3 for further requirements. 1807 6.8.11. Min Tx Interval Change 1809 When it is desired to change the rate at which BFD Control packets 1810 are transmitted to the remote system (subject to the requirements of 1811 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1812 any time to any value. The rules in section 6.8.3 apply. 1814 6.8.12. Detect Multiplier Change 1816 When it is desired to change the detect multiplier, the value of 1817 bfd.DetectMult can be changed to any nonzero value. The new value 1818 will be transmitted with the next BFD Control packet, and the use of 1819 a Poll Sequence is not necessary. See section 6.6 for additional 1820 requirements. 1822 6.8.13. Enabling or Disabling The Echo Function 1824 If it is desired to start or stop the transmission of BFD Echo 1825 packets, this MAY be done at any time (subject to the transmission 1826 requirements detailed in section 6.8.9.) 1828 If it is desired to enable or disable the looping back of received 1829 BFD Echo packets, this MAY be done at any time by changing the value 1830 of Required Min Echo RX Interval to zero or nonzero in outgoing BFD 1831 Control packets. 1833 6.8.14. Enabling or Disabling Demand Mode 1835 If it is desired to start or stop Demand mode, this MAY be done at 1836 any time by setting bfd.DemandMode to the proper value. Demand mode 1837 will subsequently become active under the rules described in section 1838 6.6. 1840 If Demand mode is no longer active on the remote system, the local 1841 system MUST begin transmitting periodic BFD Control packets as 1842 described in section 6.8.7. 1844 6.8.15. Forwarding Plane Reset 1846 When the forwarding plane in the local system is reset for some 1847 reason, such that the remote system can no longer rely on the local 1848 forwarding state, the local system MUST set bfd.LocalDiag to 4 1849 (Forwarding Plane Reset), and set bfd.SessionState to Down. 1851 6.8.16. Administrative Control 1853 There may be circumstances where it is desirable to administratively 1854 enable or disable a BFD session. When this is desired, the following 1855 procedure MUST be followed: 1857 If enabling session 1858 Set bfd.SessionState to Down 1860 Else 1861 Set bfd.SessionState to AdminDown 1862 Set bfd.LocalDiag to an appropriate value 1863 Cease the transmission of BFD Echo packets 1865 If signaling is received from outside BFD that the underlying path 1866 has failed, an implementation MAY administratively disable the 1867 session with the diagnostic Path Down. 1869 Other scenarios MAY use the diagnostic Administratively Down. 1871 BFD Control packets SHOULD be transmitted for at least a Detection 1872 Time after transitioning to AdminDown state in order to ensure that 1873 the remote system is aware of the state change. BFD Control packets 1874 MAY be transmitted indefinitely after transitioning to AdminDown 1875 state in order to maintain session state in each system (see section 1876 6.8.18 below.) 1878 6.8.17. Concatenated Paths 1880 If the path being monitored by BFD is concatenated with other paths 1881 (connected end-to-end in series), it may be desirable to propagate 1882 the indication of a failure of one of those paths across the BFD 1883 session (providing an interworking function for liveness monitoring 1884 between BFD and other technologies.) 1886 Two diagnostic codes are defined for this purpose: Concatenated Path 1887 Down and Reverse Concatenated Path Down. The first propagates 1888 forward path failures (in which the concatenated path fails in the 1889 direction toward the interworking system), and the second propagates 1890 reverse path failures (in which the concatenated path fails in the 1891 direction away from the interworking system, assuming a bidirectional 1892 link.) 1894 A system MAY signal one of these failure states by simply setting 1895 bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD 1896 session is not taken down. If Demand mode is not active on the 1897 remote system, no other action is necessary, as the diagnostic code 1898 will be carried via the periodic transmission of BFD Control packets. 1899 If Demand mode is active on the remote system (the local system is 1900 not transmitting periodic BFD Control packets), a Poll Sequence MUST 1901 be initiated to ensure that the diagnostic code is transmitted. Note 1902 that if the BFD session subsequently fails, the diagnostic code will 1903 be overwritten with a code detailing the cause of the failure. It is 1904 up to the interworking agent to perform the above procedure again, 1905 once the BFD session reaches Up state, if the propagation of the 1906 concatenated path failure is to resume. 1908 6.8.18. Holding Down Sessions 1910 A system MAY choose to prevent a BFD session from being established. 1911 One possible reason might be to manage the rate at which sessions are 1912 established. This can be done by holding the session in Down or 1913 AdminDown state, as appropriate. 1915 There are two related mechanisms that are available to help with this 1916 task. First, a system is REQUIRED to maintain session state 1917 (including timing parameters), even when a session is down, until a 1918 Detection Time has passed without the receipt of any BFD Control 1919 packets. This means that a system may take down a session and 1920 transmit an arbitrarily large value in the Required Min RX Interval 1921 field to control the rate at which it receives packets. 1923 Additionally, a system MAY transmit a value of zero for Required Min 1924 RX Interval to indicate that the remote system should send no packets 1925 whatsoever. 1927 So long as the local system continues to transmit BFD Control 1928 packets, the remote system is obligated to obey the value carried in 1929 Required Min RX Interval. If the remote system does not receive any 1930 BFD Control packets for a Detection Time, it SHOULD reset 1931 bfd.RemoteMinRxInterval to its initial value of 1 (per section 6.8.1, 1932 since it is no longer required to maintain previous session state) 1933 and then can transmit at its own rate. 1935 7. Operational Considerations 1937 BFD is likely to be deployed as a critical part of network 1938 infrastructure. As such, care should be taken to avoid disruption. 1940 Obviously, any mechanism that blocks BFD packets, such as firewalls 1941 or other policy processes, will cause BFD to fail. 1943 Mechanisms that control packet scheduling, such as policers, traffic 1944 shapers, priority queueing, etc., have the potential of impacting BFD 1945 operations if the Detection Time is similar in scale to the scheduled 1946 packet transmit or receive rate. The delivery of BFD packets is 1947 time-critical, relative to the magnitude of the Detection Time, so 1948 this may need to be taken into account in implementation and 1949 deployment, particularly when very short Detection Times are to be 1950 used. 1952 When BFD is used across multiple hops, a congestion control mechanism 1953 MUST be implemented, and when congestion is detected, the BFD 1954 implementation MUST reduce the amount of traffic it generates. The 1955 exact mechanism used is outside the scope of this specification, and 1956 the requirements of this mechanism may differ depending on how BFD is 1957 deployed, and how it interacts with other parts of the system (for 1958 example, exponential backoff may not be appropriate in cases where 1959 routing protocols are interacting closely with BFD.) 1961 Note that "congestion" is not only a traffic phenomenon, but also a 1962 computational one. It is possible for systems with a large number of 1963 BFD sessions and/or very short packet intervals to become CPU-bound. 1964 As such, a congestion control algorithm SHOULD be used even across 1965 single hops in order to avoid the possibility of catastrophic system 1966 collapse, as such failures have been seen repeatedly in other 1967 periodic hello-based protocols. 1969 The mechanisms for detecting congestion are outside the scope of this 1970 specification, but may include the detection of lost BFD Control 1971 packets (by virtue of holes in the authentication sequence number 1972 space, or by BFD session failure) or other means. 1974 The mechanisms for reducing BFD's traffic load are the control of the 1975 local and remote packet transmission rate via the Min RX Interval and 1976 Min TX Interval fields. 1978 Note that any mechanism that increases the transmit or receive 1979 intervals will increase the Detection Time for the session. 1981 It is worth noting that a single BFD session does not consume a large 1982 amount of bandwidth. An aggressive session that achieves a detection 1983 time of 50 milliseconds, by using a transmit interval of 16.7 1984 milliseconds and a detect multiplier of 3, will generate 60 packets 1985 per second. The maximum length of each packet on the wire is on the 1986 order of 100 bytes, for a total of around 48 kilobits per second of 1987 bandwidth consumption in each direction. 1989 8. IANA Considerations 1991 This document defines two registries to be administered by IANA. The 1992 first is entitled "BFD Diagnostic Codes" (see section 4.1). Initial 1993 values for the BFD Diagnostic Code registry are given below. Further 1994 assignments are to be made through Expert Review [IANA- 1995 CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name 1996 and its associated value. 1998 Value BFD Diagnostic Code Name 1999 ----- ------------------------ 2000 0 No Diagnostic 2001 1 Control Detection Time Expired 2002 2 Echo Function Failed 2003 3 Neighbor Signaled Session Down 2004 4 Forwarding Plane Reset 2005 5 Path Down 2006 6 Concatenated Path Down 2007 7 Administratively Down 2008 8 Reverse Concatenated Path Down 2009 9-31 Unassigned 2011 The second registry is entitled "BFD Authentication Types" (see section 2012 4.1). Initial values for the BFD Authentication Type registry are given 2013 below. Further assignments are to be made through Expert Review 2014 [IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type 2015 Code name and its associated value. 2017 Value BFD Authentication Type Name 2018 ----- ---------------------------- 2019 0 Reserved 2020 1 Simple Password 2021 2 Keyed MD5 2022 3 Meticulous Keyed MD5 2023 4 Keyed SHA1 2024 5 Meticulous Keyed SHA1 2025 6-255 Unassigned 2027 9. Security Considerations 2029 As BFD may be tied into the stability of the network infrastructure 2030 (such as routing protocols), the effects of an attack on a BFD 2031 session may be very serious: a link may be falsely declared to be 2032 down, or falsely declared to be up; in either case, the effect is 2033 denial-of-service. 2035 An attacker who is in complete control of the link between the 2036 systems can easily drop all BFD packets but forward everything else 2037 (causing the link to be falsely declared down), or forward only the 2038 BFD packets but nothing else (causing the link to be falsely declared 2039 up). This attack cannot be prevented by BFD. 2041 To mitigate threats from less capable attackers, BFD specifies two 2042 mechanisms to prevent spoofing of BFD Control packets. The 2043 Generalized TTL Security Mechanism [GTSM] uses the TTL or Hop Count 2044 to prevent off-link attackers from spoofing packets. The 2045 Authentication Section authenticates the BFD Control packets. These 2046 mechanisms are described in more detail below. 2048 When a BFD session is directly connected across a single link 2049 (physical, or a secure tunnel such as IPsec), the TTL or Hop Count 2050 MUST be set to the maximum on transmit, and checked to be equal to 2051 the maximum value on reception (and the packet dropped if this is not 2052 the case.) See [GTSM] for more information on this technique. If 2053 BFD is run across multiple hops or an insecure tunnel (such as GRE), 2054 the Authentication Section SHOULD be utilized. 2056 The level of security provided by the Authentication Section varies 2057 based on the authentication type used. Simple Password 2058 authentication is obviously only as secure as the secrecy of the 2059 passwords used, and should be considered only if the BFD session is 2060 guaranteed to be run over an infrastructure not subject to packet 2061 interception. Its chief advantage is that it minimizes the 2062 computational effort required for authentication. 2064 Keyed MD5 authentication is much stronger than Simple Password 2065 authentication since the keys cannot be discerned by intercepting 2066 packets. It is vulnerable to replay attacks in between increments of 2067 the sequence number. The sequence number can be incremented as 2068 seldom (or as often) as desired, trading off resistance to replay 2069 attacks with the computational effort required for authentication. 2071 Meticulous Keyed MD5 authentication is stronger yet, as it requires 2072 the sequence number to be incremented for every packet. Replay 2073 attack vulnerability is reduced due to the requirement that the 2074 sequence number must be incremented on every packet, the window size 2075 of acceptable packets is small, and the initial sequence number is 2076 randomized. There is still a window of attack at the beginning of 2077 the session while the sequence number is being determined. This 2078 authentication scheme requires an MD5 calculation on every packet 2079 transmitted and received. 2081 Using SHA1 is believed to have stronger security properties than MD5. 2082 All comments about MD5 in this section also apply to SHA1. 2084 Both Keyed MD5/SHA1 and Meticulous Keyed MD5/SHA1 use the "secret 2085 suffix" construction (also called "append only") in which the shared 2086 secret key is appended to the data before calculating the hash, 2087 instead of the more common HMAC construction [HMAC]. This 2088 construction is believed to be appropriate for BFD, but designers of 2089 any additional authentication mechanisms for BFD are encouraged to 2090 read [HMAC] and its references. 2092 If both systems randomize their Local Discriminator values at the 2093 beginning of a session, replay attacks may be further mitigated, 2094 regardless of the authentication type in use. Since the Local 2095 Discriminator may be changed at any time during a session, this 2096 mechanism may also help mitigate attacks. 2098 The security implications of the use of BFD Echo packets are 2099 dependent on how those packets are defined, since their structure is 2100 local to the transmitting system and outside the scope of this 2101 specification. However, since Echo packets are defined and processed 2102 only by the transmitting system, the use of cryptographic 2103 authentication does not guarantee that the other system is actually 2104 alive; an attacker could loop the Echo packets back (without knowing 2105 any secret keys) and cause the link to be falsely declared to be up. 2106 This can be mitigated by using a suitable interval for BFD Control 2107 packets. [GTSM] could be applied to BFD Echo packets, though the 2108 TTL/Hop Count will be decremented by 1 in the course of echoing the 2109 packet, so spoofing is possible from one hop away. 2111 10. References 2113 10.1. Normative References 2115 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 2116 (GTSM)", RFC 5082, October 2007. 2118 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 2119 Requirement Levels", RFC 2119, March 1997. 2121 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 2122 1992. 2124 [SHA1] Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, 2125 September 2001. 2127 10.2. Informative References 2129 [HMAC] Krawczyk, H., et al, "HMAC: Keyed-Hashing for Message 2130 Authentication", RFC 2104, February, 1997. 2132 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 2133 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2134 5226, May 2008. 2136 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 2138 Backward Compatibility (Non-Normative) 2140 Although Version 0 of this document is unlikely to have been deployed 2141 widely, some implementors may wish to have a backward compatibility 2142 mechanism. Note that any mechanism may be potentially used that does 2143 not alter the protocol definition, so interoperability should not be 2144 an issue. 2146 The suggested mechanism described here has the property that it will 2147 converge on version 1 if both systems implement it, even if one 2148 system is upgraded from version 0 within a Detection Time. It will 2149 interoperate with a system that implements only one version (or is 2150 configured to support only one version.) A system should obviously 2151 not perform this function if it is configured to or is only capable 2152 of using a single version. 2154 A BFD session will enter a "negotiation holddown" if it is configured 2155 for automatic versioning and either has just started up, or the 2156 session has been manually cleared. The session is set to AdminDown 2157 state and Version 1. During the holddown period, which lasts for one 2158 Detection Time, the system sends BFD Control packets as usual, but 2159 ignores received packets. After the holddown time is complete, the 2160 state transitions to Down and normal operation resumes. 2162 When a system is not in holddown, if it doing automatic versioning 2163 and is currently using Version 1, if any Version 0 packet is received 2164 for the session, it switches immediately to Version 0. If it is 2165 currently using Version 0 and a Version 1 packet is received that 2166 indicates that the neighbor is in state AdminDown, it switches to 2167 Version 1. If using Version 0 and a Version 1 packet is received 2168 indicating a state other than AdminDown, the packet is ignored (per 2169 spec.) 2171 If the version being used is changed, the session goes down as 2172 appropriate for the new version (Down state for Version 1 or Failing 2173 state for Version 0.) 2175 Contributors 2177 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 2178 significant contributors to this document. 2180 Acknowledgments 2182 This document was inspired by (and is intended to replace) the 2183 Protocol Liveness Protocol draft, written by Kireeti Kompella. 2185 Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 2186 et al. 2188 The authors would also like to thank Mike Shand, John Scudder, 2189 Stewart Bryant, Pekka Savola, Richard Spencer, and Pasi Eronen for 2190 their substantive input. 2192 The authors would also like to thank Owen Wheeler for hosting 2193 teleconferences between the authors of this specification and 2194 multiple vendors in order address implementation and clarity issues. 2196 Authors' Addresses 2198 Dave Katz 2199 Juniper Networks 2200 1194 N. Mathilda Ave. 2201 Sunnyvale, California 94089-1206 USA 2202 Phone: +1-408-745-2000 2203 Email: dkatz@juniper.net 2205 Dave Ward 2206 Juniper Networks 2207 1194 N. Mathilda Ave. 2208 Sunnyvale, California 94089-1206 USA 2209 Phone: +1-408-745-2000 2210 Email: dward@juniper.net 2212 Changes from the Previous Draft 2214 The definition and configuration of passwords and authentication keys 2215 was changed slightly to improve interoperability with deployed code. 2216 The security considerations for the Echo protocol was changed 2217 slightly. 2219 All other changes are purely editorial in nature. 2221 This document expires in July, 2010.