idnits 2.17.1 draft-ietf-bfd-base-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 (February 5, 2009) is 5552 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 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 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 Cisco Systems 6 Expires: August, 2009 February 5, 2009 8 Bidirectional Forwarding Detection 9 draft-ietf-bfd-base-09.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. 44 Abstract 46 This document describes a protocol intended to detect faults in the 47 bidirectional path between two forwarding engines, including 48 interfaces, data link(s), and to the extent possible the forwarding 49 engines themselves, with potentially very low latency. It operates 50 independently of media, data protocols, and routing protocols. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1 Addressing and Session Establishment . . . . . . . . . . . 6 64 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 6 65 4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7 66 4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 67 4.2 Simple Password Authentication Section Format . . . . . 12 68 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 69 Section Format . . . . . . . . . . . . . . . . . . . . . 13 70 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 71 Section Format . . . . . . . . . . . . . . . . . . . . . 14 72 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 15 73 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 16 74 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 75 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 17 76 6.3 Demultiplexing and the Discriminator Fields . . . . . . 19 77 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 20 78 6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 20 79 6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 21 80 6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 22 81 6.7.1 Enabling and Disabling Authentication . . . . . . 23 82 6.7.2 Simple Password Authentication . . . . . . . . . . 24 83 6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 24 84 6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 26 85 6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28 86 6.8.1 State Variables . . . . . . . . . . . . . . . . . 28 87 6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32 88 6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32 89 6.8.4 Calculating the Detection Time . . . . . . . . . . 34 90 6.8.5 Detecting Failures with the Echo Function . . . . 35 91 6.8.6 Reception of BFD Control Packets . . . . . . . . . 35 92 6.8.7 Transmitting BFD Control Packets . . . . . . . . . 37 93 6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 40 94 6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 41 95 6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 41 96 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 41 97 6.8.12 Detect Multiplier Change . . . . . . . . . . . . 41 98 6.8.13 Enabling or Disabling the Echo Function . . . . . 42 99 6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 42 100 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 42 101 6.8.16 Administrative Control . . . . . . . . . . . . . 42 102 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43 103 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 43 104 7. Operational Considerations . . . . . . . . . . . . . . . . . 44 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 106 9. Security Considerations . . . . . . . . . . . . . . . . . . 46 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . 47 108 10.1 Normative References . . . . . . . . . . . . . . . . . 47 109 10.2 Informative References . . . . . . . . . . . . . . . . 47 110 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 47 111 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 112 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49 114 Changes from the previous draft . . . . . . . . . . . . . . . . 49 116 1. Introduction 118 An increasingly important feature of networking equipment is the 119 rapid detection of communication failures between adjacent systems, 120 in order to more quickly establish alternative paths. Detection can 121 come fairly quickly in certain circumstances when data link hardware 122 comes into play (such as SONET alarms.) However, there are media 123 that do not provide this kind of signaling (such as Ethernet), and 124 some media may not detect certain kinds of failures in the path, for 125 example, failing interfaces or forwarding engine components. 127 Networks use relatively slow "Hello" mechanisms, usually in routing 128 protocols, to detect failures when there is no hardware signaling to 129 help out. The time to detect failures ("Detection Times") available 130 in the existing protocols are no better than a second, which is far 131 too long for some applications and represents a great deal of lost 132 data at gigabit rates. Furthermore, routing protocol Hellos are of 133 no help when those routing protocols are not in use, and the 134 semantics of detection are subtly different--they detect a failure in 135 the path between the two routing protocol engines. 137 The goal of BFD is to provide low-overhead, short-duration detection 138 of failures in the path between adjacent forwarding engines, 139 including the interfaces, data link(s), and to the extent possible 140 the forwarding engines themselves. 142 An additional goal is to provide a single mechanism that can be used 143 for liveness detection over any media, at any protocol layer, with a 144 wide range of Detection Times and overhead, to avoid a proliferation 145 of different methods. 147 This document specifies the details of the base protocol. The use of 148 some mechanisms are application dependent and are specified in a 149 separate series of application documents. These issues are so noted. 151 Note that many of the exact mechanisms are implementation dependent 152 and will not affect interoperability, and are thus outside the scope 153 of this specification. Those issues are so noted. 155 2. Design 157 BFD is designed to detect failures in communication with a forwarding 158 plane next hop. It is intended to be implemented in some component 159 of the forwarding engine of a system, in cases where the forwarding 160 and control engines are separated. This not only binds the protocol 161 more to the forwarding plane, but decouples the protocol from the 162 fate of the routing protocol engine, making it useful in concert with 163 various "graceful restart" mechanisms for those protocols. BFD may 164 also be implemented in the control engine, though doing so may 165 preclude the detection of some kinds of failures. 167 BFD operates on top of any data protocol (network layer, link layer, 168 tunnels, etc.) being forwarded between two systems. It is always 169 run in a unicast, point-to-point mode. BFD packets are carried as 170 the payload of whatever encapsulating protocol is appropriate for the 171 medium and network. BFD may be running at multiple layers in a 172 system. The context of the operation of any particular BFD session 173 is bound to its encapsulation. 175 BFD can provide failure detection on any kind of path between 176 systems, including direct physical links, virtual circuits, tunnels, 177 MPLS LSPs, multihop routed paths, and unidirectional links (so long 178 as there is some return path, of course.) Multiple BFD sessions can 179 be established between the same pair of systems when multiple paths 180 between them are present in at least one direction, even if a lesser 181 number of paths are available in the other direction (multiple 182 parallel unidirectional links or MPLS LSPs, for example.) 184 The BFD state machine implements a three-way handshake, both when 185 establishing a BFD session and when tearing it down for any reason, 186 to ensure that both systems are aware of the state change. 188 BFD can be abstracted as a simple service. The service primitives 189 provided by BFD are to create, destroy, and modify a session, given 190 the destination address and other parameters. BFD in return provides 191 a signal to its clients indicating when the BFD session goes up or 192 down. 194 3. Protocol Overview 196 BFD is a simple hello protocol that in many respects is similar to 197 the detection components of well-known routing protocols. A pair of 198 systems transmit BFD packets periodically over each path between the 199 two systems, and if a system stops receiving BFD packets for long 200 enough, some component in that particular bidirectional path to the 201 neighboring system is assumed to have failed. Under some conditions, 202 systems may negotiate to not send periodic BFD packets in order to 203 reduce overhead. 205 A path is only declared to be operational when two-way communication 206 has been established between systems, though this does not preclude 207 the use of unidirectional links. 209 A separate BFD session is created for each communications path and 210 data protocol in use between two systems. 212 Each system estimates how quickly it can send and receive BFD packets 213 in order to come to an agreement with its neighbor about how rapidly 214 detection of failure will take place. These estimates can be 215 modified in real time in order to adapt to unusual situations. This 216 design also allows for fast systems on a shared medium with a slow 217 system to be able to more rapidly detect failures between the fast 218 systems while allowing the slow system to participate to the best of 219 its ability. 221 The ability of each system to control the BFD packet transmission 222 rate in both directions provides a mechanism for congestion control, 223 particularly when BFD is used across multiple network hops. The 224 exact algorithm can be independent in each system without affecting 225 interoperability, and is outside the scope of this specification. 227 3.1. Addressing and Session Establishment 229 A BFD session is established based on the needs of the application 230 that will be making use of it. It is up to the application to 231 determine the need for BFD, and the addresses to use--there is no 232 discovery mechanism in BFD. For example, an OSPF [OSPF] 233 implementation may request a BFD session to be established to a 234 neighbor discovered using the OSPF Hello protocol. 236 3.2. Operating Modes 238 BFD has two operating modes which may be selected, as well as an 239 additional function that can be used in combination with the two 240 modes. 242 The primary mode is known as Asynchronous mode. In this mode, the 243 systems periodically send BFD Control packets to one another, and if 244 a number of those packets in a row are not received by the other 245 system, the session is declared to be down. 247 The second mode is known as Demand mode. In this mode, it is assumed 248 that a system has an independent way of verifying that it has 249 connectivity to the other system. Once a BFD session is established, 250 such a system may ask the other system to stop sending BFD Control 251 packets, except when the system feels the need to verify connectivity 252 explicitly, in which case a short sequence of BFD Control packets is 253 exchanged, and then the far system quiesces. Demand mode may operate 254 independently in each direction, or simultaneously. 256 An adjunct to both modes is the Echo function. When the Echo 257 function is active, a stream of BFD Echo packets is transmitted in 258 such a way as to have the other system loop them back through its 259 forwarding path. If a number of packets of the echoed data stream 260 are not received, the session is declared to be down. The Echo 261 function may be used with either Asynchronous or Demand modes. Since 262 the Echo function is handling the task of detection, the rate of 263 periodic transmission of Control packets may be reduced (in the case 264 of Asynchronous mode) or eliminated completely (in the case of Demand 265 mode.) 267 Pure asynchronous mode is advantageous in that it requires half as 268 many packets to achieve a particular Detection Time as does the Echo 269 function. It is also used when the Echo function cannot be supported 270 for some reason. 272 The Echo function has the advantage of truly testing only the 273 forwarding path on the remote system. This may reduce round-trip 274 jitter and thus allow more aggressive Detection Times, as well as 275 potentially detecting some classes of failure that might not 276 otherwise be detected. 278 The Echo function may be enabled individually in each direction. It 279 is enabled in a particular direction only when the system that loops 280 the Echo packets back signals that it will allow it, and when the 281 system that sends the Echo packets decides it wishes to. 283 Demand mode is useful in situations where the overhead of a periodic 284 protocol might prove onerous, such as a system with a very large 285 number of BFD sessions. It is also useful when the Echo function is 286 being used symmetrically. Demand mode has the disadvantage that 287 Detection Times are essentially driven by the heuristics of the 288 system implementation and are not known to the BFD protocol. Demand 289 mode may not be used when the path round trip time is greater than 290 the desired Detection Time, or the protocol will fail to work 291 properly. See section 6.6 for more details. 293 4. BFD Control Packet Format 295 4.1. Generic BFD Control Packet Format 297 BFD Control packets are sent in an encapsulation appropriate to the 298 environment. The specific encapsulation is outside of the scope of 299 this specification. See the appropriate application document for 300 encapsulation details. 302 The BFD Control packet has a Mandatory Section and an optional 303 Authentication Section. The format of the Authentication Section, if 304 present, is dependent on the type of authentication in use. 306 The Mandatory Section of a BFD Control packet has the following 307 format: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | My Discriminator | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Your Discriminator | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Desired Min TX Interval | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Required Min RX Interval | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Required Min Echo RX Interval | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 An optional Authentication Section MAY be present: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Auth Type | Auth Len | Authentication Data... | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Version (Vers) 335 The version number of the protocol. This document defines 336 protocol version 1. 338 Diagnostic (Diag) 340 A diagnostic code specifying the local system's reason for the 341 last change in session state. Values are: 343 0 -- No Diagnostic 344 1 -- Control Detection Time Expired 345 2 -- Echo Function Failed 346 3 -- Neighbor Signaled Session Down 347 4 -- Forwarding Plane Reset 348 5 -- Path Down 349 6 -- Concatenated Path Down 350 7 -- Administratively Down 351 8 -- Reverse Concatenated Path Down 352 9-31 -- Reserved for future use 354 This field allows remote systems to determine the reason that the 355 previous session failed, for example. 357 State (Sta) 359 The current BFD session state as seen by the transmitting system. 360 Values are: 362 0 -- AdminDown 363 1 -- Down 364 2 -- Init 365 3 -- Up 367 Poll (P) 369 If set, the transmitting system is requesting verification of 370 connectivity, or of a parameter change, and is expecting a packet 371 with the Final (F) bit in reply. If clear, the transmitting 372 system is not requesting verification. 374 Final (F) 376 If set, the transmitting system is responding to a received BFD 377 Control packet that had the Poll (P) bit set. If clear, the 378 transmitting system is not responding to a Poll. 380 Control Plane Independent (C) 382 If set, the transmitting system's BFD implementation does not 383 share fate with its control plane (in other words, BFD is 384 implemented in the forwarding plane and can continue to function 385 through disruptions in the control plane.) If clear, the 386 transmitting system's BFD implementation shares fate with its 387 control plane. 389 The use of this bit is application dependent and is outside the 390 scope of this specification. See specific application 391 specifications for details. 393 Authentication Present (A) 395 If set, the Authentication Section is present and the session is 396 to be authenticated (see section 6.7 for details). 398 Demand (D) 400 If set, Demand mode is active in the transmitting system (the 401 system wishes to operate in Demand mode, knows that the session is 402 up in both directions, and is directing the remote system to cease 403 the periodic transmission of BFD Control packets.) If clear, 404 Demand mode is not active in the transmitting system. 406 Multipoint (M) 408 This bit is reserved for future point-to-multipoint extensions to 409 BFD. It MUST be zero on both transmit and receipt. 411 Detect Mult 413 Detection time multiplier. The negotiated transmit interval, 414 multiplied by this value, provides the Detection Time for the 415 transmitting system in Asynchronous mode. 417 Length 419 Length of the BFD Control packet, in bytes. 421 My Discriminator 423 A unique, nonzero discriminator value generated by the 424 transmitting system, used to demultiplex multiple BFD sessions 425 between the same pair of systems. 427 Your Discriminator 429 The discriminator received from the corresponding remote system. 430 This field reflects back the received value of My Discriminator, 431 or is zero if that value is unknown. 433 Desired Min TX Interval 435 This is the minimum interval, in microseconds, that the local 436 system would like to use when transmitting BFD Control packets, 437 less any jitter applied (see section 6.8.2). The value zero is 438 reserved. 440 Required Min RX Interval 442 This is the minimum interval, in microseconds, between received 443 BFD Control packets that this system is capable of supporting, 444 less any jitter applied by the sender (see section 6.8.2). If 445 this value is zero, the transmitting system does not want the 446 remote system to send any periodic BFD Control packets. 448 Required Min Echo RX Interval 450 This is the minimum interval, in microseconds, between received 451 BFD Echo packets that this system is capable of supporting, less 452 any jitter applied by the sender (see section 6.8.9). If this 453 value is zero, the transmitting system does not support the 454 receipt of BFD Echo packets. 456 Auth Type 458 The authentication type in use, if the Authentication Present (A) 459 bit is set. 461 0 - Reserved 462 1 - Simple Password 463 2 - Keyed MD5 464 3 - Meticulous Keyed MD5 465 4 - Keyed SHA1 466 5 - Meticulous Keyed SHA1 467 6-255 - Reserved for future use 469 Auth Len 471 The length, in bytes, of the authentication section, including the 472 Auth Type and Auth Len fields. 474 4.2. Simple Password Authentication Section Format 476 If the Authentication Present (A) bit is set in the header, and the 477 Authentication Type field contains 1 (Simple Password), the 478 Authentication Section has the following format: 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Auth Type | Auth Len | Auth Key ID | Password... | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | ... | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Auth Type 490 The Authentication Type, which in this case is 1 (Simple 491 Password.) 493 Auth Len 495 The length of the Authentication Section, in bytes. For Simple 496 Password authentication, the length is equal to the password 497 length plus three. 499 Auth Key ID 501 The authentication key ID in use for this packet. This allows 502 multiple keys to be active simultaneously. 504 Password 506 The simple password in use on this session. The password MUST be 507 from 1 to 16 bytes in length. 509 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 511 The use of MD5-based authentication is strongly discouraged. 512 However, it is documented here for compatibility with existing 513 implementations. 515 If the Authentication Present (A) bit is set in the header, and the 516 Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous 517 Keyed MD5), the Authentication Section has the following format: 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Auth Type | Auth Len | Auth Key ID | Reserved | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Sequence Number | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Auth Key/Digest... | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | ... | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Auth Type 533 The Authentication Type, which in this case is 2 (Keyed MD5) or 3 534 (Meticulous Keyed MD5). 536 Auth Len 538 The length of the Authentication Section, in bytes. For Keyed MD5 539 and Meticulous Keyed MD5 authentication, the length is 24. 541 Auth Key ID 543 The authentication key ID in use for this packet. This allows 544 multiple keys to be active simultaneously. 546 Reserved 548 This byte MUST be set to zero on transmit, and ignored on receipt. 550 Sequence Number 552 The Sequence Number for this packet. For Keyed MD5 553 Authentication, this value is incremented occasionally. For 554 Meticulous Keyed MD5 Authentication, this value is incremented for 555 each successive packet transmitted for a session. This provides 556 protection against replay attacks. 558 Auth Key/Digest 560 This field carries the 16 byte MD5 digest for the packet. When 561 the digest is calculated, the shared MD5 key is stored in this 562 field. (See section 6.7.3 for details.) The shared key MUST be 563 16 bytes in length. 565 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 567 If the Authentication Present (A) bit is set in the header, and the 568 Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous 569 Keyed SHA1), the Authentication Section has the following format: 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Auth Type | Auth Len | Auth Key ID | Reserved | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Sequence Number | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Auth Key/Hash... | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | ... | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Auth Type 585 The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 586 (Meticulous Keyed SHA1). 588 Auth Len 590 The length of the Authentication Section, in bytes. For Keyed 591 SHA1 and Meticulous Keyed SHA1 authentication, the length is 28. 593 Auth Key ID 595 The authentication key ID in use for this packet. This allows 596 multiple keys to be active simultaneously. 598 Reserved 600 This byte MUST be set to zero on transmit, and ignored on receipt. 602 Sequence Number 604 The Sequence Number for this packet. For Keyed SHA1 605 Authentication, this value is incremented occasionally. For 606 Meticulous Keyed SHA1 Authentication, this value is incremented 607 for each successive packet transmitted for a session. This 608 provides protection against replay attacks. 610 Auth Key/Hash 612 This field carries the 20 byte SHA1 hash for the packet. When the 613 hash is calculated, the shared SHA1 key is stored in this field. 614 (See section 6.7.4 for details.) The shared key MUST be 20 bytes 615 in length. 617 5. BFD Echo Packet Format 619 BFD Echo packets are sent in an encapsulation appropriate to the 620 environment. See the appropriate application documents for the 621 specifics of particular environments. 623 The payload of a BFD Echo packet is a local matter, since only the 624 sending system ever processes the content. The only requirement is 625 that sufficient information is included to demultiplex the received 626 packet to the correct BFD session after it is looped back to the 627 sender. The contents are otherwise outside the scope of this 628 specification. 630 Some form of authentication SHOULD be included, since Echo packets 631 may be spoofed. 633 6. Elements of Procedure 635 This section discusses the normative requirements of the protocol in 636 order to achieve interoperability. It is important for implementors 637 to enforce only the requirements specified in this section, as 638 misguided pedantry has been proven by experience to adversely affect 639 interoperability. 641 Remember that all references of the form "bfd.Xx" refer to internal 642 state variables (defined in section 6.8.1), whereas all references to 643 "the Xxx field" refer to fields in the protocol packets themselves 644 (defined in section 4). 646 6.1. Overview 648 A system may take either an Active role or a Passive role in session 649 initialization. A system taking the Active role MUST send BFD 650 Control packets for a particular session, regardless of whether it 651 has received any BFD packets for that session. A system taking the 652 Passive role MUST NOT begin sending BFD packets for a particular 653 session until it has received a BFD packet for that session, and thus 654 has learned the remote system's discriminator value. At least one 655 system MUST take the Active role (possibly both.) The role that a 656 system takes is specific to the application of BFD, and is outside 657 the scope of this specification. 659 A session begins with the periodic, slow transmission of BFD Control 660 packets. When bidirectional communication is achieved, the BFD 661 session comes Up. 663 Once the BFD session is Up, a system can choose to start the Echo 664 function if it desires to and the other system signals that it will 665 allow it. The rate of transmission of Control packets is typically 666 kept low when the Echo function is active. 668 If the Echo function is not active, the transmission rate of Control 669 packets may be increased to a level necessary to achieve the 670 Detection Time requirements for the session. 672 Once the session is up, a system may signal that it has entered 673 Demand mode, and the transmission of BFD Control packets by the 674 remote system ceases. Other means of implying connectivity are used 675 to keep the session alive. If either system wishes to verify 676 bidirectional connectivity, it can initiate a short exchange of BFD 677 Control packets (a "Poll Sequence"; see section 6.5) to do so. 679 If Demand mode is not active, and no Control packets are received in 680 the calculated Detection Time (see section 6.8.4), the session is 681 declared Down. This is signaled to the remote end via the State 682 (Sta) field in outgoing packets. 684 If sufficient Echo packets are lost, the session is declared down in 685 the same manner. See section 6.8.5. 687 If Demand mode is active and no appropriate Control packets are 688 received in response to a Poll Sequence, the session is declared down 689 in the same manner. See section 6.6. 691 If the session goes down, the transmission of Echo packets (if any) 692 ceases, and the transmission of Control packets goes back to the slow 693 rate. 695 Once a session has been declared down, it cannot come back up until 696 the remote end first signals that it is down (by leaving the Up 697 state), thus implementing a three-way handshake. 699 A session MAY be kept administratively down by entering the AdminDown 700 state and sending an explanatory diagnostic code in the Diagnostic 701 field. 703 6.2. BFD State Machine 705 The BFD state machine is quite straightforward. There are three 706 states through which a session normally proceeds, two for 707 establishing a session (Init and Up) and one for tearing down a 708 session (Down.) This allows a three-way handshake for both session 709 establishment and session teardown (assuring that both systems are 710 aware of all session state changes.) A fourth state (AdminDown) 711 exists so that a session can be administratively put down 712 indefinitely. 714 Each system communicates its session state in the State (Sta) field 715 in the BFD Control packet, and that received state in combination 716 with the local session state drives the state machine. 718 Down state means that the session is down (or has just been created.) 719 A session remains in Down state until the remote system indicates 720 that it agrees that the session is down by sending a BFD Control 721 packet with the State field set to anything other than Up. If that 722 packet signals Down state, the session advances to Init state; if 723 that packet signals Init state, the session advances to Up state. 724 Semantically, Down state indicates that the forwarding path is 725 unavailable, and that appropriate actions should be taken by the 726 applications monitoring the state of the BFD session. A system MAY 727 hold a session in Down state indefinitely (by simply refusing to 728 advance the session state.) This may be done for operational or 729 administrative reasons, among others. 731 Init state means that the remote system is communicating, and the 732 local system desires to bring the session up, but the remote system 733 does not yet realize it. A session will remain in Init state until 734 either a BFD Control Packet is received that is signaling Init or Up 735 state (in which case the session advances to Up state) or until the 736 Detection Time expires, meaning that communication with the remote 737 system has been lost (in which case the session advances to Down 738 state.) 740 Up state means that the BFD session has successfully been 741 established, and implies that connectivity between the systems is 742 working. The session will remain in the Up state until either 743 connectivity fails, or the session is taken down administratively. 744 If either the remote system signals Down state, or the Detection Time 745 expires, the session advances to Down state. 747 AdminDown state means that the session is being held administratively 748 down. This causes the remote system to enter Down state, and remain 749 there until the local system exits AdminDown state. AdminDown state 750 has no semantic implications for the availability of the forwarding 751 path. 753 The following diagram provides an overview of the state machine. 754 Transitions involving AdminDown state are deleted for clarity (but 755 are fully specified in sections 6.8.6 and 6.8.16.) The notation on 756 each arc represents the state of the remote system (as received in 757 the State field in the BFD Control packet) or indicates the 758 expiration of the Detection Timer. 760 +--+ 761 | | UP, ADMIN DOWN, TIMER 762 | V 763 DOWN +------+ INIT 764 +------------| |------------+ 765 | | DOWN | | 766 | +-------->| |<--------+ | 767 | | +------+ | | 768 | | | | 769 | | ADMIN DOWN,| | 770 | |ADMIN DOWN, DOWN,| | 771 | |TIMER TIMER| | 772 V | | V 773 +------+ +------+ 774 +----| | | |----+ 775 DOWN| | INIT |--------------------->| UP | |INIT, UP 776 +--->| | INIT, UP | |<---+ 777 +------+ +------+ 779 6.3. Demultiplexing and the Discriminator Fields 781 Since multiple BFD sessions may be running between two systems, there 782 needs to be a mechanism for demultiplexing received BFD packets to 783 the proper session. 785 Each system MUST choose an opaque discriminator value that identifies 786 each session, and which MUST be unique among all BFD sessions on the 787 system. The local discriminator is sent in the My Discriminator 788 field in the BFD Control packet, and is echoed back in the Your 789 Discriminator field of packets sent from the remote end. 791 Once the remote end echoes back the local discriminator, all further 792 received packets are demultiplexed based on the Your Discriminator 793 field only (which means that, among other things, the source address 794 field can change or the interface over which the packets are received 795 can change, but the packets will still be associated with the proper 796 session.) 798 The method of demultiplexing the initial packets (in which Your 799 Discriminator is zero) is application-dependent, and is thus outside 800 the scope of this specification. 802 Note that it is permissible for a system to change its discriminator 803 during a session without affecting the session state, since only that 804 system uses its discriminator for demultiplexing purposes (by having 805 the other system reflect it back.) The implications on an 806 implementation for changing the discriminator value is outside the 807 scope of this specification. 809 6.4. The Echo Function and Asymmetry 811 The Echo function can be run independently in each direction between 812 a pair of systems. For whatever reason, a system may advertise that 813 it is willing to receive (and loop back) Echo packets, but may not 814 wish to ever send any. The fact that a system is sending Echo 815 packets is not directly signaled to the system looping them back. 817 When a system is using the Echo function, it is advantageous to 818 choose a sedate reception rate for Control packets, since liveness 819 detection is being handled by the Echo packets. This can be 820 controlled by manipulating the Required Min RX Interval field (see 821 section 6.8.3.) 823 If the Echo function is only being run in one direction, the system 824 not running the Echo function will more likely wish to receive fairly 825 rapid Control packets in order to achieve its desired Detection Time. 826 Since BFD allows independent transmission rates in each direction, 827 this is easily accomplished. 829 A system SHOULD otherwise advertise the lowest value of Required Min 830 RX Interval and Required Min Echo RX Interval that it can under the 831 circumstances, to give the other system more freedom in choosing its 832 transmission rate. Note that a system is committing to be able to 833 receive both streams of packets at the rate it advertises, so this 834 should be taken into account when choosing the values to advertise. 836 6.5. The Poll Sequence 838 A Poll Sequence is an exchange of BFD Control packets that is used in 839 some circumstances to ensure that the remote system is aware of 840 parameter changes. It is also used in Demand mode (see section 6.6) 841 to validate bidirectional connectivity. 843 A Poll Sequence consists of a system sending periodic BFD Control 844 packets with the Poll (P) bit set. When the other system receives a 845 Poll, it immediately transmits a BFD Control packet with the Final 846 (F) bit set, independent of any periodic BFD Control packets it may 847 be sending (see section 6.8.7). When the system sending the Poll 848 sequence receives a packet with Final, the Poll Sequence is 849 terminated, and any subsequent BFD Control packets are sent with the 850 Poll bit cleared. A BFD Control packet MUST NOT have both the Poll 851 (P) and Final (F) bits set. 853 If periodic BFD Control packets are already being sent (the remote 854 system is not in Demand mode), the Poll Sequence MUST be performed by 855 setting the Poll (P) bit on those scheduled periodic transmissions; 856 additional packets MUST NOT be sent. 858 After a Poll Sequence is terminated, the system requesting the Poll 859 Sequence will cease the periodic transmission of BFD Control packets 860 if the remote end is in Demand mode; otherwise it will return to the 861 periodic transmission of BFD Control packets with the Poll (P) bit 862 clear. 864 Typically, the entire sequence consists of a single packet in each 865 direction, though packet losses or relatively long packet latencies 866 may result in multiple Poll packets to be sent before the sequence 867 terminates. 869 6.6. Demand Mode 871 Demand mode is requested independently in each direction by virtue of 872 a system setting the Demand (D) bit in its BFD Control packets. The 873 system receiving the Demand bit ceases the periodic transmission of 874 BFD Control packets. If both systems are operating in Demand mode, 875 no periodic BFD Control packets will flow in either direction. 877 Demand mode requires that some other mechanism is used to imply 878 continuing connectivity between the two systems. The mechanism used 879 does not have to be the same in both directions, and is outside of 880 the scope of this specification. One possible mechanism is the 881 receipt of traffic from the remote system; another is the use of the 882 Echo function. 884 When a system in Demand mode wishes to verify bidirectional 885 connectivity, it initiates a Poll Sequence (see section 6.5). If no 886 response is received to a Poll, the Poll is repeated until the 887 Detection Time expires, at which point the session is declared to be 888 down. Note that if Demand mode is operating only on the local 889 system, the Poll Sequence is performed by simply setting the Poll (P) 890 bit in regular periodic BFD Control packets, as required by section 891 6.6. 893 The Detection Time in Demand mode is calculated differently than in 894 Asynchronous mode; it is based on the transmit rate of the local 895 system, rather than the transmit rate of the remote system. This 896 ensures that the Poll Sequence mechanism works properly. See section 897 6.8.4 for more details. 899 Note that the Poll mechanism will always fail unless the negotiated 900 Detection Time is greater than the round trip time between the two 901 systems. Enforcement of this constraint is outside the scope of this 902 specification. 904 Demand mode MAY be enabled or disabled at any time, independently in 905 each direction, by setting or clearing the Demand (D) bit in the BFD 906 Control packet, without affecting the BFD session state. Note that 907 the Demand bit MUST NOT be set unless both systems perceive the 908 session to be Up (the local system thinks the session is Up, and the 909 remote system last reported Up state in the State (Sta) field of the 910 BFD Control packet.) 912 When the transmitted value of the Demand (D) bit is to be changed, 913 the transmitting system MUST initiate a Poll Sequence in conjunction 914 with changing the bit in order to ensure that both systems are aware 915 of the change. 917 If Demand mode is active on either or both systems, a Poll Sequence 918 MUST be initiated whenever the contents of the next BFD Control 919 packet to be sent would be different than the contents of the 920 previous packet, with the exception of the Poll (P) and Final (F) 921 bits. This ensures that parameter changes are transmitted to the 922 remote system and that the remote system acknowledges these changes. 924 Because the underlying detection mechanism is unspecified, and may 925 differ between the two systems, the overall Detection Time 926 characteristics of the path will not be fully known to either system. 927 The total Detection Time for a particular system is the sum of the 928 time prior to the initiation of the Poll Sequence, plus the 929 calculated Detection Time. 931 Note that if Demand mode is enabled in only one direction, continuous 932 bidirectional connectivity verification is lost (only connectivity in 933 the direction from the system in Demand mode to the other system will 934 be verified.) Resolving the issue of one system requesting Demand 935 mode while the other requires continuous bidirectional connectivity 936 verification is outside the scope of this specification. 938 6.7. Authentication 940 An optional Authentication Section MAY be present in the BFD Control 941 packet. In its generic form, the purpose of the Authentication 942 Section is to carry all necessary information, based on the 943 authentication type in use, to allow the receiving system to 944 determine the validity of the received packet. The exact mechanism 945 depends on the authentication type in use, but in general the 946 transmitting system will put information in the Authentication 947 Section that vouches for the packet's validity, and the receiving 948 system will examine the Authentication Section and either accept the 949 packet for further processing, or discard it. 951 The same authentication type, and any keys or other necessary 952 information, obviously must be in use by the two systems. The 953 negotiation of authentication type, key exchange, etc. are all 954 outside the scope of this specification and are expected to be 955 performed by means outside of the protocol. 957 Note that in the subsections below, to "accept" a packet means only 958 that the packet has passed authentication; it may in fact be 959 discarded for other reasons as described in the general packet 960 reception rules described in section 6.8.6. 962 Implementations supporting authentication MUST support SHA1 963 authentication. Other forms of authentication are optional. 965 6.7.1. Enabling and Disabling Authentication 967 It may be desirable to enable or disable authentication on a session 968 without disturbing the session state. The exact mechanism for doing 969 so is outside the scope of this specification. However, it is useful 970 to point out some issues in supporting this mechanism. 972 In a simple implementation, a BFD session will fail when 973 authentication is either turned on or turned off, because the packet 974 acceptance rules essentially require the local and remote machines to 975 do so in a more or less synchronized fashion (within the Detection 976 Time)--a packet with authentication will only be accepted if 977 authentication is "in use" (and likewise packets without 978 authentication. 980 One possible approach is to build an implementation such that 981 authentication is configured, but not considered "in use" until the 982 first packet containing a matching authentication section is received 983 (providing the necessary synchronization.) Likewise, authentication 984 could be configured off, but still considered "in use" until the 985 receipt of the first packet without the authentication section. 987 In order to avoid security risks, implementations using this method 988 SHOULD only allow the authentication state to be changed at most once 989 without some form of intervention (so that authentication cannot be 990 turned on and off repeatedly simply based on the receipt of BFD 991 Control packets from remote systems.) Unless it is desired to enable 992 or disable authentication, an implementation SHOULD NOT allow the 993 authentication state to change based on the receipt of BFD Control 994 packets. 996 6.7.2. Simple Password Authentication 998 The most straightforward (and weakest) form of authentication is 999 Simple Password Authentication. In this method of authentication, 1000 one or more Passwords (with corresponding Key IDs) are configured in 1001 each system and one of these Password/ID pairs is carried in each BFD 1002 Control packet. The receiving system accepts the packet if the 1003 Password and Key ID matches one of the Password/ID pairs configured 1004 in that system. 1006 Transmission Using Simple Password Authentication 1008 The currently selected password and Key ID for the session MUST be 1009 stored in the Authentication Section of each outgoing BFD Control 1010 packet. The Auth Type field MUST be set to 1 (Simple Password.) 1011 The Auth Len field MUST be set to the proper length (4 to 19 1012 bytes.) 1014 Reception Using Simple Password Authentication 1016 If the received BFD Control packet does not contain an 1017 Authentication Section, or the Auth Type is not 1 (Simple 1018 Password), then the received packet MUST be discarded. 1020 If the Auth Key ID field does not match the ID of a configured 1021 password, the received packet MUST be discarded. 1023 If the Auth Len field is not equal to the length of the password 1024 selected by the Key ID, plus three, the packet MUST be discarded. 1026 If the Password field does not match the password selected by the 1027 Key ID, the packet MUST be discarded. 1029 Otherwise, the packet MUST be accepted. 1031 6.7.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 1033 The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are 1034 very similar to those used in other protocols. In these methods of 1035 authentication, one or more secret keys (with corresponding Key IDs) 1036 are configured in each system. One of the Keys is included in an MD5 1037 [MD5] digest calculated over the outgoing BFD Control packet, but the 1038 Key itself is not carried in the packet. To help avoid replay 1039 attacks, a sequence number is also carried in each packet. For Keyed 1040 MD5, the sequence number is occasionally incremented. For Meticulous 1041 Keyed MD5, the sequence number is incremented on every packet. 1043 The receiving system accepts the packet if the Key ID matches one of 1044 the configured Keys, an MD5 digest including the selected key matches 1045 that carried in the packet, and if the sequence number is greater 1046 than or equal to the last sequence number received (for Keyed MD5), 1047 or strictly greater than the last sequence number received (for 1048 Meticulous Keyed MD5.) 1050 Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication 1052 The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous 1053 Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key 1054 ID field MUST be set to the ID of the current authentication key. 1055 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1057 The current authentication key value MUST be placed into the Auth 1058 Key/Digest field. An MD5 digest MUST be calculated over the 1059 entire BFD control packet. The resulting digest MUST be stored in 1060 the Auth Key/Digest field prior to transmission (replacing the 1061 secret key, which MUST NOT be carried in the packet.) 1063 For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular 1064 fashion (when treated as an unsigned 32 bit value.) 1065 bfd.XmitAuthSeq SHOULD be incremented when the session state 1066 changes, or when the transmitted BFD Control packet carries 1067 different contents than the previously transmitted packet. The 1068 decision as to when to increment bfd.XmitAuthSeq is outside the 1069 scope of this specification. See the section entitled "Security 1070 Considerations" below for a discussion. 1072 For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a 1073 circular fashion (when treated as an unsigned 32 bit value.) 1075 Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication 1077 If the received BFD Control packet does not contain an 1078 Authentication Section, or the Auth Type is not correct (2 for 1079 Keyed MD5, or 3 for Meticulous Keyed MD5), then the received 1080 packet MUST be discarded. 1082 If the Auth Key ID field does not match the ID of a configured 1083 authentication key, the received packet MUST be discarded. 1085 If the Auth Len field is not equal to 24, the packet MUST be 1086 discarded. 1088 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1089 Keyed MD5, if the Sequence Number lies outside of the range of 1090 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1091 treated as an unsigned 32 bit circular number space), the received 1092 packet MUST be discarded. For Meticulous Keyed MD5, if the 1093 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1094 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1095 unsigned 32 bit circular number space, the received packet MUST be 1096 discarded. 1098 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1099 1, bfd.RcvAuthSeq MUST be set to the value of the received 1100 Sequence Number field. 1102 Replace the contents of the Auth Key/Digest field with the 1103 authentication key selected by the received Auth Key ID field. If 1104 the MD5 digest of the entire BFD Control packet is equal to the 1105 received value of the Auth Key/Digest field, the received packet 1106 MUST be accepted. Otherwise (the digest does not match the Auth 1107 Key/Digest field) the received packet MUST be discarded. 1109 6.7.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1111 The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms 1112 are very similar to those used in other protocols. In these methods 1113 of authentication, one or more secret keys (with corresponding Key 1114 IDs) are configured in each system. One of the Keys is included in a 1115 SHA1 [SHA1] hash calculated over the outgoing BFD Control packet, but 1116 the Key itself is not carried in the packet. To help avoid replay 1117 attacks, a sequence number is also carried in each packet. For Keyed 1118 SHA1, the sequence number is occasionally incremented. For 1119 Meticulous Keyed SHA1, the sequence number is incremented on every 1120 packet. 1122 The receiving system accepts the packet if the Key ID matches one of 1123 the configured Keys, a SHA1 hash including the selected key matches 1124 that carried in the packet, and if the sequence number is greater 1125 than or equal to the last sequence number received (for Keyed SHA1), 1126 or strictly greater than the last sequence number received (for 1127 Meticulous Keyed SHA1.) 1129 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 1130 Authentication 1132 The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous 1133 Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key 1134 ID field MUST be set to the ID of the current authentication key. 1135 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1137 The current authentication key value MUST be placed into the Auth 1138 Key/Hash field. A SHA1 hash MUST be calculated over the entire 1139 BFD control packet. The resulting hash MUST be stored in the Auth 1140 Key/Hash field prior to transmission (replacing the secret key, 1141 which MUST NOT be carried in the packet.) 1143 For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular 1144 fashion (when treated as an unsigned 32 bit value.) 1145 bfd.XmitAuthSeq SHOULD be incremented when the session state 1146 changes, or when the transmitted BFD Control packet carries 1147 different contents than the previously transmitted packet. The 1148 decision as to when to increment bfd.XmitAuthSeq is outside the 1149 scope of this specification. See the section entitled "Security 1150 Considerations" below for a discussion. 1152 For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in 1153 a circular fashion (when treated as an unsigned 32 bit value.) 1155 Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1157 If the received BFD Control packet does not contain an 1158 Authentication Section, or the Auth Type is not correct (4 for 1159 Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received 1160 packet MUST be discarded. 1162 If the Auth Key ID field does not match the ID of a configured 1163 authentication key, the received packet MUST be discarded. 1165 If the Auth Len field is not equal to 28, the packet MUST be 1166 discarded. 1168 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1169 Keyed SHA1, if the Sequence Number lies outside of the range of 1170 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1171 treated as an unsigned 32 bit circular number space), the received 1172 packet MUST be discarded. For Meticulous Keyed SHA1, if the 1173 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1174 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1175 unsigned 32 bit circular number space, the received packet MUST be 1176 discarded. 1178 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1179 1, bfd.RcvAuthSeq MUST be set to the value of the received 1180 Sequence Number field, and the received packet MUST be accepted. 1182 Replace the contents of the Auth Key/Hash field with the 1183 authentication key selected by the received Auth Key ID field. If 1184 the SHA1 hash of the entire BFD Control packet is equal to the 1185 received value of the Auth Key/Hash field, the received packet 1186 MUST be accepted. Otherwise (the hash does not match the Auth 1187 Key/Hash field) the received packet MUST be discarded. 1189 6.8. Functional Specifics 1191 The following section of this specification is normative. The means 1192 by which this specification is achieved is outside the scope of this 1193 specification. 1195 When a system is said to have "the Echo function active," it means 1196 that the system is sending BFD Echo packets, implying that the 1197 session is Up and the other system has signaled its willingness to 1198 loop back Echo packets. 1200 When the local system is said to have "Demand mode active," it means 1201 that bfd.DemandMode is 1 in the local system (see section 6.8.1), the 1202 session is Up, and the remote system is signaling that the session is 1203 in state Up. 1205 When the remote system is said to have "Demand mode active," it means 1206 that bfd.RemoteDemandMode is 1 (the remote system set the Demand (D) 1207 bit in the last received BFD Control packet), the session is Up, and 1208 the remote system is signaling that the session is in state Up. 1210 6.8.1. State Variables 1212 A minimum amount of information about a session needs to be tracked 1213 in order to achieve the elements of procedure described here. The 1214 following is a set of state variables that are helpful in describing 1215 the mechanisms of BFD. Any means of tracking this state may be used 1216 so long as the protocol behaves as described. 1218 When the text refers to initializing a state variable, this takes 1219 place only at the time that the session (and the corresponding state 1220 variables) is created. The state variables are subsequently 1221 manipulated by the state machine and are never reinitialized, even if 1222 the session fails and is reestablished. 1224 Once session state is created, and at least one BFD Control packet is 1225 received from the remote end, it MUST be preserved for at least one 1226 Detection Time (see section 6.8.4) subsequent to the receipt of the 1227 last BFD Control packet, regardless of the session state. This 1228 preserves timing parameters in case the session flaps. A system MAY 1229 preserve session state longer than this. The preservation or 1230 destruction of session state when no BFD Control packets for this 1231 session have been received from the remote system is outside the 1232 scope of this specification. 1234 All state variables in this specification are of the form "bfd.Xx" 1235 and should not be confused with fields carried in the protocol 1236 packets, which are always spelled out to match the names in section 1237 4. 1239 bfd.SessionState 1241 The perceived state of the session (Init, Up, Down, or 1242 AdminDown.) The exact action taken when the session state 1243 changes is outside the scope of this specification, though it 1244 is expected that this state change (particularly to and from Up 1245 state) is reported to other components of the system. This 1246 variable MUST be initialized to Down. 1248 bfd.RemoteSessionState 1250 The session state last reported by the remote system in the 1251 State (Sta) field of the BFD Control packet. This variable 1252 MUST be initialized to Down. 1254 bfd.LocalDiscr 1256 The local discriminator for this BFD session, used to uniquely 1257 identify it. It MUST be unique across all BFD sessions on this 1258 system, and nonzero. It SHOULD be set to a random (but still 1259 unique) value to improve security. The value is otherwise 1260 outside the scope of this specification. 1262 bfd.RemoteDiscr 1264 The remote discriminator for this BFD session. This is the 1265 discriminator chosen by the remote system, and is totally 1266 opaque to the local system. This MUST be initialized to zero. 1267 If a period of a Detection Time passes without the receipt of a 1268 valid, authenticated BFD packet from the remote system, this 1269 variable MUST be set to zero. 1271 bfd.LocalDiag 1273 The diagnostic code specifying the reason for the most recent 1274 change in the local session state. This MUST be initialized to 1275 zero (No Diagnostic.) 1277 bfd.DesiredMinTxInterval 1279 The minimum interval, in microseconds, between transmitted BFD 1280 Control packets that this system would like to use at the 1281 current time, less any jitter applied (see section 6.8.2). The 1282 actual interval is negotiated between the two systems. This 1283 MUST be initialized to a value of at least one second 1284 (1,000,000 microseconds) according to the rules described in 1285 section 6.8.3. The setting of this variable is otherwise 1286 outside the scope of this specification. 1288 bfd.RequiredMinRxInterval 1290 The minimum interval, in microseconds, between received BFD 1291 Control packets that this system requires, less any jitter 1292 applied by the sender (see section 6.8.2). The setting of this 1293 variable is outside the scope of this specification. A value 1294 of zero means that this system does not want to receive any 1295 periodic BFD Control packets. See section 6.8.18 for details. 1297 bfd.RemoteMinRxInterval 1299 The last value of Required Min RX Interval received from the 1300 remote system in a BFD Control packet. This variable MUST be 1301 initialized to 1. 1303 bfd.DemandMode 1305 Set to 1 if the local system wishes to use Demand mode, or 0 if 1306 not. 1308 bfd.RemoteDemandMode 1310 Set to 1 if the remote system wishes to use Demand mode, or 0 1311 if not. This is the value of the Demand (D) bit in the last 1312 received BFD Control packet. This variable MUST be initialized 1313 to zero. 1315 bfd.DetectMult 1317 The desired Detection Time multiplier for BFD Control packets. 1318 The negotiated Control packet transmission interval, multiplied 1319 by this variable, will be the Detection Time for this session 1320 (as seen by the remote system.) This variable MUST be a 1321 nonzero integer, and is otherwise outside the scope of this 1322 specification. See section 6.8.4 for further information. 1324 bfd.AuthType 1326 The authentication type in use for this session, as defined in 1327 section 4.1, or zero if no authentication is in use. 1329 bfd.RcvAuthSeq 1331 A 32 bit unsigned integer containing the next sequence number 1332 for keyed MD5 or SHA1 authentication expected to be received. 1333 The initial value is unimportant. 1335 bfd.XmitAuthSeq 1337 A 32 bit unsigned integer containing the next sequence number 1338 for keyed MD5 or SHA1 authentication to be transmitted. This 1339 variable MUST be initialized to a random 32 bit value. 1341 bfd.AuthSeqKnown 1343 Set to 1 if the next sequence number for keyed MD5 or SHA1 1344 authentication expected to be received is known, or 0 if it is 1345 not known. This variable MUST be initialized to zero. 1347 This variable MUST be set to zero after no packets have been 1348 received on this session for at least twice the Detection Time. 1349 This ensures that the sequence number can be resynchronized if 1350 the remote system restarts. 1352 6.8.2. Timer Negotiation 1354 The time values used to determine BFD packet transmission intervals 1355 and the session Detection Time are continuously negotiated, and thus 1356 may be changed at any time. The negotiation and time values are 1357 independent in each direction for each session. 1359 Each system reports in the BFD Control packet how rapidly it would 1360 like to transmit BFD packets, as well as how rapidly it is prepared 1361 to receive them. With the exceptions listed in the remainder of this 1362 section, a system MUST NOT transmit BFD Control packets at an 1363 interval less than the larger of bfd.DesiredMinTxInterval and 1364 bfd.RemoteMinRxInterval. In other words, the system reporting the 1365 slower rate determines the transmission rate. 1367 The periodic transmission of BFD Control packets SHOULD be jittered 1368 by up to 25%, that is, the interval SHOULD be reduced by a random 1369 value of 0 to 25%, in order to avoid self-synchronization. Thus, the 1370 average interval between packets may be up to 12.5% less than that 1371 negotiated. 1373 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 1374 Control packets MUST be no more than 90% of the negotiated 1375 transmission interval, and MUST be no less than 75% of the negotiated 1376 transmission interval. This is to ensure that, on the remote system, 1377 the calculated DetectTime does not pass prior to the receipt of the 1378 next BFD Control packet. 1380 6.8.3. Timer Manipulation 1382 The time values used to determine BFD packet transmission intervals 1383 and the session Detection Time may be modified at any time without 1384 affecting the state of the session. When the timer parameters are 1385 changed for any reason, the requirements of this section apply. 1387 If either bfd.DesiredMinTxInterval is changed or 1388 bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be 1389 initiated (see section 6.5). If the timing is such that a system 1390 receiving a Poll Sequence wishes to change the parameters described 1391 in this paragraph, the new parameter values MAY be carried in packets 1392 with the Final (F) bit set, even if the Poll Sequence has not yet 1393 been sent. 1395 If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, 1396 the actual transmission interval used MUST NOT change until the Poll 1397 Sequence described above has terminated. This is to ensure that the 1398 remote system updates its Detection Time before the transmission 1399 interval increases. 1401 If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, 1402 the previous value of bfd.RequiredMinRxInterval MUST be used when 1403 calculating the Detection Time for the remote system until the Poll 1404 Sequence described above has terminated. This is to ensure that the 1405 remote system is transmitting packets at the higher rate (and those 1406 packets are being received) prior to the Detection Time being 1407 reduced. 1409 When bfd.SessionState is not Up, the system MUST set 1410 bfd.DesiredMinTxInterval to a value of not less than one second 1411 (1,000,000 microseconds.) This is intended to ensure that the 1412 bandwidth consumed by BFD sessions that are not Up is negligible, 1413 particularly in the case where a neighbor may not be running BFD. 1415 If the local system reduces its transmit interval due to 1416 bfd.RemoteMinRxInterval being reduced (the remote system has 1417 advertised a reduced value in Required Min RX Interval), and the 1418 remote system is not in Demand mode, the local system MUST honor the 1419 new interval immediately. In other words, the local system cannot 1420 wait longer than the new interval between the previous packet 1421 transmission and the next one. If this interval has already passed 1422 since the last transmission (because the new interval is 1423 significantly shorter), the local system MUST send the next periodic 1424 BFD Control packet as soon as practicable. 1426 When the Echo function is active, a system SHOULD set 1427 bfd.RequiredMinRxInterval to a value of not less than one second 1428 (1,000,000 microseconds.) This is intended to keep received BFD 1429 Control traffic at a negligible level, since the actual detection 1430 function is being performed using BFD Echo packets. 1432 In any case other than those explicitly called out above, timing 1433 parameter changes MUST be effected immediately (changing the 1434 transmission rate and/or the Detection Time). 1436 Note that the Poll Sequence mechanism is ambiguous if more than one 1437 parameter change is made that would require its use, and those 1438 multiple changes are spread across multiple packets (since the 1439 semantics of the returning Final are unclear.) Therefore, if 1440 multiple changes are made that require the use of a Poll Sequence, 1441 there are three choices: 1) they MUST be communicated in a single 1442 BFD Control packet (so the semantics of the Final reply are clear), 1443 or 2) sufficient time must have transpired since the Poll Sequence 1444 was completed to disambiguate the situation (at least a round trip 1445 time since the last Poll was transmitted) prior to the initiation of 1446 another Poll Sequence, or 3) an additional BFD Control packet with 1447 the Final (F) bit *clear* MUST be received after the Poll Sequence 1448 has completed prior to the initiation of another Poll Sequence (this 1449 option is not available when Demand mode is active.) 1451 6.8.4. Calculating the Detection Time 1453 The Detection Time (the period of time without receiving BFD packets 1454 after which the session is determined to have failed) is not carried 1455 explicitly in the protocol. Rather, it is calculated independently 1456 in each direction by the receiving system based on the negotiated 1457 transmit interval and the detection multiplier. Note that there may 1458 be different Detection Times in each direction. 1460 The calculation of the Detection Time is slightly different when in 1461 Demand mode versus Asynchronous mode. 1463 In Asynchronous mode, the Detection Time calculated in the local 1464 system is equal to the value of Detect Mult received from the remote 1465 system, multiplied by the agreed transmit interval of the remote 1466 system (the greater of bfd.RequiredMinRxInterval and the last 1467 received Desired Min TX Interval.) The Detect Mult value is (roughly 1468 speaking, due to jitter) the number of packets that have to be missed 1469 in a row to declare the session to be down. 1471 If Demand mode is not active, and a period of time equal to the 1472 Detection Time passes without receiving a BFD Control packet from the 1473 remote system, and bfd.SessionState is Init or Up, the session has 1474 gone down--the local system MUST set bfd.SessionState to Down and 1475 bfd.LocalDiag to 1 (Control Detection Time Expired.) 1477 In Demand mode, the Detection Time calculated in the local system is 1478 equal to bfd.DetectMult, multiplied by the agreed transmit interval 1479 of the local system (the greater of bfd.DesiredMinTxInterval and 1480 bfd.RemoteMinRxInterval.) bfd.DetectMult is (roughly speaking, due 1481 to jitter) the number of packets that have to be missed in a row to 1482 declare the session to be down. 1484 If Demand mode is active, and a period of time equal to the Detection 1485 Time passes after the initiation of a Poll Sequence (the transmission 1486 of the first BFD Control packet with the Poll bit set), the session 1487 has gone down--the local system MUST set bfd.SessionState to Down, 1488 and bfd.LocalDiag to 1 (Control Detection Time Expired.) 1490 (Note that a packet is considered to have been received, for the 1491 purposes of Detection Time expiration, only if it has not been 1492 "discarded" according to the rules of section 6.8.6.) 1494 6.8.5. Detecting Failures with the Echo Function 1496 When the Echo function is active and a sufficient number of Echo 1497 packets have not arrived as they should, the session has gone 1498 down--the local system MUST set bfd.SessionState to Down, and 1499 bfd.LocalDiag to 2 (Echo Function Failed.) 1501 The means by which the Echo function failures are detected is outside 1502 of the scope of this specification. Any means which will detect a 1503 communication failure is acceptable. 1505 6.8.6. Reception of BFD Control Packets 1507 When a BFD Control packet is received, the following procedure MUST 1508 be followed, in the order specified. If the packet is discarded 1509 according to these rules, processing of the packet MUST cease at that 1510 point. 1512 If the version number is not correct (1), the packet MUST be 1513 discarded. 1515 If the Length field is less than the minimum correct value (24 if 1516 the A bit is clear, or 26 if the A bit is set), the packet MUST be 1517 discarded. 1519 If the Length field is greater than the payload of the 1520 encapsulating protocol, the packet MUST be discarded. 1522 If the Detect Mult field is zero, the packet MUST be discarded. 1524 If the Multipoint (M) bit is nonzero, the packet MUST be 1525 discarded. 1527 If the My Discriminator field is zero, the packet MUST be 1528 discarded. 1530 If the Your Discriminator field is nonzero, it MUST be used to 1531 select the session with which this BFD packet is associated. If 1532 no session is found, the packet MUST be discarded. 1534 If the Your Discriminator field is zero and the State field is not 1535 Down or AdminDown, the packet MUST be discarded. 1537 If the Your Discriminator field is zero, the session MUST be 1538 selected based on some combination of other fields, possibly 1539 including source addressing information, the My Discriminator 1540 field, and the interface over which the packet was received. The 1541 exact method of selection is application-specific and is thus 1542 outside the scope of this specification. If a matching session is 1543 not found, a new session MAY be created, or the packet MAY be 1544 discarded. This choice is outside the scope of this 1545 specification. 1547 If the A bit is set and no authentication is in use (bfd.AuthType 1548 is zero), the packet MUST be discarded. 1550 If the A bit is clear and authentication is in use (bfd.AuthType 1551 is nonzero), the packet MUST be discarded. 1553 If the A bit is set, the packet MUST be authenticated under the 1554 rules of section 6.7, based on the authentication type in use 1555 (bfd.AuthType.) This may cause the packet to be discarded. 1557 Set bfd.RemoteDiscr to the value of My Discriminator. 1559 Set bfd.RemoteState to the value of the State (Sta) field. 1561 Set bfd.RemoteDemandMode to the value of the Demand (D) bit. 1563 Set bfd.RemoteMinRxInterval to the value of Required Min RX 1564 Interval. 1566 If the Required Min Echo RX Interval field is zero, the 1567 transmission of Echo packets, if any, MUST cease. 1569 If a Poll Sequence is being transmitted by the local system and 1570 the Final (F) bit in the received packet is set, the Poll Sequence 1571 MUST be terminated. 1573 Update the transmit interval as described in section 6.8.2. 1575 Update the Detection Time as described in section 6.8.4. 1577 If bfd.SessionState is AdminDown 1578 Discard the packet 1580 If received state is AdminDown 1581 If bfd.SessionState is not Down 1582 Set bfd.LocalDiag to 3 (Neighbor signaled 1583 session down) 1584 Set bfd.SessionState to Down 1586 Else 1588 If bfd.SessionState is Down 1589 If received State is Down 1590 Set bfd.SessionState to Init 1591 Else if received State is Init 1592 Set bfd.SessionState to Up 1594 Else if bfd.SessionState is Init 1595 If received State is Init or Up 1596 Set bfd.SessionState to Up 1598 Else (bfd.SessionState is Up) 1599 If received State is Down 1600 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1601 Set bfd.SessionState to Down 1603 Check to see if Demand mode should become active or not (see 1604 section 6.6). 1606 If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and 1607 bfd.RemoteSessionState is Up, Demand mode is active on the remote 1608 system and the local system MUST cease the periodic transmission 1609 of BFD Control packets (see section 6.8.7.) 1611 If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or 1612 bfd.RemoteSessionState is not Up, Demand mode is not active on the 1613 remote system and the local system MUST send periodic BFD Control 1614 packets (see section 6.8.7.) 1616 If the Poll (P) bit is set, send a BFD Control packet to the 1617 remote system with the Poll (P) bit clear, and the Final (F) bit 1618 set (see section 6.8.7.) 1620 If the packet was not discarded, it has been received for purposes 1621 of the Detection Time expiration rules in section 6.8.4. 1623 6.8.7. Transmitting BFD Control Packets 1625 BFD Control packets MUST be transmitted periodically at the rate 1626 determined according to section 6.8.2, except as specified in this 1627 section. 1629 The transmit interval MUST be recalculated whenever 1630 bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval 1631 changes, and is equal to the greater of those two values. See 1632 sections 6.8.2 and 6.8.3 for details on transmit timers. 1634 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 1635 zero and the system is taking the Passive role. 1637 A system MUST NOT periodically transmit BFD Control packets if 1638 bfd.RemoteMinRxInterval is zero. 1640 A system MUST NOT periodically transmit BFD Control packets if Demand 1641 mode is active on the remote system (bfd.RemoteDemandMode is 1, 1642 bfd.SessionState is Up, and bfd.RemoteSessionState is Up) and a Poll 1643 Sequence is not being transmitted. 1645 If a BFD Control packet is received with the Poll (P) bit set to 1, 1646 the receiving system MUST transmit a BFD Control packet with the Poll 1647 (P) bit clear and the Final (F) bit set as soon as practicable, 1648 without respect to the transmission timer or any other transmission 1649 limitations, without respect to the session state, and without 1650 respect to whether Demand mode is active on either system. A system 1651 MAY limit the rate at which such packets are transmitted. If rate 1652 limiting is in effect, the advertised value of Desired Min TX 1653 Interval MUST be greater than or equal to the interval between 1654 transmitted packets imposed by the rate limiting function. 1656 A system MUST NOT set the Demand (D) bit unless bfd.DemandMode is 1, 1657 bfd.SessionState is Up, and bfd.RemoteSessionState is Up. 1659 A BFD Control packet SHOULD be transmitted during the interval 1660 between periodic Control packet transmissions when the contents of 1661 that packet would differ from that in the previously transmitted 1662 packet (other than the Poll and Final bits) in order to more rapidly 1663 communicate a change in state. 1665 The contents of transmitted BFD Control packets MUST be set as 1666 follows: 1668 Version 1670 Set to the current version number (1). 1672 Diagnostic (Diag) 1674 Set to bfd.LocalDiag. 1676 State (Sta) 1678 Set to the value indicated by bfd.SessionState. 1680 Poll (P) 1682 Set to 1 if the local system is sending a Poll Sequence, or 0 if 1683 not. 1685 Final (F) 1687 Set to 1 if the local system is responding to a Control packet 1688 received with the Poll (P) bit set, or 0 if not. 1690 Control Plane Independent (C) 1692 Set to 1 if the local system's BFD implementation is independent 1693 of the control plane (it can continue to function through a 1694 disruption of the control plane.) 1696 Authentication Present (A) 1698 Set to 1 if authentication is in use on this session (bfd.AuthType 1699 is nonzero), or 0 if not. 1701 Demand (D) 1703 Set to bfd.DemandMode if bfd.SessionState is Up and 1704 bfd.RemoteSessionState is Up. Otherwise it is set to 0. 1706 Multipoint (M) 1708 Set to 0. 1710 Detect Mult 1712 Set to bfd.DetectMult. 1714 Length 1716 Set to the appropriate length, based on the fixed header length 1717 (24) plus any Authentication Section. 1719 My Discriminator 1721 Set to bfd.LocalDiscr. 1723 Your Discriminator 1725 Set to bfd.RemoteDiscr. 1727 Desired Min TX Interval 1729 Set to bfd.DesiredMinTxInterval. 1731 Required Min RX Interval 1733 Set to bfd.RequiredMinRxInterval. 1735 Required Min Echo RX Interval 1737 Set to the minimum required Echo packet receive interval for this 1738 session. If this field is set to zero, the local system is 1739 unwilling or unable to loop back BFD Echo packets to the remote 1740 system, and the remote system will not send Echo packets. 1742 Authentication Section 1744 Included and set according to the rules in section 6.7 if 1745 authentication is in use (bfd.AuthType is nonzero.) Otherwise 1746 this section is not present. 1748 6.8.8. Reception of BFD Echo Packets 1750 A received BFD Echo packet MUST be demultiplexed to the appropriate 1751 session for processing. A means of detecting missing Echo packets 1752 MUST be implemented, which most likely involves processing of the 1753 Echo packets that are received. The processing of received Echo 1754 packets is otherwise outside the scope of this specification. 1756 6.8.9. Transmission of BFD Echo Packets 1758 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 1759 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 1760 Control packet received from the remote system contains a nonzero 1761 value in Required Min Echo RX Interval. 1763 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 1764 interval between transmitted BFD Echo packets MUST NOT be less than 1765 the value advertised by the remote system in Required Min Echo RX 1766 Interval, except as follows: 1768 A 25% jitter MAY be applied to the rate of transmission, such that 1769 the actual interval MAY be between 75% and 100% of the advertised 1770 value. A single BFD Echo packet MAY be transmitted between 1771 normally scheduled Echo transmission intervals. 1773 The transmission of BFD Echo packets is otherwise outside the scope 1774 of this specification. 1776 6.8.10. Min Rx Interval Change 1778 When it is desired to change the rate at which BFD Control packets 1779 arrive from the remote system, bfd.RequiredMinRxInterval can be 1780 changed at any time to any value. The new value will be transmitted 1781 in the next outgoing Control packet, and the remote system will 1782 adjust accordingly. See section 6.8.3 for further requirements. 1784 6.8.11. Min Tx Interval Change 1786 When it is desired to change the rate at which BFD Control packets 1787 are transmitted to the remote system (subject to the requirements of 1788 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1789 any time to any value. The rules in section 6.8.3 apply. 1791 6.8.12. Detect Multiplier Change 1793 When it is desired to change the detect multiplier, the value of 1794 bfd.DetectMult can be changed to any nonzero value. The new value 1795 will be transmitted with the next BFD Control packet, and the use of 1796 a Poll Sequence is not necessary. See section 6.6 for additional 1797 requirements. 1799 6.8.13. Enabling or Disabling The Echo Function 1801 If it is desired to start or stop the transmission of BFD Echo 1802 packets, this MAY be done at any time (subject to the transmission 1803 requirements detailed in section 6.8.9.) 1805 If it is desired to enable or disable the looping back of received 1806 BFD Echo packets, this MAY be done at any time by changing the value 1807 of Required Min Echo RX Interval to zero or nonzero in outgoing BFD 1808 Control packets. 1810 6.8.14. Enabling or Disabling Demand Mode 1812 If it is desired to start or stop Demand mode, this MAY be done at 1813 any time by setting bfd.DemandMode to the proper value. Demand mode 1814 will subsequently become active under the rules described in section 1815 6.6. 1817 If Demand mode is no longer active on the remote system, the local 1818 system MUST begin transmitting periodic BFD Control packets as 1819 described in section 6.8.7. 1821 6.8.15. Forwarding Plane Reset 1823 When the forwarding plane in the local system is reset for some 1824 reason, such that the remote system can no longer rely on the local 1825 forwarding state, the local system MUST set bfd.LocalDiag to 4 1826 (Forwarding Plane Reset), and set bfd.SessionState to Down. 1828 6.8.16. Administrative Control 1830 There may be circumstances where it is desirable to administratively 1831 enable or disable a BFD session. When this is desired, the following 1832 procedure MUST be followed: 1834 If enabling session 1835 Set bfd.SessionState to Down 1837 Else 1838 Set bfd.SessionState to AdminDown 1839 Set bfd.LocalDiag to an appropriate value 1840 Cease the transmission of BFD Echo packets 1842 If signaling is received from outside BFD that the underlying path 1843 has failed, an implementation MAY administratively disable the 1844 session with the diagnostic Path Down. 1846 Other scenarios MAY use the diagnostic Administratively Down. 1848 BFD Control packets SHOULD be transmitted for at least a Detection 1849 Time after transitioning to AdminDown state in order to ensure that 1850 the remote system is aware of the state change. BFD Control packets 1851 MAY be transmitted indefinitely after transitioning to AdminDown 1852 state in order to maintain session state in each system (see section 1853 6.8.18 below.) 1855 6.8.17. Concatenated Paths 1857 If the path being monitored by BFD is concatenated with other paths, 1858 it may be desirable to propagate the indication of a failure of one 1859 of those paths across the BFD session (providing an interworking 1860 function for liveness monitoring between BFD and other technologies.) 1862 Two diagnostic codes are defined for this purpose: Concatenated Path 1863 Down and Reverse Concatenated Path Down. The first propagates 1864 forward path failures (in which the concatenated path fails in the 1865 direction toward the interworking system), and the second propagates 1866 reverse path failures (in which the concatenated path fails in the 1867 direction away from the interworking system, assuming a bidirectional 1868 link.) 1870 A system MAY signal one of these failure states by simply setting 1871 bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD 1872 session is not taken down. If Demand mode is not active on the 1873 remote system, no other action is necessary, as the diagnostic code 1874 will be carried via the periodic transmission of BFD Control packets. 1875 If Demand mode is active on the remote system (the local system is 1876 not transmitting periodic BFD Control packets), a Poll Sequence MUST 1877 be initiated to ensure that the diagnostic code is transmitted. Note 1878 that if the BFD session subsequently fails, the diagnostic code will 1879 be overwritten with a code detailing the cause of the failure. It is 1880 up to the interworking agent to perform the above procedure again, 1881 once the BFD session reaches Up state, if the propagation of the 1882 concatenated path failure is to resume. 1884 6.8.18. Holding Down Sessions 1886 A system MAY choose to prevent a BFD session from being established. 1887 One possible reason might be to manage the rate at which sessions are 1888 established. This can be done by holding the session in Down or 1889 AdminDown state, as appropriate. 1891 There are two related mechanisms that are available to help with this 1892 task. First, a system is REQUIRED to maintain session state 1893 (including timing parameters), even when a session is down, until a 1894 Detection Time has passed without the receipt of any BFD Control 1895 packets. This means that a system may take down a session and 1896 transmit an arbitrarily large value in the Required Min RX Interval 1897 field to control the rate at which it receives packets. 1899 Additionally, a system MAY transmit a value of zero for Required Min 1900 RX Interval to indicate that the remote system should send no packets 1901 whatsoever. 1903 So long as the local system continues to transmit BFD Control 1904 packets, the remote system is obligated to obey the value carried in 1905 Required Min RX Interval. If the remote system does not receive any 1906 BFD Control packets for a Detection Time, it resets 1907 bfd.RemoteMinRxIvl to a small value and then can transmit at its own 1908 rate. 1910 7. Operational Considerations 1912 BFD is likely to be deployed as a critical part of network 1913 infrastructure. As such, care should be taken to avoid disruption. 1915 Obviously, any mechanism that blocks BFD packets, such as firewalls 1916 or other policy processes, will cause BFD to fail. 1918 Mechanisms that control packet scheduling, such as policers, traffic 1919 shapers, priority queueing, etc., have the potential of impacting BFD 1920 operations if the Detection Time is similar in scale to the scheduled 1921 packet transmit or receive rate. The delivery of BFD packets is 1922 time-critical, relative to the magnitude of the Detection Time, so 1923 this may need to be taken into account in implementation and 1924 deployment, particularly when very short Detection Times are to be 1925 used. 1927 8. IANA Considerations 1929 This document defines two registries to be administered by IANA. The 1930 first is entitled "BFD Diagnostic Codes" (see section 4.1). Initial 1931 values for the BFD Diagnostic Code registry are given below. Further 1932 assignments are to be made through Expert Review [IANA- 1933 CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name 1934 and its associated value. 1936 Value BFD Diagnostic Code Name 1937 ----- ------------------------ 1938 0 No Diagnostic 1939 1 Control Detection Time Expired 1940 2 Echo Function Failed 1941 3 Neighbor Signaled Session Down 1942 4 Forwarding Plane Reset 1943 5 Path Down 1944 6 Concatenated Path Down 1945 7 Administratively Down 1946 8 Reverse Concatenated Path Down 1947 9-31 Reserved 1949 The second registry is entitled "BFD Authentication Types" (see section 1950 4.1). Initial values for the BFD Authentication Type registry are given 1951 below. Further assignments are to be made through Expert Review 1952 [IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type 1953 Code name and its associated value. 1955 Value BFD Diagnostic Code Name 1956 ----- ------------------------ 1957 0 Reserved 1958 1 Simple Password 1959 2 Keyed MD5 1960 3 Meticulous Keyed MD5 1961 4 Keyed SHA1 1962 5 Meticulous Keyed SHA1 1963 6-255 Reserved 1965 9. Security Considerations 1967 As BFD may be tied into the stability of the network infrastructure 1968 (such as routing protocols), the effects of an attack on a BFD 1969 session may be very serious. This ultimately has denial-of-service 1970 effects, as links may be declared to be down (or falsely declared to 1971 be up.) 1973 When BFD is run over network layer protocols, a significant denial- 1974 of-service risk is created, as BFD packets may be trivial to spoof. 1975 When the session is directly connected across a single link 1976 (physical, or a secure tunnel such as IPsec), the TTL or Hop Count 1977 MUST be set to the maximum on transmit, and checked to be equal to 1978 the maximum value on reception (and the packet dropped if this is not 1979 the case.) See [GTSM] for more information on this technique. If 1980 BFD is run across multiple hops or an insecure tunnel (such as GRE), 1981 the Authentication Section SHOULD be utilized. 1983 The level of security provided by the Authentication Section varies 1984 based on the authentication type used. Simple Password 1985 authentication is obviously only as secure as the secrecy of the 1986 passwords used, and should be considered only if the BFD session is 1987 guaranteed to be run over an infrastructure not subject to packet 1988 interception. Its chief advantage is that it minimizes the 1989 computational effort required for authentication. 1991 Keyed MD5 authentication is much stronger than Simple Password 1992 authentication since the keys cannot be discerned by intercepting 1993 packets. It is vulnerable to replay attacks in between increments of 1994 the sequence number. The sequence number can be incremented as 1995 seldom (or as often) as desired, trading off resistance to replay 1996 attacks with the computational effort required for authentication. 1998 Meticulous Keyed MD5 authentication is stronger yet, as it requires 1999 the sequence number to be incremented for every packet. Replay 2000 attack vulnerability is reduced due to the requirement that the 2001 sequence number must be incremented on every packet, the window size 2002 of acceptable packets is small, and the initial sequence number is 2003 randomized. There is still a window of attack at the beginning of 2004 the session while the sequence number is being determined. This 2005 authentication scheme requires an MD5 calculation on every packet 2006 transmitted and received. 2008 Using SHA1 is believed to have stronger security properties than MD5. 2009 All comments about MD5 in this section also apply to SHA1. 2011 If both systems randomize their Local Discriminator values at the 2012 beginning of a session, replay attacks may be further mitigated, 2013 regardless of the authentication type in use. Since the Local 2014 Discriminator may be changed at any time during a session, this 2015 mechanism may also help mitigate attacks. 2017 10. References 2019 10.1. Normative References 2021 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 2022 (GTSM)", RFC 5082, October 2007. 2024 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 2025 Requirement Levels", RFC 2119, March 1997. 2027 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 2028 1992. 2030 [SHA1] Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, 2031 September 2001. 2033 10.2. Informative References 2035 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 2036 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2037 2434, October 1998. 2039 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 2041 Backward Compatibility (Non-Normative) 2043 Although Version 0 of this document is unlikely to have been deployed 2044 widely, some implementors may wish to have a backward compatibility 2045 mechanism. Note that any mechanism may be potentially used that does 2046 not alter the protocol definition, so interoperability should not be 2047 an issue. 2049 The suggested mechanism described here has the property that it will 2050 converge on version 1 if both systems implement it, even if one 2051 system is upgraded from version 0 within a Detection Time. It will 2052 interoperate with a system that implements only one version (or is 2053 configured to support only one version.) A system should obviously 2054 not perform this function if it is configured to or is only capable 2055 of using a single version. 2057 A BFD session will enter a "negotiation holddown" if it is configured 2058 for automatic versioning and either has just started up, or the 2059 session has been manually cleared. The session is set to AdminDown 2060 state and Version 1. During the holddown period, which lasts for one 2061 Detection Time, the system sends BFD Control packets as usual, but 2062 ignores received packets. After the holddown time is complete, the 2063 state transitions to Down and normal operation resumes. 2065 When a system is not in holddown, if it doing automatic versioning 2066 and is currently using Version 1, if any Version 0 packet is received 2067 for the session, it switches immediately to Version 0. If it is 2068 currently using Version 0 and a Version 1 packet is received that 2069 indicates that the neighbor is in state AdminDown, it switches to 2070 Version 1. If using Version 0 and a Version 1 packet is received 2071 indicating a state other than AdminDown, the packet is ignored (per 2072 spec.) 2074 If the version being used is changed, the session goes down as 2075 appropriate for the new version (Down state for Version 1 or Failing 2076 state for Version 0.) 2078 Contributors 2080 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 2081 significant contributors to this document. 2083 Acknowledgments 2085 This document was inspired by (and is intended to replace) the 2086 Protocol Liveness Protocol draft, written by Kireeti Kompella. 2088 Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 2089 et al. 2091 The authors would also like to thank Mike Shand, John Scudder, 2092 Stewart Bryant, Pekka Savola, and Richard Spencer for their 2093 substantive input. 2095 The authors would also like to thank Owen Wheeler for hosting 2096 teleconferences between the authors of this specification and 2097 multiple vendors in order address implementation and clarity issues. 2099 Authors' Addresses 2101 Dave Katz 2102 Juniper Networks 2103 1194 N. Mathilda Ave. 2104 Sunnyvale, California 94089-1206 USA 2105 Phone: +1-408-745-2000 2106 Email: dkatz@juniper.net 2108 Dave Ward 2109 Cisco Systems 2110 170 W. Tasman Dr. 2111 San Jose, CA 95134 USA 2112 Phone: +1-408-526-4000 2113 Email: dward@cisco.com 2115 Changes from the Previous Draft 2117 A note was added about the availability of the timer mechanism for 2118 congestion control. Text was added about the need for out-of-band 2119 negotiation of authentication parameters. The sequence number check 2120 was moved before the digest/hash calculation (this is a backward 2121 compatible change.) An Operational Considerations section was added. 2122 All other changes are purely editorial in nature. 2124 This document expires in August, 2009.