idnits 2.17.1 draft-ietf-bfd-base-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1883. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1887), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KEYWORDS' is mentioned on line 52, but not defined == Unused Reference: 'KEYWORD' is defined on line 1824, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3682 (ref. 'GTSM') (Obsoleted by RFC 5082) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 D. Ward 5 Cisco Systems 6 Expires: April, 2006 October, 2005 8 Bidirectional Forwarding Detection 9 draft-ietf-bfd-base-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This document describes a protocol intended to detect faults in the 41 bidirectional path between two forwarding engines, including 42 interfaces, data link(s), and to the extent possible the forwarding 43 engines themselves, with potentially very low latency. It operates 44 independently of media, data protocols, and routing protocols. 45 Comments on this draft should be directed to rtg-bfd@ietf.org. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1 Addressing and Session Establishment . . . . . . . . . . . 5 59 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 5 60 4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7 61 4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 62 4.2 Simple Password Authentication Section Format . . . . . 11 63 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 64 Section Format . . . . . . . . . . . . . . . . . . . . . 12 65 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 66 Section Format . . . . . . . . . . . . . . . . . . . . . 13 67 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 14 68 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 15 69 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 16 71 6.3 Demultiplexing and the Discriminator Fields . . . . . . 18 72 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 18 73 6.5 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 19 74 6.6 Authentication . . . . . . . . . . . . . . . . . . . . . 20 75 6.6.1 Enabling and Disabling Authentication . . . . . . 20 76 6.6.2 Simple Password Authentication . . . . . . . . . . 21 77 6.6.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 22 78 6.6.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 23 79 6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 25 80 6.7.1 State Variables . . . . . . . . . . . . . . . . . 25 81 6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 28 82 6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 29 83 6.7.4 Calculating the Detection Time . . . . . . . . . . 30 84 6.7.5 Detecting Failures with the Echo Function . . . . 31 85 6.7.6 Reception of BFD Control Packets . . . . . . . . . 31 86 6.7.7 Transmitting BFD Control Packets . . . . . . . . . 33 87 6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 36 88 6.7.9 Reception of BFD Echo Packets . . . . . . . . . . 36 89 6.7.10 Transmission of BFD Echo Packets . . . . . . . . 37 90 6.7.11 Min Rx Interval Change . . . . . . . . . . . . . 37 91 6.7.12 Min Tx Interval Change . . . . . . . . . . . . . 37 92 6.7.13 Detect Multiplier Change . . . . . . . . . . . . 37 93 6.7.14 Enabling or Disabling the Echo Function . . . . . 38 94 6.7.15 Enabling or Disabling Demand Mode . . . . . . . . 38 95 6.7.16 Forwarding Plane Reset . . . . . . . . . . . . . 38 96 6.7.17 Administrative Control . . . . . . . . . . . . . 38 97 6.7.18 Concatenated Paths . . . . . . . . . . . . . . . 39 98 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 39 99 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 40 100 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 101 Security Considerations . . . . . . . . . . . . . . . . . . . . 41 102 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 42 103 Normative References . . . . . . . . . . . . . . . . . . . . . 42 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42 105 Changes from the previous draft . . . . . . . . . . . . . . . . 43 106 IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 43 108 1. Introduction 110 An increasingly important feature of networking equipment is the 111 rapid detection of communication failures between adjacent systems, 112 in order to more quickly establish alternative paths. Detection can 113 come fairly quickly in certain circumstances when data link hardware 114 comes into play (such as SONET alarms.) However, there are media 115 that do not provide this kind of signaling (such as Ethernet), and 116 some media may not detect certain kinds of failures in the path, for 117 example, failing interfaces or forwarding engine components. 119 Networks use relatively slow "Hello" mechanisms, usually in routing 120 protocols, to detect failures when there is no hardware signaling to 121 help out. The time to detect failures ("detection times") available 122 in the existing protocols are no better than a second, which is far 123 too long for some applications and represents a great deal of lost 124 data at gigabit rates. Furthermore, routing protocol Hellos are of 125 no help when those routing protocols are not in use, and the 126 semantics of detection are subtly different--they detect a failure in 127 the path between the two routing protocol engines. 129 The goal of BFD is to provide low-overhead, short-duration detection 130 of failures in the path between adjacent forwarding engines, 131 including the interfaces, data link(s), and to the extent possible 132 the forwarding engines themselves. 134 An additional goal is to provide a single mechanism that can be used 135 for liveness detection over any media, at any protocol layer, with a 136 wide range of detection times and overhead, to avoid a proliferation 137 of different methods. 139 This document specifies the details of the base protocol. The use of 140 some mechanisms are application dependent and are specified in a 141 separate series of application documents. These issues are so noted. 143 Note that many of the exact mechanisms are implementation dependent 144 and will not affect interoperability, and are thus outside the scope 145 of this specification. Those issues are so noted. 147 2. Design 149 BFD is designed to detect failures in communication with a forwarding 150 plane next hop. It is intended to be implemented in some component 151 of the forwarding engine of a system, in cases where the forwarding 152 and control engines are separated. This not only binds the protocol 153 more to the forwarding plane, but decouples the protocol from the 154 fate of the routing protocol engine, making it useful in concert with 155 various "graceful restart" mechanisms for those protocols. BFD may 156 also be implemented in the control engine, though doing so may 157 preclude the detection of some kinds of failures. 159 BFD operates on top of any data protocol being forwarded between two 160 systems. It is always run in a unicast, point-to-point mode. BFD 161 packets are carried as the payload of whatever encapsulating protocol 162 is appropriate for the medium and network. BFD may be running at 163 multiple layers in a system. The context of the operation of any 164 particular BFD session is bound to its encapsulation. 166 BFD can provide failure detection on any kind of path between 167 systems, including direct physical links, virtual circuits, tunnels, 168 MPLS LSPs, multihop routed paths, and unidirectional links (so long 169 as there is some return path, of course.) Multiple BFD sessions can 170 be established between the same pair of systems when multiple paths 171 between them are present in at least one direction, even if a lesser 172 number of paths are available in the other direction (multiple 173 parallel unidirectional links or MPLS LSPs, for example.) 175 The BFD state machine implements a three-way handshake, both when 176 establishing a BFD session and when tearing it down for any reason, 177 to ensure that both systems are aware of the state change. 179 BFD can be abstracted as a simple service. The service primitives 180 provided by BFD are to create, destroy, and modify a session, given 181 the destination address and other parameters. BFD in return provides 182 a signal to its clients indicating when the BFD session goes up or 183 down. 185 3. Protocol Overview 187 BFD is a simple hello protocol that in many respects is similar to 188 the detection components of well-known routing protocols. A pair of 189 systems transmit BFD packets periodically over each path between the 190 two systems, and if a system stops receiving BFD packets for long 191 enough, some component in that particular bidirectional path to the 192 neighboring system is assumed to have failed. Under some conditions, 193 systems may negotiate to not send periodic BFD packets in order to 194 reduce overhead. 196 A path is only declared to be operational when two-way communication 197 has been established between systems, though this does not preclude 198 the use of unidirectional links. 200 A separate BFD session is created for each communications path and 201 data protocol in use between two systems. 203 Each system estimates how quickly it can send and receive BFD packets 204 in order to come to an agreement with its neighbor about how rapidly 205 detection of failure will take place. These estimates can be 206 modified in real time in order to adapt to unusual situations. This 207 design also allows for fast systems on a shared medium with a slow 208 system to be able to more rapidly detect failures between the fast 209 systems while allowing the slow system to participate to the best of 210 its ability. 212 3.1. Addressing and Session Establishment 214 A BFD session is established based on the needs of the application 215 that will be making use of it. It is up to the application to 216 determine the need for BFD, and the addresses to use--there is no 217 discovery mechanism in BFD. For example, an OSPF [OSPF] 218 implementation may request a BFD session to be established to a 219 neighbor discovered using the OSPF Hello protocol. 221 3.2. Operating Modes 223 BFD has two operating modes which may be selected, as well as an 224 additional function that can be used in combination with the two 225 modes. 227 The primary mode is known as Asynchronous mode. In this mode, the 228 systems periodically send BFD Control packets to one another, and if 229 a number of those packets in a row are not received by the other 230 system, the session is declared to be down. 232 The second mode is known as Demand mode. In this mode, it is assumed 233 that each system has an independent way of verifying that it has 234 connectivity to the other system. Once a BFD session is established, 235 the systems stop sending BFD Control packets, except when either 236 system feels the need to verify connectivity explicitly, in which 237 case a short sequence of BFD Control packets is sent, and then the 238 protocol quiesces. 240 An adjunct to both modes is the Echo function. When the Echo 241 function is active, a stream of BFD Echo packets is transmitted in 242 such a way as to have the other system loop them back through its 243 forwarding path. If a number of packets of the echoed data stream 244 are not received, the session is declared to be down. The Echo 245 function may be used with either Asynchronous or Demand modes. Since 246 the Echo function is handling the task of detection, the rate of 247 periodic transmission of Control packets may be reduced (in the case 248 of Asynchronous mode) or eliminated completely (in the case of Demand 249 mode.) 251 Pure asynchronous mode is advantageous in that it requires half as 252 many packets to achieve a particular detection time as does the Echo 253 function. It is also used when the Echo function cannot be supported 254 for some reason. 256 The Echo function has the advantage of truly testing only the 257 forwarding path on the remote system. This may reduce round-trip 258 jitter and thus allow more aggressive detection times, as well as 259 potentially detecting some classes of failure that might not 260 otherwise be detected. 262 The Echo function may be enabled individually in each direction. It 263 is enabled in a particular direction only when the system that loops 264 the Echo packets back signals that it will allow it, and when the 265 system that sends the Echo packets decides it wishes to. 267 Demand mode is useful in situations where the overhead of a periodic 268 protocol might prove onerous, such as a system with a very large 269 number of BFD sessions. It is also useful when the Echo function is 270 being used symmetrically. Demand mode has the disadvantage that 271 detection times are essentially driven by the heuristics of the 272 system implementation and are not known to the BFD protocol. Demand 273 mode also may not be used when the path round trip time is greater 274 than the desired detection time. See section 6.5 for more details. 276 4. BFD Control Packet Format 278 4.1. Generic BFD Control Packet Format 280 BFD Control packets are sent in an encapsulation appropriate to the 281 environment. The specific encapsulation is outside of the scope of 282 this document. See the appropriate application document for 283 encapsulation details. 285 The BFD Control packet has a Mandatory Section and an optional 286 Authentication Section. The format of the Authentication Section, if 287 present, is dependent on the type of authentication in use. 289 The Mandatory Section of a BFD Control packet has the following 290 format: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 |Vers | Diag |Sta|P|F|C|A|D|R| Detect Mult | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | My Discriminator | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Your Discriminator | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Desired Min TX Interval | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Required Min RX Interval | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Required Min Echo RX Interval | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 An optional Authentication Section may be present: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Auth Type | Auth Len | Authentication Data... | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Version (Vers) 318 The version number of the protocol. This document defines 319 protocol version 1. 321 Diagnostic (Diag) 323 A diagnostic code specifying the local system's reason for the 324 last session state change. Values are: 326 0 -- No Diagnostic 327 1 -- Control Detection Time Expired 328 2 -- Echo Function Failed 329 3 -- Neighbor Signaled Session Down 330 4 -- Forwarding Plane Reset 331 5 -- Path Down 332 6 -- Concatenated Path Down 333 7 -- Administratively Down 334 8 -- Reverse Concatenated Path Down 335 9-31 -- Reserved for future use 337 This field allows remote systems to determine the reason that the 338 previous session failed, for example. 340 State (Sta) 342 The current BFD session state as seen by the transmitting system. 343 Values are: 345 0 -- AdminDown 346 1 -- Down 347 2 -- Init 348 3 -- Up 350 Poll (P) 352 If set, the transmitting system is requesting verification of 353 connectivity, or of a parameter change. If clear, the 354 transmitting system is not requesting verification. 356 Final (F) 358 If set, the transmitting system is responding to a received BFD 359 Control packet that had the Poll (P) bit set. If clear, the 360 transmitting system is not responding to a Poll. 362 Control Plane Independent (C) 364 If set, the transmitting system's BFD implementation does not 365 share fate with its control plane (in other words, BFD is 366 implemented in the forwarding plane and can continue to function 367 through disruptions in the control plane.) If clear, the 368 transmitting system's BFD implementation shares fate with its 369 control plane. 371 The use of this bit is application dependent and is outside the 372 scope of this specification. See specific application 373 specifications for details. 375 Authentication Present (A) 377 If set, the Authentication Section is present and the session is 378 to be authenticated. 380 Demand (D) 382 If set, the transmitting system wishes to operate in Demand Mode. 383 If clear, the transmitting system does not wish to or is not 384 capable of operating in Demand Mode. 386 Reserved (R) 388 This bit must be zero on transmit, and ignored on receipt. 390 Detect Mult 392 Detect time multiplier. The negotiated transmit interval, 393 multiplied by this value, provides the detection time for the 394 transmitting system in Asynchronous mode. 396 Length 398 Length of the BFD Control packet, in bytes. 400 My Discriminator 402 A unique, nonzero discriminator value generated by the 403 transmitting system, used to demultiplex multiple BFD sessions 404 between the same pair of systems. 406 Your Discriminator 408 The discriminator received from the corresponding remote system. 409 This field reflects back the received value of My Discriminator, 410 or is zero if that value is unknown. 412 Desired Min TX Interval 414 This is the minimum interval, in microseconds, that the local 415 system would like to use when transmitting BFD Control packets. 417 Required Min RX Interval 419 This is the minimum interval, in microseconds, between received 420 BFD Control packets that this system is capable of supporting. 422 Required Min Echo RX Interval 424 This is the minimum interval, in microseconds, between received 425 BFD Echo packets that this system is capable of supporting. If 426 this value is zero, the transmitting system does not support the 427 receipt of BFD Echo packets. 429 Auth Type 431 The authentication type in use, if the Authentication Present (A) 432 bit is set. 434 0 - Reserved 435 1 - Simple Password 436 2 - Keyed MD5 437 3 - Meticulous Keyed MD5 438 4 - Keyed SHA1 439 5 - Meticulous Keyed SHA1 440 6-255 - Reserved for future use 442 Auth Len 444 The length, in bytes, of the authentication section, including the 445 Auth Type and Auth Len fields. 447 4.2. Simple Password Authentication Section Format 449 If the Autentication Present (A) bit is set in the header, and the 450 Authentication Type field contains 1 (Simple Password), the 451 Authentication Section has the following format: 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Auth Type | Auth Len | Auth Key ID | Password... | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | ... | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Auth Type 463 The Authentication Type, which in this case is 1 (Simple 464 Password.) 466 Auth Len 468 The length of the Authentication Section, in bytes. For Simple 469 Password authentication, the length is equal to the password 470 length plus three. 472 Auth Key ID 474 The authentication key ID in use for this packet. This allows 475 multiple keys to be active simultaneously. 477 Password 479 The simple password in use on this session. The password MUST be 480 from 1 to 16 bytes in length. 482 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 484 If the Authentication Present (A) bit is set in the header, and the 485 Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous 486 Keyed MD5), the Authentication Section has the following format: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Auth Type | Auth Len | Auth Key ID | Reserved | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Sequence Number | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Auth Key/Checksum... | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | ... | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Auth Type 502 The Authentication Type, which in this case is 2 (Keyed MD5) or 3 503 (Meticulous Keyed MD5). 505 Auth Len 507 The length of the Authentication Section, in bytes. For Keyed MD5 508 and Meticulous Keyed MD5 authentication, the length is 24. 510 Auth Key ID 512 The authentication key ID in use for this packet. This allows 513 multiple keys to be active simultaneously. 515 Reserved 517 This byte must be set to zero on transmit, and ignored on receipt. 519 Sequence Number 521 The Sequence Number for this packet. For Keyed MD5 522 Authentication, this value is incremented occasionally. For 523 Meticulous Keyed MD5 Authentication, this value is incremented for 524 each successive packet transmitted for a session. This provides 525 protection against replay attacks. 527 Auth Key/Checksum 529 This field carries the 16 byte MD5 checksum for the packet. When 530 the checksum is calculated, the shared MD5 key is stored in this 531 field. (See section 6.6.3 for details.) 533 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 535 If the Authentication Present (A) bit is set in the header, and the 536 Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous 537 Keyed SHA1), the Authentication Section has the following format: 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Auth Type | Auth Len | Auth Key ID | Reserved | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Sequence Number | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Auth Key/Checksum... | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | ... | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Auth Type 553 The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 554 (Meticulous Keyed SHA1). 556 Auth Len 558 The length of the Authentication Section, in bytes. For Keyed 559 SHA1 and Meticulous Keyed SHA1 authentication, the length is 28. 561 Auth Key ID 563 The authentication key ID in use for this packet. This allows 564 multiple keys to be active simultaneously. 566 Reserved 568 This byte must be set to zero on transmit, and ignored on receipt. 570 Sequence Number 572 The Sequence Number for this packet. For Keyed SHA1 573 Authentication, this value is incremented occasionally. For 574 Meticulous Keyed SHA1 Authentication, this value is incremented 575 for each successive packet transmitted for a session. This 576 provides protection against replay attacks. 578 Auth Key/Checksum 580 This field carries the 20 byte SHA1 checksum for the packet. When 581 the checksum is calculated, the shared SHA1 key is stored in this 582 field. (See section 6.6.4 for details.) 584 5. BFD Echo Packet Format 586 BFD Echo packets are sent in an encapsulation appropriate to the 587 environment. See the appropriate application documents for the 588 specifics of particular environments. 590 The payload of a BFD Echo packet is a local matter, since only the 591 sending system ever processes the content. The only requirement is 592 that sufficient information is included to demultiplex the received 593 packet to the correct BFD session after it is looped back to the 594 sender. The contents are otherwise outside the scope of this 595 specification. 597 6. Elements of Procedure 599 This section discusses the normative requirements of the protocol in 600 order to achieve interoperability. It is important for implementors 601 to enforce only the requirements specified in this section, as 602 misguided pedantry has been proven by experience to adversely affect 603 interoperability. 605 Remember that all references of the form "bfd.Xx" refer to internal 606 state variables (defined in section 6.7.1), whereas all references to 607 "the Xxx field" refer to fields in the protocol packets themselves 608 (defined in section 4). 610 6.1. Overview 612 A system may take either an Active role or a Passive role in session 613 initialization. A system taking the Active role MUST send BFD 614 Control packets for a particular session, regardless of whether it 615 has received any BFD packets for that session. A system taking the 616 Passive role MUST NOT begin sending BFD packets for a particular 617 session until it has received a BFD packet for that session, and thus 618 has learned the remote system's discriminator value. At least one 619 system MUST take the Active role (possibly both.) The role that a 620 system takes is specific to the application of BFD, and is outside 621 the scope of this specification. 623 A session begins with the periodic, slow transmission of BFD Control 624 packets. When bidirectional communication is achieved, the BFD 625 session comes Up. 627 Once the BFD session is Up, a system can choose to start the Echo 628 function if it desires to and the other system signals that it will 629 allow it. The rate of transmission of Control packets is typically 630 kept low when the Echo function is active. 632 If the Echo function is not active, the transmission rate of Control 633 packets may be increased to a level necessary to achieve the 634 detection time requirements for the session. 636 If both systems signal that they want to use Demand mode, the 637 transmission of BFD Control packets ceases once the session is Up. 638 Other means of implying connectivity are used to keep the session 639 alive. If one of the systems wishes to verify connectivity, it can 640 initiate a short exchange (a "Poll Sequence") of BFD Control packets 641 to verify this. 643 If Demand mode is not active, and no Control packets are received in 644 the calculated detection time (see section 6.7.4), the session is 645 declared Down. This is signalled to the remote end via the State 646 (Sta) field in outgoing packets. 648 If sufficient Echo packets are lost, the session is declared down in 649 the same manner. See section 6.7.5. 651 If Demand mode is active and no appropriate Control packets are 652 received in response to a Poll Sequence, the session is declared down 653 in the same manner. See section 6.5. 655 If the session goes down, the transmission of Echo packets (if any) 656 ceases, and the transmission of Control packets goes back to the slow 657 rate. 659 Once a session has been declared down, it cannot come back up until 660 the remote end first signals that it is down (by leaving the Up 661 state), thus implementing a three-way handshake. 663 A session may be kept administratively down by entering the AdminDown 664 state and sending an explanatory diagnostic code in the Diagnostic 665 field. 667 6.2. BFD State Machine 669 The BFD state machine is quite straightforward. There are three 670 states through which a session normally proceeds, two for 671 establishing a session (Init and Up) and one for tearing down a 672 session (Down.) This allows a three-way handshake for both session 673 establishment and session teardown (assuring that both systems are 674 aware of all session state changes.) A fourth state (AdminDown) 675 exists so that a session can be administratively put down 676 indefinitely. 678 Each system communicates its session state in the State (Sta) field 679 in the BFD Control packet, and that received state in combination 680 with the local session state drives the state machine. 682 Down state means that the session is down (or has just been created.) 683 A session remains in Down state until the remote system indicates 684 that it agrees that the session is down by sending a BFD Control 685 packet with the State field set to anything other than Up. If that 686 packet signals Down state, the session advances to Init state; if 687 that packet signals Init state, the session advances to Up state. 689 Init state means that the remote system is communicating, and the 690 local system desires to bring the session up, but the remote system 691 does not yet realize it. A session will remain in Init state until 692 either a BFD Control Packet is received that is signalling Init or Up 693 state (in which case the session advances to Up state) or until the 694 detection time expires, meaning that communication with the remote 695 system has been lost (in which case the session advances to Down 696 state.) 698 Up state means that the BFD session has successfully been 699 established, and implies that connectivity between the systems is 700 working. The session will remain in the Up state until either 701 connectivity fails, or the session is taken down administratively. 702 If either the remote system signals Down state, or the detection time 703 expires, the session advances to Down state. 705 AdminDown state means that the session is being held administratively 706 down. This causes the remote system to enter Down state, and remain 707 there until the local system exits AdminDown state. 709 The following diagram provides an overview of the state machine. 710 Transitions involving AdminDown state are deleted for clarity (but 711 are fully specified in section 6.7.6.) The notation on each arc 712 represents the state of the remote system (as received in the State 713 field in the BFD Control packet) or indicates the expiration of the 714 Detection Time. 716 +--+ 717 | | UP 718 | V 719 DOWN +------+ INIT 720 +------------| |------------+ 721 | | DOWN | | 722 | +-------->| |<--------+ | 723 | | +------+ | | 724 | | | | 725 | | | | 726 | | DOWN,| | 727 | |TIMER TIMER| | 728 V | | V 729 +------+ +------+ 730 +----| | | |----+ 731 DOWN| | INIT |--------------------->| UP | |INIT, UP 732 +--->| | INIT, UP | |<---+ 733 +------+ +------+ 735 6.3. Demultiplexing and the Discriminator Fields 737 Since multiple BFD sessions may be running between two systems, there 738 needs to be a mechanism for demultiplexing received BFD packets to 739 the proper session. 741 Each system MUST choose an opaque discriminator value that identifies 742 each session, and which MUST be unique among all BFD sessions on the 743 system. The local discriminator is sent in the My Discriminator 744 field in the BFD Control packet, and is echoed back in the Your 745 Discriminator field of packets sent from the remote end. 747 Once the remote end echoes back the local discriminator, all further 748 received packets are demultiplexed based on the Your Discriminator 749 field only (which means that, among other things, the source address 750 field can change or the interface over which the packets are received 751 can change, but the packets will still be associated with the proper 752 session.) 754 The method of demultiplexing the initial packets (in which Your 755 Discriminator is zero) is application-dependent, and is thus outside 756 the scope of this specification. 758 Note that it is permissible for a system to change its discriminator 759 during a session without affecting the session state, since only that 760 system uses its discriminator for demultiplexing purposes (by having 761 the other system reflect it back.) The implications on an 762 implementation for changing the discriminator value is outside the 763 scope of this specification. 765 6.4. The Echo Function and Asymmetry 767 The Echo function can be run independently in each direction between 768 a pair of systems. For whatever reason, a system may advertise that 769 it is willing to receive (and loop back) Echo packets, but may not 770 wish to ever send any. The fact that a system is sending Echo 771 packets is not directly signalled to the system looping them back. 773 When a system is using the Echo function, it is advantageous to 774 choose a sedate transmission rate for Control packets, since liveness 775 detection is being handled by the Echo packets. This can be 776 controlled by manipulating the Desired Min TX Interval field (see 777 section 6.7.3.) 779 If the Echo function is only being run in one direction, the system 780 not running the Echo function will more likely wish to send fairly 781 rapid Control packets in order to achieve its desired detection time. 783 Since BFD allows independent transmission rates in each direction, 784 this is easily accomplished. 786 A system SHOULD always advertise the lowest value of Required Min RX 787 Interval and Required Min Echo RX Interval that it can under the 788 circumstances, to give the other system more freedom in choosing its 789 transmission rate. Note that a system is committing to be able to 790 receive both streams of packets at the rate it advertises, so this 791 should be taken into account when choosing the values to advertise. 793 6.5. Demand Mode 795 Demand mode is negotiated by virtue of both systems setting the 796 Demand (D) bit in its BFD Control packets. Both systems must request 797 Demand mode for it to become active. 799 Demand mode requires that some other mechanism is used to imply 800 continuing connectivity between the two systems. The mechanism used 801 does not have to be the same in both directions, and is outside of 802 the scope of this specification. One possible mechanism is the 803 receipt of traffic from the remote system; another is the use of the 804 Echo function. 806 Once a BFD session comes up, if Demand mode is active, both systems 807 stop sending periodic BFD Control packets, and depend on the 808 alternative mechanism for maintaining ongoing connectivity. 810 When a system wishes to verify connectivity, it initiates a Poll 811 Sequence. It starts periodically sending BFD Control packets with 812 the Poll (P) bit set, at the negotiated transmission rate. When a 813 system receives such a packet, it immediately replies with a BFD 814 Control packet of its own, with the Poll (P) bit clear, and the Final 815 (F) bit set. The receipt of a reply to a Poll terminates the Poll 816 Sequence. If no response is received to a Poll, the Poll is repeated 817 until the detection time expires, at which point the session is 818 declared to be down. 820 The detection time in Demand mode is calculated differently than in 821 Asynchronous mode; it is based on the transmit rate of the local 822 system, rather than the transmit rate of the remote system. This 823 ensures that the Poll Sequence mechanism works properly. See section 824 6.7.8 for more details. 826 Note that this mechanism requires that the detection time negotiated 827 is greater than the round trip time between the two systems, or the 828 Poll mechanism will always fail. Enforcement of this requirement is 829 outside the scope of this specification. 831 Demand mode MAY be enabled or disabled at any time by setting or 832 clearing the Demand (D) bit in the BFD Control packet, without 833 affecting the BFD session state. 835 Because the underlying detection mechanism is unspecified, and may 836 differ between the two systems, the overall detection time 837 characteristics of the path will not be fully known to either system. 838 The total detection time for a particular system is the sum of the 839 time prior to the initiation of the Poll Sequence, plus the 840 calculated detection time. 842 6.6. Authentication 844 An optional Authentication Section may be present in the BFD Control 845 packet. In its generic form, the purpose of the Authentication 846 Section is to carry all necessary information, based on the 847 authentication type in use, to allow the receiving system to 848 determine the validity of the received packet. The exact mechanism 849 depends on the authentication type in use, but in general the 850 transmitting system will put information in the Authentication 851 Section that vouches for the packet's validity, and the receiving 852 system will examine the Authentication Section and either accept the 853 packet for further processing, or discard it. 855 Note that in the subsections below, to "accept" a packet means only 856 that the packet has passed authentication; it may in fact be 857 discarded for other reasons as described in the general packet 858 reception rules described in section 6.7.6. 860 Implementations supporting authentication MUST support SHA1 861 authentication. Other forms of authentication are optional. 863 6.6.1. Enabling and Disabling Authentication 865 It may be desirable to enable or disable authentication on a session 866 without disturbing the session state. The exact mechanism for doing 867 so is outside the scope of this specification. However, it is useful 868 to point out some issues in supporting this mechanism. 870 In a simple implementation, a BFD session will fail when 871 authentication is either turned on or turned off, because the packet 872 acceptance rules essentially require the local and remote machines to 873 do so in a more or less synchronized fashion (within the detect 874 time)--a packet with authentication will only be accepted if 875 authentication is "in use" (and likewise packets without 876 authentication. 878 One possible approach is to build an implementation such that 879 authentication is configured, but not considered "in use" until the 880 first packet containing a matching authentication section is received 881 (providing the necessary synchronization.) Likewise, authentication 882 could be configured off, but still considered "in use" until the 883 receipt of the first packet without the authentication section. 885 In order to avoid security risks, implementations using this method 886 should only allow the authentication state to be changed once without 887 some form of intervention (so that authentication cannot be turned on 888 and off repeatedly simply based on the receipt of BFD Control packets 889 from remote systems.) 891 6.6.2. Simple Password Authentication 893 The most straightforward (and weakest) form of authentication is 894 Simple Password Authentication. In this method of authentication, 895 one or more Passwords (with corresponding Key IDs) are configured in 896 each system and one of these Password/ID pairs is carried in each BFD 897 Control packet. The receiving system accepts the packet if the 898 Password and Key ID matches one of the Password/ID pairs configured 899 in that system. 901 Transmission Using Simple Password Authentication 903 The currently selected password and Key ID for the session MUST be 904 stored in the Authentication Section of each outgoing BFD Control 905 packet. The Auth Type field MUST be set to 1 (Simple Password.) 906 The Auth Len field MUST be set to the proper length (4 to 19 907 bytes.) 909 Reception Using Simple Password Authentication 911 If the received BFD Control packet does not contain an 912 Authentication Section, or the Auth Type is not 1 (Simple 913 Password), then the received packet MUST be discarded. 915 If the Auth Key ID field does not match the ID of a configured 916 password, the received packet MUST be discarded. 918 If the Auth Len field is not equal to the length of the password 919 selected by the Key ID, plus three, the packet MUST be discarded. 921 If the Password field does not match the password selected by the 922 Key ID, the packet MUST be discarded. 924 Otherwise, the packet MUST be accepted. 926 6.6.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 928 The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are 929 very similar to those used in other protocols. In these methods of 930 authentication, one or more secret keys (with corresponding Key IDs) 931 are configured in each system. One of the Keys is included in an MD5 932 [MD5] checksum calculated over the outgoing BFD Control packet, but 933 the Key itself is not carried in the packet. To help avoid replay 934 attacks, a sequence number is also carried in each packet. For Keyed 935 MD5, the sequence number is occasionally incremented. For Meticulous 936 Keyed MD5, the sequence number is incremented on every packet. 938 The receiving system accepts the packet if the Key ID matches one of 939 the configured Keys, an MD5 checksum including the selected key 940 matches that carried in the packet, and if the sequence number is 941 greater than or equal to the last sequence number received (for Keyed 942 MD5), or strictly greater than the last sequence number received (for 943 Meticulous Keyed MD5.) 945 Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication 947 The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous 948 Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key 949 ID field MUST be set to the ID of the current authentication key. 950 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 952 The current authentication key value MUST be placed into the Auth 953 Key/Checksum field. An MD5 checksum MUST be calculated over the 954 entire BFD control packet. The resulting checksum MUST be stored 955 in the Auth Key/Checksum field prior to transmission (replacing 956 the secret key, which MUST NOT be carried in the packet.) 958 For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular 959 fashion (when treated as an unsigned 32 bit value.) 960 bfd.XmitAuthSeq SHOULD be incremented when the session state 961 changes, or when the transmitted BFD Control packet carries 962 different contents than the previously transmitted packet. The 963 decision as to when to increment bfd.XmitAuthSeq is outside the 964 scope of this specification. See the section entitled "Security 965 Considerations" below for a discussion. 967 For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a 968 circular fashion (when treated as an unsigned 32 bit value.) 970 Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication 972 If the received BFD Control packet does not contain an 973 Authentication Section, or the Auth Type is not correct (2 for 974 Keyed MD5, or 3 for Meticulous Keyed MD5), then the received 975 packet MUST be discarded. 977 If the Auth Key ID field does not match the ID of a configured 978 authentication key, the received packet MUST be discarded. 980 If the Auth Len field is not equal to 24, the packet MUST be 981 discarded. 983 Replace the contents of the Auth Key/Checksum field with the 984 authentication key selected by the received Auth Key ID field. If 985 the MD5 checksum of the entire BFD Control packet is not equal to 986 the received value of the Auth Key/Checksum field, the received 987 packet MUST be discarded. 989 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 990 Keyed MD5, if the Sequence Number lies outside of the range of 991 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 992 treated as an unsigned 32 bit circular number space), the received 993 packet MUST be discarded. For Meticulous Keyed MD5, if the 994 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 995 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 996 unsigned 32 bit circular number space, the received packet MUST be 997 discarded. 999 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1000 1, bfd.RcvAuthSeq MUST be set to the value of the received 1001 Sequence Number field, and the received packet MUST be accepted. 1003 6.6.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1005 The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms 1006 are very similar to those used in other protocols. In these methods 1007 of authentication, one or more secret keys (with corresponding Key 1008 IDs) are configured in each system. One of the Keys is included in a 1009 SHA1 [SHA1] checksum calculated over the outgoing BFD Control packet, 1010 but the Key itself is not carried in the packet. To help avoid 1011 replay attacks, a sequence number is also carried in each packet. 1012 For Keyed SHA1, the sequence number is occasionally incremented. For 1013 Meticulous Keyed SHA1, the sequence number is incremented on every 1014 packet. 1016 The receiving system accepts the packet if the Key ID matches one of 1017 the configured Keys, a SHA1 checksum including the selected key 1018 matches that carried in the packet, and if the sequence number is 1019 greater than or equal to the last sequence number received (for Keyed 1020 SHA1), or strictly greater than the last sequence number received 1021 (for Meticulous Keyed SHA1.) 1023 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 1024 Authentication 1026 The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous 1027 Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key 1028 ID field MUST be set to the ID of the current authentication key. 1029 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1031 The current authentication key value MUST be placed into the Auth 1032 Key/Checksum field. A SHA1 checksum MUST be calculated over the 1033 entire BFD control packet. The resulting checksum MUST be stored 1034 in the Auth Key/Checksum field prior to transmission (replacing 1035 the secret key, which MUST NOT be carried in the packet.) 1037 For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular 1038 fashion (when treated as an unsigned 32 bit value.) 1039 bfd.XmitAuthSeq SHOULD be incremented when the session state 1040 changes, or when the transmitted BFD Control packet carries 1041 different contents than the previously transmitted packet. The 1042 decision as to when to increment bfd.XmitAuthSeq is outside the 1043 scope of this specification. See the section entitled "Security 1044 Considerations" below for a discussion. 1046 For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in 1047 a circular fashion (when treated as an unsigned 32 bit value.) 1049 Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1051 If the received BFD Control packet does not contain an 1052 Authentication Section, or the Auth Type is not correct (4 for 1053 Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received 1054 packet MUST be discarded. 1056 If the Auth Key ID field does not match the ID of a configured 1057 authentication key, the received packet MUST be discarded. 1059 If the Auth Len field is not equal to 28, the packet MUST be 1060 discarded. 1062 Replace the contents of the Auth Key/Checksum field with the 1063 authentication key selected by the received Auth Key ID field. If 1064 the SHA1 checksum of the entire BFD Control packet is not equal to 1065 the received value of the Auth Key/Checksum field, the received 1066 packet MUST be discarded. 1068 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1069 Keyed SHA1, if the Sequence Number lies outside of the range of 1070 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1071 treated as an unsigned 32 bit circular number space), the received 1072 packet MUST be discarded. For Meticulous Keyed SHA1, if the 1073 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1074 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1075 unsigned 32 bit circular number space, the received packet MUST be 1076 discarded. 1078 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1079 1, bfd.RcvAuthSeq MUST be set to the value of the received 1080 Sequence Number field, and the received packet MUST be accepted. 1082 6.7. Functional Specifics 1084 The following section of this specification is normative. The means 1085 by which this specification is achieved is outside the scope of this 1086 specification. 1088 When a system is said to have "the Echo function active," it means 1089 that the system is sending BFD Echo packets, implying that the 1090 session is Up and the other system has signalled its willingness to 1091 loop back Echo packets. 1093 When a system is said to have "Demand mode active," it means that 1094 bfd.DemandModeDesired is 1 in the local system (see State Variables 1095 below), the remote system is signalling with the Demand (D) bit set, 1096 and that the session is Up. 1098 6.7.1. State Variables 1100 A minimum amount of information about a session needs to be tracked 1101 in order to achieve the elements of procedure described here. The 1102 following is a set of state variables that are helpful in describing 1103 the mechanisms of BFD. Any means of tracking this state may be used 1104 so long as the protocol behaves as described. 1106 When the text refers to initializing a state variable, this takes 1107 place only at the time that the session (and the corresponding state 1108 variables) is created. The state variables are subsequently 1109 manipulated by the state machine and are never reinitialized, even if 1110 the session fails and is reestablished. 1112 All state variables in this specification are of the form "bfd.Xx" 1113 and should not be confused with fields carried in the protocol 1114 packets, which are always spelled out to match the names in section 1115 4. 1117 bfd.SessionState 1119 The perceived state of the session (Init, Up, Down, or 1120 AdminDown.) The exact action taken when the session state 1121 changes is outside the scope of this specification, though it 1122 is expected that this state change (particularly to and from Up 1123 state) is reported to other components of the system. This 1124 variable MUST be initialized to Down. 1126 bfd.LocalDiscr 1128 The local discriminator for this BFD session, used to uniquely 1129 identify it. It MUST be unique across all BFD sessions on this 1130 system, and nonzero. It SHOULD be set to a random (but still 1131 unique) value to improve security. The value is otherwise 1132 outside the scope of this specification. 1134 bfd.RemoteDiscr 1136 The remote discriminator for this BFD session. This is the 1137 discriminator chosen by the remote system, and is totally 1138 opaque to the local system. This MUST be initialized to zero. 1140 bfd.LocalDiag 1142 The diagnostic code specifying the reason for the most recent 1143 local session state chage. This MUST be initialized to zero 1144 (No Diagnostic.) 1146 bfd.DesiredMinTxInterval 1148 The minimum interval, in microseconds, between transmitted BFD 1149 Control packets that this system would like to use at the 1150 current time. The actual interval is negotiated between the 1151 two systems. This MUST be initialized to a value of at least 1152 one second (1,000,000 microseconds) according to the rules 1153 described in section 6.7.3. The setting of this variable is 1154 otherwise outside the scope of this specification. 1156 bfd.RequiredMinRxInterval 1158 The minimum interval, in microseconds, between received BFD 1159 Control packets that this system requires. The setting of this 1160 variable is outside the scope of this specification. 1162 bfd.DemandModeDesired 1164 Set to 1 if the local system wishes to use Demand mode, or 0 if 1165 not. 1167 bfd.DetectMult 1169 The desired detect time multiplier for BFD Control packets. 1170 The negotiated Control packet transmission interval, multiplied 1171 by this variable, will be the detection time for this session 1172 (as seen by the remote system.) This variable MUST be a 1173 nonzero integer, and is otherwise outside the scope of this 1174 specification. See section 6.7.4 for further information. 1176 bfd.AuthType 1178 The authentication type in use for this session, as defined in 1179 section 4.1, or zero if no authentication is in use. 1181 bfd.RcvAuthSeq 1183 A 32 bit unsigned integer containing the next sequence number 1184 for keyed MD5 or SHA1 authentication expected to be received. 1185 The initial value is unimportant. 1187 bfd.XmitAuthSeq 1189 A 32 bit unsigned integer containing the next sequence number 1190 for keyed MD5 or SHA1 authentication to be transmitted. This 1191 variable MUST be initialized to a random 32 bit value. 1193 bfd.AuthSeqKnown 1195 Set to 1 if the next sequence number for keyed MD5 or SHA1 1196 authentication expected to be received is known, or 0 if it is 1197 not known. This variable MUST be initialized to zero. 1199 This variable MUST be set to zero after no packets have been 1200 received on this session for at least twice the Detection Time. 1201 This ensures that the sequence number can be resynchronized if 1202 the remote system restarts. 1204 6.7.2. Timer Negotiation 1206 The time values used to determine BFD packet transmission intervals 1207 and the session detection time are continuously negotiated, and thus 1208 may be changed at any time. The negotiation and time values are 1209 independent in each direction for each session. Packets are always 1210 periodically transmitted in Asynchronous mode, and are periodically 1211 transmitted during Poll Sequences when in Demand mode. 1213 Each system reports in the BFD Control packet how rapidly it would 1214 like to transmit BFD packets, as well as how rapidly it is prepared 1215 to receive them. With the exceptions listed in the remainder of this 1216 section, a system MUST NOT transmit BFD Control packets with an 1217 interval less than the larger of bfd.DesiredMinTxInterval and the 1218 received Required Min RX Interval field. In other words, the system 1219 reporting the slower rate determines the transmission rate. 1221 The periodic transmission of BFD Control packets SHOULD be jittered 1222 by up to 25%, that is, the interval SHOULD be reduced by a random 1223 value of 0 to 25%, in order to avoid self-synchronization. Thus, the 1224 average interval between packets may be up to 12.5% less than that 1225 negotiated. 1227 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 1228 Control packets MUST be no more than 90% of the negotiated 1229 transmission interval, and MUST be no less than 75% of the negotiated 1230 transmission interval. This is to ensure that, on the remote system, 1231 the calculated DetectTime does not pass prior to the receipt of the 1232 next BFD Control packet. 1234 A BFD Control packet SHOULD be transmitted during the interval 1235 between periodic Control packet transmissions when the contents of 1236 that packet would differ from that in the previously transmitted 1237 packet (other than the Poll and Final bits) in order to more rapidly 1238 communicate a change in state. 1240 If a BFD Control packet is received with the Poll (P) bit set to 1, 1241 the receiving system MUST transmit a BFD Control packet with the Poll 1242 (P) bit clear and the Final (F) bit set as soon as practicable, 1243 without respect to the transmission timer or any other transmission 1244 limitations, without respect to the session state, and without 1245 respect to whether Demand mode is active. 1247 6.7.3. Timer Manipulation 1249 The time values used to determine BFD packet transmission intervals 1250 and the session detection time may be modified at any time without 1251 affecting the state of the session. When the timer parameters are 1252 changed for any reason, the requirements of this section apply. 1254 If Demand mode is active, and either bfd.DesiredMinTxInterval is 1255 changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST 1256 be initiated (see section 6.7.8). 1258 If Demand mode is not active, bfd.SessionState is Up, and either 1259 bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is 1260 changed, all subsequent transmitted Control packets MUST be sent with 1261 the Poll (P) bit set until a packet is received with the Final (F) 1262 bit set (except for those packets sent in response to received 1263 Polls.) 1265 If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, 1266 the actual transmission interval used MUST NOT change until a Control 1267 packet is received with the Final (F) bit set. This is to ensure 1268 that the remote system updates its Detect Time before the 1269 transmission interval increases. 1271 If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, 1272 the calculated detection time for the remote system MUST NOT change 1273 until a Control packet is received with the Final (F) bit set. This 1274 is to ensure that the remote system is transmitting packets at the 1275 higher rate (and those packets are being received) prior to the 1276 detection time being reduced. 1278 When bfd.SessionState is not Up, the system MUST set 1279 bfd.DesiredMinTxInterval to a value of not less than one second 1280 (1,000,000 microseconds.) This is intended to ensure that the 1281 bandwidth consumed by BFD sessions that are not Up is negligible, 1282 particularly in the case where a neighbor may not be running BFD. 1284 When the Echo function is active, a system SHOULD set 1285 bfd.DesiredMinTxInterval to a value of not less than one second 1286 (1,000,000 microseconds.) This is intended to keep BFD Control 1287 traffic at a negligible level, since the actual detection function is 1288 being performed using BFD Echo packets. 1290 6.7.4. Calculating the Detection Time 1292 The Detection Time (the period of time without receiving BFD packets 1293 after which the session is determined to have failed) is not carried 1294 explicitly in the protocol. Rather, it is calculated independently 1295 in each direction by the receiving system based on the negotiated 1296 transmit interval and the detection multiplier. Note that, in 1297 Asynchronous mode, there may be different detection times in each 1298 direction. 1300 The calculation of the Detection Time is slightly different when in 1301 Demand mode versus Asynchronous mode. 1303 In Asynchronous mode, the Detection Time calculated in the local 1304 system is equal to the value of Detect Mult received from the remote 1305 system, multiplied by the agreed transmit interval of the remote 1306 system (the greater of bfd.RequiredMinRxInterval and the last 1307 received Desired Min TX Interval.) The Detect Mult value is (roughly 1308 speaking, due to jitter) the number of packets that have to be missed 1309 in a row to declare the session to be down. 1311 If Demand mode is not active, and a period of time equal to the 1312 Detection Time passes without receiving a BFD Control packet from the 1313 remote system, and bfd.SessionState is Init or Up, the session has 1314 gone down--the local system MUST set bfd.SessionState to Down and 1315 bfd.LocalDiag to 1 (Control Detection Time Expired.) 1317 In Demand mode, the Detection Time calculated in the local system is 1318 equal to bfd.DetectMult, multiplied by the agreed transmit interval 1319 of the local system (the greater of bfd.DesiredMinTxInterval and the 1320 last received Required Min RX Interval.) bfd.DetectMult is (roughly 1321 speaking, due to jitter) the number of packets that have to be missed 1322 in a row to declare the session to be down. 1324 If Demand mode is active, and a period of time equal to the Detection 1325 Time passes after the initiation of a Poll Sequence (the transmission 1326 of the first BFD Control packet with the Poll bit set), the session 1327 has gone down--the local system MUST set bfd.SessionState to Down, 1328 and bfd.LocalDiag to 1 (Control Detection Time Expired.) 1330 (Note that a packet is considered to have been received, for the 1331 purposes of Detection Time expiration, only if it has not been 1332 "discarded" according to the rules of section 6.7.6.) 1334 6.7.5. Detecting Failures with the Echo Function 1336 When the Echo function is active and a sufficient number of Echo 1337 packets have not arrived as they should, the session has gone 1338 down--the local system MUST set bfd.SessionState to Down, and 1339 bfd.LocalDiag to 2 (Echo Function Failed.) 1341 The means by which the Echo function failures are detected is outside 1342 of the scope of this specification. Any means which will detect a 1343 communication failure is acceptable. 1345 6.7.6. Reception of BFD Control Packets 1347 When a BFD Control packet is received, the following procedure MUST 1348 be followed, in the order specified. If the packet is discarded 1349 according to these rules, processing of the packet MUST cease at that 1350 point. 1352 If the version number is not correct (1), the packet MUST be 1353 discarded. 1355 If the Length field is less than the minimum correct value (24 if 1356 the A bit is clear, or 26 if the A bit is set), the packet MUST be 1357 discarded. 1359 If the Length field is greater than the payload of the 1360 encapsulating protocol, the packet MUST be discarded. 1362 If the Detect Mult field is zero, the packet MUST be discarded. 1364 If the My Discriminator field is zero, the packet MUST be 1365 discarded. 1367 If the Your Discriminator field is nonzero, it MUST be used to 1368 select the session with which this BFD packet is associated. If 1369 no session is found, the packet MUST be discarded. 1371 If the Your Discriminator field is zero and the State field is not 1372 Down or AdminDown, the packet MUST be discarded. 1374 If the Your Discriminator field is zero, the session MUST be 1375 selected based on some combination of other fields, possibly 1376 including source addressing information, the My Discriminator 1377 field, and the interface over which the packet was received. The 1378 exact method of selection is application-specific and is thus 1379 outside the scope of this specification. If a matching session is 1380 not found, a new session may be created, or the packet may be 1381 discarded. This choice is outside the scope of this 1382 specification. 1384 If the A bit is set and no authentication is in use (bfd.AuthType 1385 is zero), the packet MUST be discarded. 1387 If the A bit is clear and authentication is in use (bfd.AuthType 1388 is nonzero), the packet MUST be discarded. 1390 If the A bit is set, the packet MUST be authenticated under the 1391 rules of section 6.6, based on the authentication type in use 1392 (bfd.AuthType.) This may cause the packet to be discarded. 1394 Set bfd.RemoteDiscr to the value of My Discriminator. 1396 If the Required Min Echo RX Interval field is zero, the 1397 transmission of Echo packets, if any, MUST cease. 1399 If Demand mode is active, a Poll Sequence is being transmitted by 1400 the local system, and the Final (F) bit in the received packet is 1401 set, the Poll Sequence MUST be terminated. 1403 If Demand mode is not active, the Final (F) bit in the received 1404 packet is set, and the local system has been transmitting packets 1405 with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in 1406 subsequent transmitted packets. 1408 Update the Detection Time as described in section 6.7.4. 1410 Update the transmit interval as described in section 6.7.2. 1412 If bfd.SessionState is AdminDown 1413 Discard the packet 1415 If received state is AdminDown 1416 If bfd.SessionState is not Down 1417 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1418 Set bfd.SessionState to Down 1420 Else 1422 If bfd.SessionState is Down 1423 If received State is Down 1424 Set bfd.SessionState to Init 1425 Else if received State is Init 1426 Set bfd.SessionState to Up 1428 Else if bfd.SessionState is Init 1429 If received State is Init or Up 1430 Set bfd.SessionState to Up 1432 Else (bfd.SessionState is Up) 1433 If received State is Down 1434 Set bfd.LocalDiag to 3 (Neighbor signaled session 1435 down) 1436 Set bfd.SessionState to Down 1438 If the Demand (D) bit is set and bfd.DemandModeDesired is 1, 1439 and bfd.SessionState is Up, Demand mode is active. 1441 If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, 1442 or bfd.SessionState is not Up, Demand mode is not 1443 active. 1445 If the Poll (P) bit is set, send a BFD Control packet to the 1446 remote system with the Poll (P) bit clear, and the Final (F) bit 1447 set. 1449 If the packet was not discarded, it has been received for purposes 1450 of the Detection Time expiration rules in section 6.7.4. 1452 6.7.7. Transmitting BFD Control Packets 1454 BFD Control packets MUST be transmitted periodically at the rate 1455 determined according to section 6.7.2, except as specified in this 1456 section. 1458 The transmit interval MUST be recalculated whenever 1459 bfd.DesiredMinTxInterval changes, or whenever the received Required 1460 Min RX Interval changes, and is equal to the greater of those two 1461 values. See sections 6.7.2 and 6.7.3 for details on transmit timers. 1463 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 1464 zero and the system is taking the Passive role. 1466 A system MUST NOT periodically transmit BFD Control packets if Demand 1467 mode is active and a Poll Sequence is not being transmitted. 1469 A system MUST send a BFD Control packet in response to a received BFD 1470 Control Packet with the Poll (P) bit set, regardless of the BFD 1471 session state. The packet sent in response MUST NOT have the Poll 1472 (P) bit set, and MUST have the Final (F) bit set. A system MAY limit 1473 the rate at which such packets are transmitted. If rate limiting is 1474 in effect, the advertised value of Desired Min TX Interval must be 1475 greater than or equal to the interval between transmitted packets 1476 imposed by the rate limiting function. 1478 A BFD Control packet SHOULD be transmitted between normally scheduled 1479 transmissions when the contents of that packet would differ from 1480 those in the previously transmitted packet (other than the Poll and 1481 Final bits) in order to more rapidly communicate a change in state. 1483 The contents of transmitted BFD Control packets MUST be set as 1484 follows: 1486 Version 1488 Set to the current version number (1). 1490 Diagnostic (Diag) 1492 Set to bfd.LocalDiag. 1494 State (Sta) 1496 Set to the value indicated by bfd.SessionState. 1498 Poll (P) 1500 Set to 1 if the local system is sending a Poll Sequence or is 1501 required to do so according to the requirements of section 6.7.3, 1502 or 0 if not. 1504 Final (F) 1506 Set to 1 if the local system is responding to a Control packet 1507 received with the Poll (P) bit set, or 0 if not. 1509 Control Plane Independent (C) 1511 Set to 1 if the local system's BFD implementation is independent 1512 of the control plane (it can continue to function through a 1513 disruption of the control plane.) 1515 Authentication Present (A) 1517 Set to 1 if authentication is in use on this session (bfd.AuthType 1518 is nonzero), or 0 if not. 1520 Demand (D) 1522 Set to bfd.DemandModeDesired. 1524 Reserved (R) 1526 Set to 0. 1528 Detect Mult 1530 Set to bfd.DetectMult. 1532 Length 1534 Set to the appropriate length, based on the fixed header length 1535 (24) plus any Authentication Section. 1537 My Discriminator 1539 Set to bfd.LocalDiscr. 1541 Your Discriminator 1543 Set to bfd.RemoteDiscr. 1545 Desired Min TX Interval 1547 Set to bfd.DesiredMinTxInterval. 1549 Required Min RX Interval 1551 Set to bfd.RequiredMinRxInterval. 1553 Required Min Echo RX Interval 1555 Set to the minimum required Echo packet receive interval for this 1556 session. If this field is set to zero, the local system is 1557 unwilling or unable to loop back BFD Echo packets to the remote 1558 system, and the remote system will not send Echo packets. 1560 Authentication Section 1562 Included and set according to the rules in section 6.6 if 1563 authentication is in use (bfd.AuthType is nonzero.) Otherwise 1564 this section is not present. 1566 6.7.8. Initiation of a Poll Sequence 1568 If Demand mode is active, a Poll Sequence MUST be initiated whenever 1569 the contents of the next BFD Control packet to be sent would be 1570 different than the contents of the previous packet, with the 1571 exception of the Poll (P) and Final (F) bits. This ensures that 1572 parameter changes are transmitted to the remote system. 1574 If Demand mode is active, a Poll Sequence SHOULD be initiated 1575 whenever the system feels the need to verify connectivity with the 1576 remote system. The conditions under which this is desirable are 1577 outside the scope of this specification. 1579 If a Poll Sequence is being sent, and a new Poll Sequence is 1580 initiated due to one of the above conditions, the detection interval 1581 MUST be restarted in order to ensure that a full Poll Sequence is 1582 transmitted under the new conditions. 1584 6.7.9. Reception of BFD Echo Packets 1586 A received BFD Echo packet MUST be demultiplexed to the appropriate 1587 session for processing. A means of detecting missing Echo packets 1588 MUST be implemented, which most likely involves processing of the 1589 Echo packets that are received. The processing of received Echo 1590 packets is otherwise outside the scope of this specification. 1592 6.7.10. Transmission of BFD Echo Packets 1594 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 1595 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 1596 Control packet received from the remote system contains a nonzero 1597 value in Required Min Echo RX Interval. 1599 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 1600 interval between transmitted BFD Echo packets MUST NOT be less than 1601 the value advertised by the remote system in Required Min Echo RX 1602 Interval, except as follows: 1604 A 25% jitter MAY be applied to the rate of transmission, such that 1605 the actual interval MAY be between 75% and 100% of the advertised 1606 value. A single BFD Echo packet MAY be transmitted between 1607 normally scheduled Echo transmission intervals. 1609 The transmission of BFD Echo packets is otherwise outside the scope 1610 of this specification. 1612 6.7.11. Min Rx Interval Change 1614 When it is desired to change the rate at which BFD Control packets 1615 arrive from the remote system, bfd.RequiredMinRxInterval can be 1616 changed at any time to any value. The new value will be transmitted 1617 in the next outgoing Control packet, and the remote system will 1618 adjust accordingly. See sections 6.7.3 and 6.7.8 for further 1619 requirements. 1621 6.7.12. Min Tx Interval Change 1623 When it is desired to change the rate at which BFD Control packets 1624 are transmitted to the remote system (subject to the requirements of 1625 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1626 any time to any value. The rules in sections 6.7.3 and 6.7.8 apply. 1628 6.7.13. Detect Multiplier Change 1630 When it is desired to change the detect multiplier, the value of 1631 bfd.DetectMult can be changed to any nonzero value. The new value 1632 will be transmitted with the next BFD Control packet. See section 1633 6.7.8 for additional requirements. 1635 6.7.14. Enabling or Disabling The Echo Function 1637 If it is desired to start or stop the transmission of BFD Echo 1638 packets, this MAY be done at any time (subject to the transmission 1639 requirements detailed in section 6.7.10.) 1641 If it is desired to enable or disable the looping back of received 1642 BFD Echo packets, this MAY be done at any time by changing the value 1643 of Required Min RX Interval to zero or nonzero in outgoing BFD 1644 Control packets. 1646 6.7.15. Enabling or Disabling Demand Mode 1648 If it is desired to start or stop Demand mode, this MAY be done at 1649 any time by setting bfd.DemandModeDesired to the proper value. If 1650 Demand mode is no longer active, the system MUST begin transmitting 1651 periodic BFD Control packets as described in section 6.7.7. 1653 6.7.16. Forwarding Plane Reset 1655 When the forwarding plane in the local system is reset for some 1656 reason, such that the remote system can no longer rely on the local 1657 forwarding state, the local system MUST set bfd.LocalDiag to 4 1658 (Forwarding Plane Reset), and set bfd.SessionState to Down. 1660 6.7.17. Administrative Control 1662 There may be circumstances where it is desirable to administratively 1663 enable or disable a BFD session. When this is desired, the following 1664 procedure MUST be followed: 1666 If enabling session 1667 Set bfd.SessionState to Down 1669 Else 1670 Set bfd.SessionState to AdminDown 1671 Set bfd.LocalDiag to an appropriate value 1672 Cease the transmission of BFD Echo packets 1674 If signalling is received from outside BFD that the underlying 1675 path has failed, an implementation MAY adminstratively disable 1676 the session with the diagnostic Path Down. 1678 Other scenarios MAY use the diagnostic Administratively Down. 1680 6.7.18. Concatenated Paths 1682 If the path being monitored by BFD is concatenated with other paths, 1683 it may be desirable to propagate the indication of a failure of one 1684 of those paths across the BFD session (providing an interworking 1685 function for liveness monitoring between BFD and other technologies.) 1687 Two diagnostic codes are defined for this purpose: Concatenated Path 1688 Down and Reverse Concatenated Path Down. The first propagates 1689 forward path failures (in which the concatenated path fails in the 1690 direction toward the interworking system), and the second propagates 1691 reverse path failures (in which the concatenated path fails in the 1692 direction away from the interworking system, assuming a bidirectional 1693 link.) 1695 A system MAY signal one of these failure states by simply setting 1696 bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD 1697 session is not taken down. If Demand Mode is not active, no other 1698 action is necessary, as the diagnostic code will be carried via the 1699 periodic transmission of BFD Control packets. If Demand Mode is 1700 active, a Poll Sequence MUST be initiated to ensure that the 1701 diagnostic code is transmitted. Note that if the BFD session 1702 subsequently fails, the diagnostic code will be overwritten with a 1703 code detailing the cause of the failure. It is up to the 1704 interworking agent to perform the above procedure again, once the BFD 1705 session reaches Up state, if the propagation of the concatenated path 1706 failure is to resume. 1708 Backward Compatibility (Non-Normative) 1710 Although Version 0 of this document is unlikely to have been deployed 1711 widely, some implementors may wish to have a backward compatibility 1712 mechanism. Note that any mechanism may be potentially used that does 1713 not alter the protocol definition, so interoperability should not be 1714 an issue. 1716 The suggested mechanism described here has the property that it will 1717 converge on version 1 if both systems implement it, even if one 1718 system is upgraded from version 0 within a detection time. It will 1719 interoperate with a system that implements only one version (or is 1720 configured to support only one version.) A system should obviously 1721 not perform this function if it is configured to or is only capable 1722 of using a single version. 1724 A BFD session will enter a "negotiation holddown" if it is configured 1725 for automatic versioning and either has just started up, or the 1726 session has been manually cleared. The session is set to AdminDown 1727 state and Version 1. During the holddown period, which lasts for one 1728 detection time, the system sends BFD Control packets as usual, but 1729 ignores received packets. After the holddown time is complete, the 1730 state transitions to Down and normal operation resumes. 1732 When a system is not in holddown, if it doing automatic versioning 1733 and is currently using Version 1, if any Version 0 packet is received 1734 for the session, it switches immediately to Version 0. If it is 1735 currently using Version 0 and a Version 1 packet is received that 1736 indicates that the neighbor is in state AdminDown, it switches to 1737 Version 1. If using Version 0 and a Version 1 packet is received 1738 indicating a state other than AdminDown, the packet is ignored (per 1739 spec.) 1741 If the version being used is changed, the session goes down as 1742 appropriate for the new version (Down state for Version 1 or Failing 1743 state for Version 0.) 1745 Contributors 1747 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 1748 significant contributors to this document. 1750 Acknowledgments 1752 This document was inspired by (and is intended to replace) the 1753 Protocol Liveness Protocol draft, written by Kireeti Kompella. 1755 Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 1756 et al. 1758 The authors would also like to thank Mike Shand, John Scudder, 1759 Stewart Bryant, Pekka Savola, and Richard Spencer for their 1760 substantive input. 1762 Security Considerations 1764 As BFD may be tied into the stability of the network infrastructure 1765 (such as routing protocols), the effects of an attack on a BFD 1766 session may be very serious. This ultimately has denial-of-service 1767 effects, as links may be declared to be down (or falsely declared to 1768 be up.) 1770 When BFD is run over network layer protocols, a significant denial- 1771 of-service risk is created, as BFD packets may be trivial to spoof. 1772 When the session is directly connected across a single link 1773 (physical, or a secure tunnel such as IPsec), the TTL or Hop Count 1774 MUST be set to the maximum on transmit, and checked to be equal to 1775 the maximum value on reception (and the packet dropped if this is not 1776 the case.) See [GTSM] for more information on this technique. If 1777 BFD is run across multiple hops or an insecure tunnel (such as GRE), 1778 the Authentication Section SHOULD be utilized. 1780 The level of security provided by the Authentication Section varies 1781 based on the authentication type used. Simple Password 1782 authentication is obviously only as secure as the secrecy of the 1783 passwords used, and should be considered only if the BFD session is 1784 guaranteed to be run over an infrastructure not subject to packet 1785 interception. Its chief advantage is that it minimizes the 1786 computational effort required for authentication. 1788 Keyed MD5 authentication is much stronger than Simple Password 1789 authentication since the keys cannot be discerned by intercepting 1790 packets. It is vulnerable to replay attacks in between increments of 1791 the sequence number. The sequence number can be incremented as 1792 seldom (or as often) as desired, trading off resistance to replay 1793 attacks with the computational effort required for authentication. 1795 Meticulous Keyed MD5 authentication is stronger yet, as it requires 1796 the sequence number to be incremented for every packet. Replay 1797 attack vulnerability is reduced due to the requirement that the 1798 sequence number must be incremented on every packet, the window size 1799 of acceptable packets is small, and the initial sequence number is 1800 randomized. There is still a window of attack at the beginning of 1801 the session while the sequence number is being determined. This 1802 authentication scheme requires an MD5 calculation on every packet 1803 transmitted and received. 1805 Using SHA1 rather than MD5 is believed to have stronger security 1806 properties. All comments about MD5 in this section also apply to 1807 SHA1. 1809 If both systems randomize their Local Discriminator values at the 1810 beginning of a session, replay attacks may be further mitigated, 1811 regardless of the authentication type in use. Since the Local 1812 Discriminator may be changed at any time during a session, this 1813 mechanism may also help mitigate attacks. 1815 IANA Considerations 1817 This document has no actions for IANA. 1819 Normative References 1821 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 1822 (GTSM)", RFC 3682, February 2004. 1824 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 1825 Requirement Levels", RFC 2119, March 1997. 1827 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1828 1992. 1830 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1832 [SHA1] "Secure Hash Standard", United States of America, National 1833 Institute of Science and Technology, Federal Information 1834 Processing Standard (FIPS) 180-1, April 1993. 1836 Authors' Addresses 1838 Dave Katz 1839 Juniper Networks 1840 1194 N. Mathilda Ave. 1841 Sunnyvale, California 94089-1206 USA 1842 Phone: +1-408-745-2000 1843 Email: dkatz@juniper.net 1845 Dave Ward 1846 Cisco Systems 1847 170 W. Tasman Dr. 1848 San Jose, CA 95134 USA 1849 Phone: +1-408-526-4000 1850 Email: dward@cisco.com 1852 Changes from the previous draft 1854 All changes from the previous draft are purely editorial. 1856 IPR Notice 1858 The IETF has been notified of intellectual property rights claimed in 1859 regard to some or all of the specification contained in this 1860 document. For more information consult the online list of claimed 1861 rights. 1863 The IETF takes no position regarding the validity or scope of any 1864 Intellectual Property Rights or other rights that might be claimed to 1865 pertain to the implementation or use of the technology described in 1866 this document or the extent to which any license under such rights 1867 might or might not be available; nor does it represent that it has 1868 made any independent effort to identify any such rights. Information 1869 on the procedures with respect to rights in RFC documents can be 1870 found in BCP 78 and BCP 79. 1872 Copies of IPR disclosures made to the IETF Secretariat and any 1873 assurances of licenses to be made available, or the result of an 1874 attempt made to obtain a general license or permission for the use of 1875 such proprietary rights by implementers or users of this 1876 specification can be obtained from the IETF on-line IPR repository at 1877 http://www.ietf.org/ipr. 1879 The IETF invites any interested party to bring to its attention any 1880 copyrights, patents or patent applications, or other proprietary 1881 rights that may cover technology that may be required to implement 1882 this standard. Please address the information to the IETF at ietf- 1883 ipr@ietf.org. 1885 Full Copyright Notice 1887 Copyright (C) The Internet Society (2005). 1889 This document is subject to the rights, licenses and restrictions 1890 contained in BCP 78, and except as set forth therein, the authors 1891 retain all their rights. 1893 This document and the information contained herein are provided on an 1894 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1895 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1896 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1897 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1898 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1899 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1901 Acknowledgement 1903 Funding for the RFC Editor function is currently provided by the 1904 Internet Society. 1906 This document expires in April, 2006.