idnits 2.17.1 draft-ietf-bfd-base-02.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1874. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1866), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 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 1780, 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: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: September, 2005 March, 2005 8 Bidirectional Forwarding Detection 9 draft-ietf-bfd-base-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 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 . . . . . . . . 36 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 . . . . . 37 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 . . . . . . . . . . . . . . . 38 98 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 99 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 100 Security Considerations . . . . . . . . . . . . . . . . . . . . 39 101 Normative References . . . . . . . . . . . . . . . . . . . . . 41 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41 103 Changes from the previous draft . . . . . . . . . . . . . . . . 41 104 IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 42 106 1. Introduction 108 An increasingly important feature of networking equipment is the 109 rapid detection of communication failures between adjacent systems, 110 in order to more quickly establish alternative paths. Currently, 111 detection can come fairly quickly in certain circumstances when data 112 link hardware comes into play (such as SONET alarms.) However, there 113 are media that do not provide this kind of signaling (such as 114 Ethernet), and some media may not detect certain kinds of failures in 115 the path, for example, failing interfaces or forwarding engine 116 components. 118 Networks use relatively slow "Hello" mechanisms, usually in routing 119 protocols, to detect failures when there is no hardware signaling to 120 help out. The time to detect failures ("detection times") available 121 in the existing protocols are no better than a second, which is far 122 too long for some applications and represents a great deal of lost 123 data at gigabit rates. Furthermore, routing protocol Hellos are of 124 no help when those routing protocols are not in use, and the 125 semantics of detection are subtly different--they detect a failure in 126 the path between the two routing protocol engines. 128 The goal of BFD is to provide low-overhead, short-duration detection 129 of failures in the path between adjacent forwarding engines, 130 including the interfaces, data link(s), and to the extent possible 131 the forwarding engines themselves. 133 An additional goal is to provide a single mechanism that can be used 134 for liveness detection over any media, at any protocol layer, with a 135 wide range of detection times and overhead, to avoid a proliferation 136 of different methods. 138 This document specifies the details of the base protocol. The use of 139 some mechanisms are application dependent, and will be specified in a 140 separate series of application documents. These issues are so noted. 142 Note that many of the exact mechanisms are implementation dependent 143 and will not affect interoperability, and are thus outside the scope 144 of this specification. Those issues are so noted. 146 2. Design 148 BFD is designed to detect failures in communication with a forwarding 149 plane next hop. It is intended to be implemented in some component 150 of the forwarding engine of a system, in cases where the forwarding 151 and control engines are separated. This not only binds the protocol 152 more to the forwarding plane, but decouples the protocol from the 153 fate of the routing protocol engine (making it useful in concert with 154 various "graceful restart" mechanisms for those protocols.) BFD may 155 also be implemented in the control engine, though doing so may 156 preclude the detection of some kinds of failures. 158 BFD operates on top of any data protocol being forwarded between two 159 systems. It is always run in a unicast, point-to-point mode. BFD 160 packets are carried as the payload of whatever encapsulating protocol 161 is appropriate for the medium and network. BFD may be running at 162 multiple layers in a system. The context of the operation of any 163 particular BFD session is bound to its encapsulation. 165 BFD can provide failure detection on any kind of path between 166 systems, including direct physical links, virtual circuits, tunnels, 167 MPLS LSPs, multihop routed paths, and unidirectional links (so long 168 as there is some return path, of course.) Multiple BFD sessions can 169 be established between the same pair of systems when multiple paths 170 between them are present in at least one direction, even if a lesser 171 number of paths are available in the other direction (multiple 172 parallel unidirectional links or MPLS LSPs, for example.) 174 The BFD state machine implements a three-way handshake, both when 175 establishing a BFD session and when tearing it down for any reason, 176 to ensure that both systems are aware of the state change. 178 BFD can be abstracted as a simple service. The service primitives 179 provided by BFD are to create, destroy, and modify a session, given 180 the destination address and other parameters. BFD in return provides 181 a signal to its clients indicating when the BFD session goes up or 182 down. 184 3. Protocol Overview 186 BFD is a simple hello protocol that in many respects is similar to 187 the detection components of well-known routing protocols. A pair of 188 systems transmit BFD packets periodically over each path between the 189 two systems, and if a system stops receiving BFD packets for long 190 enough, some component in that particular bidirectional path to the 191 neighboring system is assumed to have failed. Under some conditions, 192 systems may negotiate to not send periodic BFD packets in order to 193 reduce overhead. 195 A path is only declared to be operational when two-way communication 196 has been established between systems (though this does not preclude 197 the use of unidirectional links.) 199 A separate BFD session is created for each communications path and 200 data protocol in use between two systems. 202 Each system estimates how quickly it can send and receive BFD packets 203 in order to come to an agreement with its neighbor about how rapidly 204 detection of failure will take place. These estimates can be 205 modified in real time in order to adapt to unusual situations. This 206 design also allows for fast systems on a shared medium with a slow 207 system to be able to more rapidly detect failures between the fast 208 systems while allowing the slow system to participate to the best of 209 its ability. 211 3.1. Addressing and Session Establishment 213 A BFD session is established based on the needs of the application 214 that will be making use of it. It is up to the application to 215 determine the need for BFD, and the addresses to use--there is no 216 discovery mechanism in BFD. For example, an OSPF [OSPF] 217 implementation may request a BFD session to be established to a 218 neighbor discovered using the OSPF Hello protocol. 220 3.2. Operating Modes 222 BFD has two operating modes which may be selected, as well as an 223 additional function that can be used in combination with the two 224 modes. 226 The primary mode is known as Asynchronous mode. In this mode, the 227 systems periodically send BFD Control packets to one another, and if 228 a number of those packets in a row are not received by the other 229 system, the session is declared to be down. 231 The second mode is known as Demand mode. In this mode, it is assumed 232 that each system has an independent way of verifying that it has 233 connectivity to the other system, so once a BFD session is 234 established, the systems stop sending BFD Control packets, except 235 when either system feels the need to verify connectivity explicitly, 236 in which case a short sequence of BFD Control packets is sent, and 237 then the protocol quiesces. 239 An adjunct to both modes is the Echo function. When the Echo 240 function is active, a stream of BFD Echo packets is transmitted in 241 such a way as to have the other system loop them back through its 242 forwarding path. If a number of packets in a row of the echoed data 243 stream are not received, the session is declared to be down. The 244 Echo function may be used with either Asynchronous or Demand modes. 245 Since the Echo function is handling the task of detection, the rate 246 of periodic transmission of Control packets may be reduced (in the 247 case of Asynchronous mode) or eliminated completely (in the case of 248 Demand mode.) 250 Pure asynchronous mode is advantageous in that it requires half as 251 many packets to achieve a particular detection time as does the Echo 252 function. It is also used when the Echo function cannot be supported 253 for some reason. 255 The Echo function has the advantage of truly testing only the 256 forwarding path on the remote system, which may reduce round-trip 257 jitter and thus allow more aggressive detection times, as well as 258 potentially detecting some classes of failure that might not 259 otherwise be detected. 261 The Echo function may be enabled individually in each direction. It 262 is enabled in a particular direction only when the system that loops 263 the Echo packets back signals that it will allow it, and when the 264 system that sends the Echo packets decides it wishes to. 266 Demand mode is useful in situations where the overhead of a periodic 267 protocol might prove onerous, such as a system with a very large 268 number of BFD sessions. It is also useful when the Echo function is 269 being used symmetrically. Demand mode has the disadvantage that 270 detection times are essentially driven by the heuristics of the 271 system implementation and are not known to the BFD protocol. Demand 272 mode also may not be used when the path round trip time is greater 273 than the desired detection time. See section 6.5 for more details. 275 4. BFD Control Packet Format 277 4.1. Generic BFD Control Packet Format 279 BFD Control packets are sent in an encapsulation appropriate to the 280 environment, which is outside of the scope of this document. See the 281 appropriate application document for encapsulation details. 283 The BFD Control packet has a Mandatory Section and an optional 284 Authentication Section. The format of the Authentication Section, if 285 present, is dependent on the type of authentication in use. 287 The Mandatory Section of a BFD Control packet has the following 288 format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |Vers | Diag |Sta|P|F|C|A|D|R| Detect Mult | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | My Discriminator | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Your Discriminator | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Desired Min TX Interval | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Required Min RX Interval | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Required Min Echo RX Interval | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 An optional Authentication Section may be present: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Auth Type | Auth Len | Authentication Data... | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Version (Vers) 316 The version number of the protocol. This document defines 317 protocol version 1. 319 Diagnostic (Diag) 321 A diagnostic code specifying the local system's reason for the 322 last session state change. Values are: 324 0 -- No Diagnostic 325 1 -- Control Detection Time Expired 326 2 -- Echo Function Failed 327 3 -- Neighbor Signaled Session Down 328 4 -- Forwarding Plane Reset 329 5 -- Path Down 330 6 -- Concatenated Path Down 331 7 -- Administratively Down 332 8 -- Reverse Concatenated Path Down 333 9-31 -- Reserved for future use 335 This field allows remote systems to determine the reason that the 336 previous session failed, for example. 338 State (Sta) 340 The current BFD session state as seen by the transmitting system. 341 Values are: 343 0 -- AdminDown 344 1 -- Down 345 2 -- Init 346 3 -- Up 348 Poll (P) 350 If set, the transmitting system is requesting verification of 351 connectivity, or of a parameter change. If clear, the 352 transmitting system is not requesting verification. 354 Final (F) 356 If set, the transmitting system is responding to a received BFD 357 Control packet that had the Poll (P) bit set. If clear, the 358 transmitting system is not responding to a Poll. 360 Control Plane Independent (C) 362 If set, the transmitting system's BFD implementation does not 363 share fate with its control plane (in other words, BFD is 364 implemented in the forwarding plane and can continue to function 365 through disruptions in the control plane.) If clear, the 366 transmitting system's BFD implementation shares fate with its 367 control plane. 369 The use of this bit is application dependent and is outside the 370 scope of this specification. See specific application 371 specifications for details. 373 Authentication Present (A) 375 If set, the Authentication Section is present and the session is 376 to be authenticated. 378 Demand (D) 380 If set, the transmitting system wishes to operate in Demand Mode. 381 If clear, the transmitting system does not wish to or is not 382 capable of operating in Demand Mode. 384 Reserved (R) 386 This bit must be zero on transmit, and ignored on receipt. 388 Detect Mult 390 Detect time multiplier. The negotiated transmit interval, 391 multiplied by this value, provides the detection time for the 392 transmitting system in Asynchronous mode. 394 Length 396 Length of the BFD Control packet, in bytes. 398 My Discriminator 400 A unique, nonzero discriminator value generated by the 401 transmitting system, used to demultiplex multiple BFD sessions 402 between the same pair of systems. 404 Your Discriminator 406 The discriminator received from the corresponding remote system. 407 This field reflects back the received value of My Discriminator, 408 or is zero if that value is unknown. 410 Desired Min TX Interval 412 This is the minimum interval, in microseconds, that the local 413 system would like to use when transmitting BFD Control packets. 415 Required Min RX Interval 417 This is the minimum interval, in microseconds, between received 418 BFD Control packets that this system is capable of supporting. 420 Required Min Echo RX Interval 422 This is the minimum interval, in microseconds, between received 423 BFD Echo packets that this system is capable of supporting. If 424 this value is zero, the transmitting system does not support the 425 receipt of BFD Echo packets. 427 Auth Type 429 The authentication type in use, if the Authentication Present (A) 430 bit is set. 432 0 - Reserved 433 1 - Simple Password 434 2 - Keyed MD5 435 3 - Meticulous Keyed MD5 436 4 - Keyed SHA1 437 5 - Meticulous Keyed SHA1 438 6-255 - Reserved for future use 440 Auth Len 442 The length, in bytes, of the authentication section, including the 443 Auth Type and Auth Len fields. 445 4.2. Simple Password Authentication Section Format 447 If the Autentication Present (A) bit is set in the header, and the 448 Authentication Type field contains 1 (Simple Password), the 449 Authentication Section has the following format: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Auth Type | Auth Len | Auth Key ID | Password... | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | ... | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Auth Type 461 The Authentication Type, which in this case is 1 (Simple 462 Password.) 464 Auth Len 466 The length of the Authentication Section, in bytes. For Simple 467 Password authentication, the length is equal to the password 468 length plus three. 470 Auth Key ID 472 The authentication key ID in use for this packet. This allows 473 multiple keys to be active simultaneously. 475 Password 477 The simple password in use on this session. The password MUST be 478 from 1 to 16 bytes in length. 480 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 482 If the Authentication Present (A) bit is set in the header, and the 483 Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous 484 Keyed MD5), the Authentication Section has the following format: 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Auth Type | Auth Len | Auth Key ID | Reserved | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Sequence Number | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Auth Key/Checksum... | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | ... | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Auth Type 500 The Authentication Type, which in this case is 2 (Keyed MD5) or 3 501 (Meticulous Keyed MD5). 503 Auth Len 505 The length of the Authentication Section, in bytes. For Keyed MD5 506 and Meticulous Keyed MD5 authentication, the length is 24. 508 Auth Key ID 510 The authentication key ID in use for this packet. This allows 511 multiple keys to be active simultaneously. 513 Reserved 515 This byte must be set to zero on transmit, and ignored on receipt. 517 Sequence Number 519 The Sequence Number for this packet. For Keyed MD5 520 Authentication, this value is incremented occasionally. For 521 Meticulous Keyed MD5 Authentication, this value is incremented for 522 each successive packet transmitted for a session. This provides 523 protection against replay attacks. 525 Auth Key/Checksum 527 This field carries the 16 byte MD5 checksum for the packet. When 528 the checksum is calculated, the shared MD5 key is stored in this 529 field. (See section 6.6.3 for details.) 531 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 533 If the Authentication Present (A) bit is set in the header, and the 534 Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous 535 Keyed SHA1), the Authentication Section has the following format: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Auth Type | Auth Len | Auth Key ID | Reserved | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Sequence Number | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Auth Key/Checksum... | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | ... | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Auth Type 551 The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 552 (Meticulous Keyed SHA1). 554 Auth Len 556 The length of the Authentication Section, in bytes. For Keyed 557 SHA1 and Meticulous Keyed SHA1 authentication, the length is 28. 559 Auth Key ID 561 The authentication key ID in use for this packet. This allows 562 multiple keys to be active simultaneously. 564 Reserved 566 This byte must be set to zero on transmit, and ignored on receipt. 568 Sequence Number 570 The Sequence Number for this packet. For Keyed SHA1 571 Authentication, this value is incremented occasionally. For 572 Meticulous Keyed SHA1 Authentication, this value is incremented 573 for each successive packet transmitted for a session. This 574 provides protection against replay attacks. 576 Auth Key/Checksum 578 This field carries the 20 byte SHA1 checksum for the packet. When 579 the checksum is calculated, the shared SHA1 key is stored in this 580 field. (See section 6.6.4 for details.) 582 5. BFD Echo Packet Format 584 BFD Echo packets are sent in an encapsulation appropriate to the 585 environment. See the appropriate application document for the 586 specifics of particular environments. 588 The payload of a BFD Echo packet is a local matter, since only the 589 sending system ever processes the content. The only requirement is 590 that sufficient information is included to demultiplex the received 591 packet to the correct BFD session after it is looped back to the 592 sender. The contents are otherwise outside the scope of this 593 specification. 595 6. Elements of Procedure 597 This section discusses the normative requirements of the protocol in 598 order to achieve interoperability. It is important for implementors 599 to enforce only the requirements specified in this section, as 600 misguided pedantry has been proven by experience to adversely affect 601 interoperability. 603 Remember that all references of the form "bfd.Xx" refer to internal 604 state variables (defined in section 6.7.1), whereas all references to 605 "the Xxx field" refer to fields in the protocol packets themselves 606 (defined in section 4). 608 6.1. Overview 610 A system may take either an Active role or a Passive role in session 611 initialization. A system taking the Active role MUST send BFD 612 Control packets for a particular session, regardless of whether it 613 has received any BFD packets for that session. A system taking the 614 Passive role MUST NOT begin sending BFD packets for a particular 615 session until it has received a BFD packet for that session, and thus 616 has learned the remote system's discriminator value. At least one 617 system MUST take the Active role (possibly both.) The role that a 618 system takes is specific to the application of BFD, and is outside 619 the scope of this specification. 621 A session begins with the periodic, slow transmission of BFD Control 622 packets. When bidirectional communication is achieved, the BFD 623 session comes up. 625 Once the BFD session is Up, a system can choose to start the Echo 626 function if it desires to and the other system signals that it will 627 allow it. The rate of transmission of Control packets is typically 628 kept low when the Echo function is active. 630 If the Echo function is not active, the transmission rate of Control 631 packets may be increased to a level necessary to achieve the 632 detection time requirements for the session. 634 If both systems signal that they want to use Demand mode, the 635 transmission of BFD Control packets ceases once the session is Up. 636 Other means of implying connectivity are used to keep the session 637 alive. If one of the systems wishes to verify connectivity, it can 638 initiate a short exchange (a "Poll Sequence") of BFD Control packets 639 to verify this. 641 If Demand mode is not active, and no Control packets are received in 642 the calculated detection time (see section 6.7.4), the session is 643 declared down, and signalled to the remote end via the State (Sta) 644 field in outgoing packets. 646 If sufficient Echo packets are lost, the session is declared down in 647 the same manner. 649 If Demand mode is active and no appropriate Control packets are 650 received in response to a Poll Sequence, the session is declared down 651 in the same manner. 653 If the session goes down, the transmission of Echo packets (if any) 654 ceases, and the transmission of Control packets goes back to the slow 655 rate. 657 Once a session has been declared down, it cannot come back up until 658 the remote end first signals that it is down (by leaving the Up 659 state), thus implementing a three-way handshake. 661 A session may be kept administratively down by entering the AdminDown 662 state and sending an explanatory diagnostic code in the Diagnostic 663 field. 665 6.2. BFD State Machine 667 The BFD state machine is quite straightforward. There are three 668 states through which a session normally proceeds, two for 669 establishing a session (Init and Up) and one for tearing down a 670 session (Down.) This allows a three-way handshake for both session 671 establishment and session teardown (assuring that both systems are 672 aware of all session state changes.) A fourth state (AdminDown) 673 exists so that a session can be administratively put down 674 indefinitely. 676 Each system communicates its session state in the State (Sta) field 677 in the BFD Control packet, and that received state in combination 678 with the local session state drives the state machine. 680 Down state means that the session is down (or has just been created.) 681 A session remains in Down state until the remote system indicates 682 that it agrees that the session is down by sending a BFD Control 683 packet with the State field set to anything other than Up. If that 684 packet signals Down state, the session advances to Init state; if 685 that packet signals Init state, the session advances to Up state. 687 Init state means that the remote system is communicating, and the 688 local system desires to bring the session up, but the remote system 689 does not yet realize it. A session will remain in Init state until 690 either a BFD Control Packet is received that is signalling Init or Up 691 state (in which case the session advances to Up state) or until the 692 detection time expires, meaning that communication with the remote 693 system has been lost (in which case the session advances to Down 694 state.) 696 Up state means that the BFD session has successfully been 697 established, and implies that connectivity between the systems is 698 working. The session will remain in the Up state until either 699 connectivity fails, or the session is taken down administratively. 700 If either the remote system signals Down state, or the detection time 701 expires, the session advances to Down state. 703 AdminDown state means that the session is being held administratively 704 down. This causes the remote system to enter Down state, and remain 705 there until the local system exits AdminDown state. 707 The following diagram provides an overview of the state machine. 708 Transitions involving AdminDown state are deleted for clarity (but 709 are fully specified in section 6.7.6.) The notation on each arc 710 represents the state of the remote system (as received in the State 711 field in the BFD Control packet) or indicates the expiration of the 712 Detection Time. 714 +--+ 715 | | UP 716 | V 717 DOWN +------+ INIT 718 +------------| |------------+ 719 | | DOWN | | 720 | +-------->| |<--------+ | 721 | | +------+ | | 722 | | | | 723 | | | | 724 | | DOWN,| | 725 | |TIMER TIMER| | 726 V | | V 727 +------+ +------+ 728 +----| | | |----+ 729 DOWN| | INIT |--------------------->| UP | |INIT, UP 730 +--->| | INIT, UP | |<---+ 731 +------+ +------+ 733 6.3. Demultiplexing and the Discriminator Fields 735 Since multiple BFD sessions may be running between two systems, there 736 needs to be a mechanism for demultiplexing received BFD packets to 737 the proper session. 739 Each system MUST choose an opaque discriminator value that identifies 740 each session, and which MUST be unique among all BFD sessions on the 741 system. The local discriminator is sent in the My Discriminator 742 field in the BFD Control packet, and is echoed back in the Your 743 Discriminator field of packets sent from the remote end. 745 Once the remote end echoes back the local discriminator, all further 746 received packets are demultiplexed based on the Your Discriminator 747 field only (which means that, among other things, the source address 748 field can change or the interface over which the packets are received 749 can change, but the packets will still be associated with the proper 750 session.) 752 The method of demultiplexing the initial packets (in which Your 753 Discriminator is zero) is application-dependent, and is thus outside 754 the scope of this specification. 756 Note that it is permissible for a system to change its discriminator 757 during a session (without affecting the session state), since only 758 that system uses its discriminator for demultiplexing purposes (by 759 having the other system reflect it back.) The implications on an 760 implementation for changing the discriminator value is outside the 761 scope of this specification. 763 6.4. The Echo Function and Asymmetry 765 The Echo function can be run independently in each direction between 766 a pair of systems. For whatever reason, a system may advertise that 767 it is willing to receive (and loop back) Echo packets, but may not 768 wish to ever send any. The fact that a system is sending Echo 769 packets is not directly signalled to the system looping them back. 771 When a system is using the Echo function, it is advantageous to 772 choose a sedate transmission rate for Control packets, since liveness 773 detection is being handled by the Echo packets. This can be 774 controlled by manipulating the Desired Min TX Interval field (see 775 section 6.7.3.) 777 If the Echo function is only being run in one direction, the system 778 not running the Echo function will more likely wish to send fairly 779 rapid Control packets in order to achieve its desired detection time. 781 Since BFD allows independent transmission rates in each direction, 782 this is easily accomplished. 784 A system SHOULD always advertise the lowest value of Required Min RX 785 Interval and Required Min Echo RX Interval that it can under the 786 circumstances, to give the other system more freedom in choosing its 787 transmission rate. Note that a system is committing to be able to 788 receive both streams of packets at the rate it advertises, so this 789 should be taken into account when choosing the values to advertise. 791 6.5. Demand Mode 793 Demand mode is negotiated by virtue of both systems setting the 794 Demand (D) bit in its BFD Control packets. Both systems must request 795 Demand mode for it to become active. 797 Demand mode requires that some other mechanism is used to imply 798 continuing connectivity between the two systems. The mechanism used 799 does not have to be the same in both directions, and is outside of 800 the scope of this specification. One possible mechanism is the 801 receipt of traffic from the remote system; another is the use of the 802 Echo function. 804 Once a BFD session comes up, if Demand mode is active, both systems 805 stop sending periodic BFD Control packets, and depend on the 806 alternative mechanism for maintaining ongoing connectivity. 808 When a system wishes to verify connectivity, it initiates a Poll 809 Sequence. It starts periodically sending BFD Control packets with 810 the Poll (P) bit set, at the negotiated transmission rate. When a 811 system receives such a packet, it immediately replies with a BFD 812 Control packet of its own, with the Poll (P) bit clear, and the Final 813 (F) bit set. The receipt of a reply to a Poll terminates the Poll 814 Sequence. If no response is received to a Poll, the Poll is repeated 815 until the detection time expires, at which point the session is 816 declared to be down. 818 The detection time in Demand mode is calculated differently than in 819 Asynchronous mode; it is based on the transmit rate of the local 820 system, rather than the transmit rate of the remote system. This 821 ensures that the Poll Sequence mechanism works properly. See section 822 6.7.8 for more details. 824 Note that this mechanism requires that the detection time negotiated 825 is greater than the round trip time between the two systems, or the 826 Poll mechanism will always fail. Enforcement of this requirement is 827 outside the scope of this specification. 829 Demand mode MAY be enabled or disabled at any time by setting or 830 clearing the Demand (D) bit in the BFD Control packet, without 831 affecting the BFD session state. 833 Because the underlying detection mechanism is unspecified, and may 834 differ between the two systems, the overall detection time 835 characteristics of the path will not be fully known to either system. 836 The total detection time for a particular system is the sum of the 837 time prior to the initiation of the Poll Sequence, plus the 838 calculated detection time. 840 6.6. Authentication 842 An optional Authentication Section may be present in the BFD Control 843 packet. In its generic form, the purpose of the Authentication 844 Section is to carry all necessary information, based on the 845 authentication type in use, to allow the receiving system to 846 determine the validity of the received packet. The exact mechanism 847 depends on the authentication type in use, but in general the 848 transmitting system will put information in the Authentication 849 Section that vouches for the packet's validity, and the receiving 850 system will examine the Authentication Section and either accept the 851 packet for further processing, or discard it. 853 Note that in the subsections below, to "accept" a packet means only 854 that the packet has passed authentication; it may in fact be 855 discarded for other reasons as described in the general packet 856 reception rules described in section 6.7.6. 858 Implementations supporting authentication MUST support SHA1 859 authentication. Other forms of authentication are optional. 861 6.6.1. Enabling and Disabling Authentication 863 It may be desirable to enable or disable authentication on a session 864 without disturbing the session state. The exact mechanism for doing 865 so is outside the scope of this specification. However, it is useful 866 to point out some issues in supporting this mechanism. 868 In a simple implementation, a BFD session will fail when 869 authentication is either turned on or turned off, because the packet 870 acceptance rules essentially require the local and remote machines to 871 do so in a more or less synchronized fashion (within the detect 872 time)--a packet with authentication will only be accepted if 873 authentication is "in use" (and likewise packets without 874 authentication. 876 One possible approach is to build an implementation such that 877 authentication is configured, but not considered "in use" until the 878 first packet containing a matching authentication section is received 879 (providing the necessary synchronization.) Likewise, authentication 880 could be configured off, but still considered "in use" until the 881 receipt of the first packet without the authentication section. 883 In order to avoid security risks, implementations using this method 884 should only allow the authentication state to be changed once without 885 some form of intervention (so that authentication cannot be turned on 886 and off repeatedly simply based on the receipt of BFD Control packets 887 from remote systems.) 889 6.6.2. Simple Password Authentication 891 The most straightforward (and weakest) form of authentication is 892 Simple Password Authentication. In this method of authentication, 893 one or more Passwords (with corresponding Key IDs) are configured in 894 each system and one of these Password/ID pairs is carried in each BFD 895 Control packet. The receiving system accepts the packet if the 896 Password and Key ID matches one of the Password/ID pairs configured 897 in that system. 899 Transmission Using Simple Password Authentication 901 The currently selected password and Key ID for the session MUST be 902 stored in the Authentication Section of each outgoing BFD Control 903 packet. The Auth Type field MUST be set to 1 (Simple Password.) 904 The Auth Len field MUST be set to the proper length (4 to 19 905 bytes.) 907 Reception Using Simple Password Authentication 909 If the received BFD Control packet does not contain an 910 Authentication Section, or the Auth Type is not 1 (Simple 911 Password), then the received packet MUST be discarded. 913 If the Auth Key ID field does not match the ID of a configured 914 password, the received packet MUST be discarded. 916 If the Auth Len field is not equal to the length of the password 917 selected by the Key ID, plus three, the packet MUST be discarded. 919 If the Password field does not match the password selected by the 920 Key ID, the packet MUST be discarded. 922 Otherwise, the packet MUST be accepted. 924 6.6.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 926 The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are 927 very similar to those used in other protocols. In these methods of 928 authentication, one or more secret keys (with corresponding Key IDs) 929 are configured in each system. One of the Keys is included in an MD5 930 [MD5] checksum calculated over the outgoing BFD Control packet, but 931 the Key itself is not carried in the packet. To help avoid replay 932 attacks, a sequence number is also carried in each packet. For Keyed 933 MD5, the sequence number is occasionally incremented. For Meticulous 934 Keyed MD5, the sequence number is incremented on every packet. 936 The receiving system accepts the packet if the Key ID matches one of 937 the configured Keys, an MD5 checksum including the selected key 938 matches that carried in the packet, and if the sequence number is 939 greater than or equal to the last sequence number received (for Keyed 940 MD5), or strictly greater than the last sequence number received (for 941 Meticulous Keyed MD5.) 943 Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication 945 The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous 946 Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key 947 ID field MUST be set to the ID of the current authentication key. 948 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 950 The current authentication key value MUST be placed into the Auth 951 Key/Checksum field. An MD5 checksum MUST be calculated over the 952 entire BFD control packet. The resulting checksum MUST be stored 953 in the Auth Key/Checksum field prior to transmission (replacing 954 the secret key, which MUST NOT be carried in the packet.) 956 For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular 957 fashion (when treated as an unsigned 32 bit value.) 958 bfd.XmitAuthSeq SHOULD be incremented when the session state 959 changes, or when the transmitted BFD Control packet carries 960 different contents than the previously transmitted packet. The 961 decision as to when to increment bfd.XmitAuthSeq is outside the 962 scope of this specification. See the section entitled "Security 963 Considerations" below for a discussion. 965 For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a 966 circular fashion (when treated as an unsigned 32 bit value.) 968 Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication 970 If the received BFD Control packet does not contain an 971 Authentication Section, or the Auth Type is not correct (2 for 972 Keyed MD5, or 3 for Meticulous Keyed MD5), then the received 973 packet MUST be discarded. 975 If the Auth Key ID field does not match the ID of a configured 976 authentication key, the received packet MUST be discarded. 978 If the Auth Len field is not equal to 24, the packet MUST be 979 discarded. 981 Replace the contents of the Auth Key/Checksum field with the 982 authentication key selected by the received Auth Key ID field. If 983 the MD5 checksum of the entire BFD Control packet is not equal to 984 the received value of the Auth Key/Checksum field, the received 985 packet MUST be discarded. 987 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 988 Keyed MD5, if the Sequence Number lies outside of the range of 989 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 990 treated as an unsigned 32 bit circular number space), the received 991 packet MUST be discarded. For Meticulous Keyed MD5, if the 992 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 993 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 994 unsigned 32 bit circular number space, the received packet MUST be 995 discarded. 997 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 998 1, bfd.RcvAuthSeq MUST be set to the value of the received 999 Sequence Number field, and the received packet MUST be accepted. 1001 6.6.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1003 The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms 1004 are very similar to those used in other protocols. In these methods 1005 of authentication, one or more secret keys (with corresponding Key 1006 IDs) are configured in each system. One of the Keys is included in a 1007 SHA1 [SHA1] checksum calculated over the outgoing BFD Control packet, 1008 but the Key itself is not carried in the packet. To help avoid 1009 replay attacks, a sequence number is also carried in each packet. 1010 For Keyed SHA1, the sequence number is occasionally incremented. For 1011 Meticulous Keyed SHA1, the sequence number is incremented on every 1012 packet. 1014 The receiving system accepts the packet if the Key ID matches one of 1015 the configured Keys, a SHA1 checksum including the selected key 1016 matches that carried in the packet, and if the sequence number is 1017 greater than or equal to the last sequence number received (for Keyed 1018 SHA1), or strictly greater than the last sequence number received 1019 (for Meticulous Keyed SHA1.) 1021 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 1022 Authentication 1024 The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous 1025 Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key 1026 ID field MUST be set to the ID of the current authentication key. 1027 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1029 The current authentication key value MUST be placed into the Auth 1030 Key/Checksum field. A SHA1 checksum MUST be calculated over the 1031 entire BFD control packet. The resulting checksum MUST be stored 1032 in the Auth Key/Checksum field prior to transmission (replacing 1033 the secret key, which MUST NOT be carried in the packet.) 1035 For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular 1036 fashion (when treated as an unsigned 32 bit value.) 1037 bfd.XmitAuthSeq SHOULD be incremented when the session state 1038 changes, or when the transmitted BFD Control packet carries 1039 different contents than the previously transmitted packet. The 1040 decision as to when to increment bfd.XmitAuthSeq is outside the 1041 scope of this specification. See the section entitled "Security 1042 Considerations" below for a discussion. 1044 For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in 1045 a circular fashion (when treated as an unsigned 32 bit value.) 1047 Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1049 If the received BFD Control packet does not contain an 1050 Authentication Section, or the Auth Type is not correct (4 for 1051 Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received 1052 packet MUST be discarded. 1054 If the Auth Key ID field does not match the ID of a configured 1055 authentication key, the received packet MUST be discarded. 1057 If the Auth Len field is not equal to 28, the packet MUST be 1058 discarded. 1060 Replace the contents of the Auth Key/Checksum field with the 1061 authentication key selected by the received Auth Key ID field. If 1062 the SHA1 checksum of the entire BFD Control packet is not equal to 1063 the received value of the Auth Key/Checksum field, the received 1064 packet MUST be discarded. 1066 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1067 Keyed SHA1, if the Sequence Number lies outside of the range of 1068 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1069 treated as an unsigned 32 bit circular number space), the received 1070 packet MUST be discarded. For Meticulous Keyed SHA1, if the 1071 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1072 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1073 unsigned 32 bit circular number space, the received packet MUST be 1074 discarded. 1076 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1077 1, bfd.RcvAuthSeq MUST be set to the value of the received 1078 Sequence Number field, and the received packet MUST be accepted. 1080 6.7. Functional Specifics 1082 The following section of this specification is normative. The means 1083 by which this specification is achieved is outside the scope of this 1084 specification. 1086 When a system is said to have "the Echo function active," it means 1087 that the system is sending BFD Echo packets, implying that the 1088 session is Up and the other system has signalled its willingness to 1089 loop back Echo packets. 1091 When a system is said to have "Demand mode active," it means that 1092 bfd.DemandModeDesired is 1 in the local system (see State Variables 1093 below), the remote system is signalling with the Demand (D) bit set, 1094 and that the session is Up. 1096 6.7.1. State Variables 1098 A minimum amount of information about a session needs to be tracked 1099 in order to achieve the elements of procedure described here. The 1100 following is a set of state variables that are helpful in describing 1101 the mechanisms of BFD. Any means of tracking this state may be used 1102 so long as the protocol behaves as described. 1104 When the text refers to initializing a state variable, this takes 1105 place only at the time that the session (and the corresponding state 1106 variables) is created. The state variables are subsequently 1107 manipulated by the state machine and are never reinitialized, even if 1108 the session fails and is reestablished. 1110 All state variables in this specification are of the form "bfd.Xx" 1111 and should not be confused with fields carried in the protocol 1112 packets, which are always spelled out to match the names in section 1113 4. 1115 bfd.SessionState 1117 The perceived state of the session (Init, Up, Down, or 1118 AdminDown.) The exact action taken when the session state 1119 changes is outside the scope of this specification, though it 1120 is expected that this state change (particularly to and from Up 1121 state) is reported to other components of the system. This 1122 variable MUST be initialized to Down. 1124 bfd.LocalDiscr 1126 The local discriminator for this BFD session, used to uniquely 1127 identify it. It MUST be unique across all BFD sessions on this 1128 system, and nonzero. It SHOULD be set to a random (but still 1129 unique) value to improve security. The value is otherwise 1130 outside the scope of this specification. 1132 bfd.RemoteDiscr 1134 The remote discriminator for this BFD session. This is the 1135 discriminator chosen by the remote system, and is totally 1136 opaque to the local system. This MUST be initialized to zero. 1138 bfd.LocalDiag 1140 The diagnostic code specifying the reason for the most recent 1141 local session state chage. This MUST be initialized to zero 1142 (No Diagnostic.) 1144 bfd.DesiredMinTxInterval 1146 The minimum interval, in microseconds, between transmitted BFD 1147 Control packets that this system would like to use at the 1148 current time. The actual interval is negotiated between the 1149 two systems. This MUST be initialized to a value of at least 1150 one second (1,000,000 microseconds) according to the rules 1151 described in section 6.7.3. The setting of this variable is 1152 otherwise outside the scope of this specification. 1154 bfd.RequiredMinRxInterval 1156 The minimum interval, in microseconds, between received BFD 1157 Control packets that this system requires. The setting of this 1158 variable is outside the scope of this specification. 1160 bfd.DemandModeDesired 1162 Set to 1 if the local system wishes to use Demand mode, or 0 if 1163 not. 1165 bfd.DetectMult 1167 The desired detect time multiplier for BFD Control packets. 1168 The negotiated Control packet transmission interval, multiplied 1169 by this variable, will be the detection time for this session 1170 (as seen by the remote system.) This variable MUST be a 1171 nonzero integer, and is otherwise outside the scope of this 1172 specification. See section 6.7.4 for further information. 1174 bfd.AuthType 1176 The authentication type in use for this session, as defined in 1177 section 4.1, or zero if no authentication is in use. 1179 bfd.RcvAuthSeq 1181 A 32 bit unsigned integer containing the next sequence number 1182 for keyed MD5 or SHA1 authentication expected to be received. 1183 The initial value is unimportant. 1185 bfd.XmitAuthSeq 1187 A 32 bit unsigned integer containing the next sequence number 1188 for keyed MD5 or SHA1 authentication to be transmitted. This 1189 variable MUST be initialized to a random 32 bit value. 1191 bfd.AuthSeqKnown 1193 Set to 1 if the next sequence number for keyed MD5 or SHA1 1194 authentication expected to be received is known, or 0 if it is 1195 not known. This variable MUST be initialized to zero. 1197 This variable MUST be set to zero after no packets have been 1198 received on this session for at least twice the Detection Time. 1199 This ensures that the sequence number can be resynchronized if 1200 the remote system restarts. 1202 6.7.2. Timer Negotiation 1204 The time values used to determine BFD packet transmission intervals 1205 and the session detection time are continuously negotiated, and thus 1206 may be changed at any time. The negotiation and time values are 1207 independent in each direction for each session. Packets are always 1208 periodically transmitted in Asynchronous mode, and are periodically 1209 transmitted during Poll Sequences when in Demand mode. 1211 Each system reports in the BFD Control packet how rapidly it would 1212 like to transmit BFD packets, as well as how rapidly it is prepared 1213 to receive them. With the exceptions listed in the remainder of this 1214 section, a system MUST NOT transmit BFD Control packets with an 1215 interval less than the larger of bfd.DesiredMinTxInterval and the 1216 received Required Min RX Interval field. In other words, the system 1217 reporting the slower rate determines the transmission rate. 1219 The periodic transmission of BFD Control packets SHOULD be jittered 1220 by up to 25%, that is, the interval SHOULD be reduced by a random 1221 value of 0 to 25%, in order to avoid self-synchronization. Thus, the 1222 average interval between packets may be up to 12.5% less than that 1223 negotiated. 1225 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 1226 Control packets MUST be no more than 90% of the negotiated 1227 transmission interval, and MUST be no less than 75% of the negotiated 1228 transmission interval. This is to ensure that, on the remote system, 1229 the calculated DetectTime does not pass prior to the receipt of the 1230 next BFD Control packet. 1232 A BFD Control packet SHOULD be transmitted during the interval 1233 between periodic Control packet transmissions when the contents of 1234 that packet would differ from that in the previously transmitted 1235 packet (other than the Poll and Final bits) in order to more rapidly 1236 communicate a change in state. 1238 If a BFD Control packet is received with the Poll (P) bit set to 1, 1239 the receiving system MUST transmit a BFD Control packet with the Poll 1240 (P) bit clear and the Final (F) bit set as soon as practicable, 1241 without respect to the transmission timer or any other transmission 1242 limitations, without respect to the session state, and without 1243 respect to whether Demand mode is active. 1245 6.7.3. Timer Manipulation 1247 The time values used to determine BFD packet transmission intervals 1248 and the session detection time may be modified at any time without 1249 affecting the state of the session. When the timer parameters are 1250 changed for any reason, the requirements of this section apply. 1252 If Demand mode is active, and either bfd.DesiredMinTxInterval is 1253 changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST 1254 be initiated (see section 6.7.8). 1256 If Demand mode is not active, bfd.SessionState is Up, and either 1257 bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is 1258 changed, all subsequent transmitted Control packets MUST be sent with 1259 the Poll (P) bit set until a packet is received with the Final (F) 1260 bit set (except for those packets sent in response to received 1261 Polls.) 1263 If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, 1264 the actual transmission interval used MUST NOT change until a Control 1265 packet is received with the Final (F) bit set. This is to ensure 1266 that the remote system updates its Detect Time before the 1267 transmission interval increases. 1269 If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, 1270 the calculated detection time for the remote system MUST NOT change 1271 until a Control packet is received with the Final (F) bit set. This 1272 is to ensure that the remote system is transmitting packets at the 1273 higher rate (and those packets are being received) prior to the 1274 detection time being reduced. 1276 When bfd.SessionState is not Up, the system MUST set 1277 bfd.DesiredMinTxInterval to a value of not less than one second 1278 (1,000,000 microseconds.) This is intended to ensure that the 1279 bandwidth consumed by BFD sessions that are not Up is negligible, 1280 particularly in the case where a neighbor may not be running BFD. 1282 When the Echo function is active, a system SHOULD set 1283 bfd.DesiredMinTxInterval to a value of not less than one second 1284 (1,000,000 microseconds.) This is intended to keep BFD Control 1285 traffic at a negligible level, since the actual detection function is 1286 being performed using BFD Echo packets. 1288 6.7.4. Calculating the Detection Time 1290 The Detection Time (the period of time without receiving BFD packets 1291 after which the session is determined to have failed) is not carried 1292 explicitly in the protocol. Rather, it is calculated independently 1293 in each direction by the receiving system based on the negotiated 1294 transmit interval and the detection multiplier. Note that, in 1295 Asynchronous mode, there may be different detection times in each 1296 direction. 1298 The calculation of the Detection Time is slightly different when in 1299 Demand mode versus Asynchronous mode. 1301 In Asynchronous mode, the Detection Time calculated in the local 1302 system is equal to the value of Detect Mult received from the remote 1303 system, multiplied by the agreed transmit interval of the remote 1304 system (the greater of bfd.RequiredMinRxInterval and the last 1305 received Desired Min TX Interval.) The Detect Mult value is (roughly 1306 speaking, due to jitter) the number of packets that have to be missed 1307 in a row to declare the session to be down. 1309 If Demand mode is not active, and a period of time equal to the 1310 Detection Time passes without receiving a BFD Control packet from the 1311 remote system, and bfd.SessionState is Init or Up, the session has 1312 gone down--the local system MUST set bfd.SessionState to Down and 1313 bfd.LocalDiag to 1 (Control Detection Time Expired.) 1315 In Demand mode, the Detection Time calculated in the local system is 1316 equal to bfd.DetectMult, multiplied by the agreed transmit interval 1317 of the local system (the greater of bfd.DesiredMinTxInterval and the 1318 last received Required Min RX Interval.) bfd.DetectMult is (roughly 1319 speaking, due to jitter) the number of packets that have to be missed 1320 in a row to declare the session to be down. 1322 If Demand mode is active, and a period of time equal to the Detection 1323 Time passes after the initiation of a Poll Sequence (the transmission 1324 of the first BFD Control packet with the Poll bit set), the session 1325 has gone down--the local system MUST set bfd.SessionState to Down, 1326 and bfd.LocalDiag to 1 (Control Detection Time Expired.) 1328 (Note that a packet is considered to have been received, for the 1329 purposes of Detection Time expiration, only if it has not been 1330 "discarded" according to the rules of section 6.7.6.) 1332 6.7.5. Detecting Failures with the Echo Function 1334 When the Echo function is active and a sufficient number of Echo 1335 packets have not arrived as they should, the session has gone 1336 down--the local system MUST set bfd.SessionState to Down, and 1337 bfd.LocalDiag to 2 (Echo Function Failed.) 1339 The means by which the Echo function failures are detected is outside 1340 of the scope of this specification. Any means which will detect a 1341 communication failure is acceptable. 1343 6.7.6. Reception of BFD Control Packets 1345 When a BFD Control packet is received, the following procedure MUST 1346 be followed, in the order specified. If the packet is discarded 1347 according to these rules, processing of the packet MUST cease at that 1348 point. 1350 If the version number is not correct (1), the packet MUST be 1351 discarded. 1353 If the Length field is less than the minimum correct value (24 if 1354 the A bit is clear, or 26 if the A bit is set), the packet MUST be 1355 discarded. 1357 If the Length field is greater than the payload of the 1358 encapsulating protocol, the packet MUST be discarded. 1360 If the Detect Mult field is zero, the packet MUST be discarded. 1362 If the My Discriminator field is zero, the packet MUST be 1363 discarded. 1365 If the Your Discriminator field is nonzero, it MUST be used to 1366 select the session with which this BFD packet is associated. If 1367 no session is found, the packet MUST be discarded. 1369 If the Your Discriminator field is zero and the State field is not 1370 Down or AdminDown, the packet MUST be discarded. 1372 If the Your Discriminator field is zero, the session MUST be 1373 selected based on some combination of other fields, possibly 1374 including source addressing information, the My Discriminator 1375 field, and the interface over which the packet was received. The 1376 exact method of selection is application-specific and is thus 1377 outside the scope of this specification. If a matching session is 1378 not found, a new session may be created, or the packet may be 1379 discarded. This choice is outside the scope of this 1380 specification. 1382 If the A bit is set and no authentication is in use (bfd.AuthType 1383 is zero), the packet MUST be discarded. 1385 If the A bit is clear and authentication is in use (bfd.AuthType 1386 is nonzero), the packet MUST be discarded. 1388 If the A bit is set, the packet MUST be authenticated under the 1389 rules of section 6.6, based on the authentication type in use 1390 (bfd.AuthType.) This may cause the packet to be discarded. 1392 Set bfd.RemoteDiscr to the value of My Discriminator. 1394 If the Required Min Echo RX Interval field is zero, the 1395 transmission of Echo packets, if any, MUST cease. 1397 If Demand mode is active, a Poll Sequence is being transmitted by 1398 the local system, and the Final (F) bit in the received packet is 1399 set, the Poll Sequence MUST be terminated. 1401 If Demand mode is not active, the Final (F) bit in the received 1402 packet is set, and the local system has been transmitting packets 1403 with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in 1404 subsequent transmitted packets. 1406 Update the Detection Time as described in section 6.7.4. 1408 If received state is AdminDown 1409 If bfd.SessionState is not Down 1410 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1411 Set bfd.SessionState to Down 1413 Else 1414 If bfd.SessionState is AdminDown 1415 Discard the packet 1417 Else if bfd.SessionState is Down 1418 If received State is Down 1419 Set bfd.SessionState to Init 1420 Else if received State is Init 1421 Set bfd.SessionState to Up 1423 Else if bfd.SessionState is Init 1424 If received State is Init or Up 1425 Set bfd.SessionState to Up 1427 Else (bfd.SessionState is Up) 1428 If received State is Down 1429 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1430 Set bfd.SessionState to Down 1432 Update the transmit interval as described in section 6.7.2. 1434 If the Demand (D) bit is set and bfd.DemandModeDesired is 1, 1435 and bfd.SessionState is Up, Demand mode is active. 1437 If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, 1438 or bfd.SessionState is not Up, Demand mode is not 1439 active. 1441 If the Poll (P) bit is set, send a BFD Control packet to the 1442 remote system with the Poll (P) bit clear, and the Final (F) bit 1443 set. 1445 If the packet was not discarded, it has been received for purposes of 1446 the Detection Time expiration rules in section 6.7.4. 1448 6.7.7. Transmitting BFD Control Packets 1450 BFD Control packets MUST be transmitted periodically at the rate 1451 determined according to section 6.7.2, except as specified in this 1452 section. 1454 The transmit interval MUST be recalculated whenever 1455 bfd.DesiredMinTxInterval changes, or whenever the received Required 1456 Min RX Interval changes, and is equal to the greater of those two 1457 values. See sections 6.7.2 and 6.7.3 for details on transmit timers. 1459 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 1460 zero and the system is taking the Passive role. 1462 A system MUST NOT periodically transmit BFD Control packets if Demand 1463 mode is active and a Poll Sequence is not being transmitted. 1465 A system MUST send a BFD Control packet in response to a received BFD 1466 Control Packet with the Poll (P) bit set, regardless of the BFD 1467 session state. The packet sent in response MUST NOT have the Poll 1468 (P) bit set, and MUST have the Final (F) bit set. A system MAY limit 1469 the rate at which such packets are transmitted. If rate limiting is 1470 in effect, the advertised value of Desired Min TX Interval must be 1471 greater than or equal to the interval between transmitted packets 1472 imposed by the rate limiting function. 1474 A BFD Control packet SHOULD be transmitted between normally scheduled 1475 transmissions when the contents of that packet would differ from 1476 those in the previously transmitted packet (other than the Poll and 1477 Final bits) in order to more rapidly communicate a change in state. 1479 The contents of transmitted BFD Control packets MUST be set as 1480 follows: 1482 Version 1484 Set to the current version number (1). 1486 Diagnostic (Diag) 1488 Set to bfd.LocalDiag. 1490 State (Sta) 1492 Set to the value indicated by bfd.SessionState. 1494 Poll (P) 1496 Set to 1 if the local system is sending a Poll Sequence or is 1497 required to do so according to the requirements of section 6.7.3, 1498 or 0 if not. 1500 Final (F) 1502 Set to 1 if the local system is responding to a Control packet 1503 received with the Poll (P) bit set, or 0 if not. 1505 Control Plane Independent (C) 1507 Set to 1 if the local system's BFD implementation is independent 1508 of the control plane (it can continue to function through a 1509 disruption of the control plane.) 1511 Authentication Present (A) 1513 Set to 1 if authentication is in use on this session (bfd.AuthType 1514 is nonzero), or 0 if not. 1516 Demand (D) 1518 Set to bfd.DemandModeDesired. 1520 Reserved (R) 1522 Set to 0. 1524 Detect Mult 1526 Set to bfd.DetectMult. 1528 Length 1530 Set to the appropriate length, based on the fixed header length 1531 (24) plus any Authentication Section. 1533 My Discriminator 1535 Set to bfd.LocalDiscr. 1537 Your Discriminator 1539 Set to bfd.RemoteDiscr. 1541 Desired Min TX Interval 1543 Set to bfd.DesiredMinTxInterval. 1545 Required Min RX Interval 1547 Set to bfd.RequiredMinRxInterval. 1549 Required Min Echo RX Interval 1551 Set to the minimum required Echo packet receive interval for this 1552 session. If this field is set to zero, the local system is 1553 unwilling or unable to loop back BFD Echo packets to the remote 1554 system, and the remote system will not send Echo packets. 1556 Authentication Section 1558 Included and set according to the rules in section 6.6 if 1559 authentication is in use (bfd.AuthType is nonzero.) Otherwise 1560 this section is not present. 1562 6.7.8. Initiation of a Poll Sequence 1564 If Demand mode is active, a Poll Sequence MUST be initiated whenever 1565 the contents of the next BFD Control packet to be sent would be 1566 different than the contents of the previous packet, with the 1567 exception of the Poll (P) and Final (F) bits. This ensures that 1568 parameter changes are transmitted to the remote system. Note that if 1569 the I Hear You (H) bit is changing to zero, the session is going down 1570 and Demand mode will no longer be active. 1572 If Demand mode is active, a Poll Sequence SHOULD be initiated 1573 whenever the system feels the need to verify connectivity with the 1574 remote system. The conditions under which this is desirable are 1575 outside the scope of this specification. 1577 If a Poll Sequence is being sent, and a new Poll Sequence is 1578 initiated due to one of the above conditions, the detection interval 1579 MUST be restarted in order to ensure that a full Poll Sequence is 1580 transmitted under the new conditions. 1582 6.7.9. Reception of BFD Echo Packets 1584 A received BFD Echo packet MUST be demultiplexed to the appropriate 1585 session for processing. A means of detecting missing Echo packets 1586 MUST be implemented, which most likely involves processing of the 1587 Echo packets that are received. The processing of received Echo 1588 packets is otherwise outside the scope of this specification. 1590 6.7.10. Transmission of BFD Echo Packets 1592 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 1593 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 1594 Control packet received from the remote system contains a nonzero 1595 value in Required Min Echo RX Interval. 1597 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 1598 interval between transmitted BFD Echo packets MUST NOT be less than 1599 the value advertised by the remote system in Required Min Echo RX 1600 Interval, except as follows: 1602 A 25% jitter MAY be applied to the rate of transmission, such that 1603 the actual interval MAY be between 75% and 100% of the advertised 1604 value. A single BFD Echo packet MAY be transmitted between 1605 normally scheduled Echo transmission intervals. 1607 The transmission of BFD Echo packets is otherwise outside the scope 1608 of this specification. 1610 6.7.11. Min Rx Interval Change 1612 When it is desired to change the rate at which BFD Control packets 1613 arrive from the remote system, bfd.RequiredMinRxInterval can be 1614 changed at any time to any value. The new value will be transmitted 1615 in the next outgoing Control packet, and the remote system will 1616 adjust accordingly. See sections 6.7.3 and 6.7.8 for further 1617 requirements. 1619 6.7.12. Min Tx Interval Change 1621 When it is desired to change the rate at which BFD Control packets 1622 are transmitted to the remote system (subject to the requirements of 1623 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1624 any time to any value. The rules in sections 6.7.3 and 6.7.8 apply. 1626 6.7.13. Detect Multiplier Change 1628 When it is desired to change the detect multiplier, the value of 1629 bfd.DetectMult can be changed to any nonzero value. The new value 1630 will be transmitted with the next BFD Control packet. See section 1631 6.7.8 for additional requirements. 1633 6.7.14. Enabling or Disabling The Echo Function 1635 If it is desired to start or stop the transmission of BFD Echo 1636 packets, this MAY be done at any time (subject to the transmission 1637 requirements detailed in section 6.7.10.) 1639 If it is desired to enable or disable the looping back of received 1640 BFD Echo packets, this MAY be done at any time by changing the value 1641 of Required Min RX Interval to zero or nonzero in outgoing BFD 1642 Control packets. 1644 6.7.15. Enabling or Disabling Demand Mode 1646 If it is desired to start or stop Demand mode, this MAY be done at 1647 any time by setting bfd.DemandModeDesired to the proper value. If 1648 Demand mode is no longer active, the system MUST begin transmitting 1649 periodic BFD Control packets as described in section 6.7.7. 1651 6.7.16. Forwarding Plane Reset 1653 When the forwarding plane in the local system is reset for some 1654 reason, such that the remote system can no longer rely on the local 1655 forwarding state, the local system MUST set bfd.LocalDiag to 4 1656 (Forwarding Plane Reset), and set bfd.SessionState to Down. 1658 6.7.17. Administrative Control 1660 There may be circumstances where it is desirable to administratively 1661 enable or disable a BFD session. When this is desired, the following 1662 procedure MUST be followed: 1664 If enabling session 1665 Set bfd.SessionState to Down 1667 Else 1668 Set bfd.SessionState to AdminDown 1669 Set bfd.LocalDiag to an appropriate value 1670 Cease the transmission of BFD Echo packets 1672 If signalling is received from outside BFD that the underlying path 1673 has failed, an implementation MAY adminstratively disable the session 1674 with the diagnostic Path Down. 1676 Other scenarios MAY use the diagnostic Administratively Down. 1678 6.7.18. Concatenated Paths 1680 If the path being monitored by BFD is concatenated with other paths, 1681 it may be desirable to propagate the indication of a failure of one 1682 of those paths across the BFD session (providing an interworking 1683 function for liveness monitoring between BFD and other technologies.) 1685 Two diagnostic codes are defined for this purpose: Concatenated Path 1686 Down and Reverse Concatenated Path Down. The first propagates 1687 forward path failures (in which the concatenated path fails in the 1688 direction toward the interworking system), and the second propagates 1689 reverse path failures (in which the concatenated path fails in the 1690 direction away from the interworking system, assuming a bidirectional 1691 link.) 1693 A system MAY signal one of these failure states by simply setting 1694 bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD 1695 session is not taken down. If Demand Mode is not active, no other 1696 action is necessary, as the diagnostic code will be carried via the 1697 periodic transmission of BFD Control packets. If Demand Mode is 1698 active, a Poll Sequence MUST be initiated to ensure that the 1699 diagnostic code is transmitted. Note that if the BFD session 1700 subsequently fails, the diagnostic code will be overwritten with a 1701 code detailing the cause of the failure. It is up to the 1702 interworking agent to perform the above procedure again, once the BFD 1703 session reaches Up state, if the propagation of the concatenated path 1704 failure is to resume. 1706 Contributors 1708 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 1709 significant contributors to this document. 1711 Acknowledgments 1713 This document was inspired by (and is intended to replace) the 1714 Protocol Liveness Protocol draft, written by Kireeti Kompella. 1716 Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 1717 et al. 1719 The authors would also like to thank Mike Shand, John Scudder, 1720 Stewart Bryant, Pekka Savola, and Richard Spencer for their 1721 substantive input. 1723 Security Considerations 1725 As BFD may be tied into the stability of the network infrastructure 1726 (such as routing protocols), the effects of an attack on a BFD 1727 session may be very serious. This ultimately has denial-of-service 1728 effects, as links may be declared to be down (or falsely declared to 1729 be up.) 1730 When BFD is run over network layer protocols, a significant denial- 1731 of-service risk is created, as BFD packets may be trivial to spoof. 1732 When the session is directly connected across a single link 1733 (physical, or a secure tunnel such as IPsec), the TTL or Hop Count 1734 MUST be set to the maximum on transmit, and checked to be equal to 1735 the maximum value on reception (and the packet dropped if this is not 1736 the case.) See [GTSM] for more information on this technique. If 1737 BFD is run across multiple hops or an insecure tunnel (such as GRE), 1738 the Authentication Section SHOULD be utilized. 1740 The level of security provided by the Authentication Section varies 1741 based on the authentication type used. Simple Password 1742 authentication is obviously only as secure as the secrecy of the 1743 passwords used, and should be considered only if the BFD session is 1744 guaranteed to be run over an infrastructure not subject to packet 1745 interception. Its chief advantage is that it minimizes the 1746 computational effort required for authentication. 1748 Keyed MD5 authentication is much stronger than Simple Password 1749 authentication since the keys cannot be discerned by intercepting 1750 packets. It is vulnerable to replay attacks in between increments of 1751 the sequence number. The sequence number can be incremented as 1752 seldom (or as often) as desired, trading off resistance to replay 1753 attacks with the computational effort required for authentication. 1755 Meticulous Keyed MD5 authentication is stronger yet, as it requires 1756 the sequence number to be incremented for every packet. Replay 1757 attack vulnerability is reduced due to the requirement that the 1758 sequence number must be incremented on every packet, the window size 1759 of acceptable packets is small, and the initial sequence number is 1760 randomized. There is still a window of attack at the beginning of 1761 the session while the sequence number is being determined. This 1762 authentication scheme requires an MD5 calculation on every packet 1763 transmitted and received. 1765 Using SHA1 rather than MD5 is believed to have stronger security 1766 properties. All comments about MD5 in this section also apply to 1767 SHA1. 1769 If both systems randomize their Local Discriminator values at the 1770 beginning of a session, replay attacks may be further mitigated, 1771 regardless of the authentication type in use. Since the Local 1772 Discriminator may be changed at any time during a session, this 1773 mechanism may also help mitigate attacks. 1775 Normative References 1777 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 1778 (GTSM)", RFC 3682, February 2004. 1780 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 1781 Requirement Levels", RFC 2119, March 1997. 1783 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1784 1992. 1786 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1788 [SHA1] "Secure Hash Standard", United States of America, National 1789 Institute of Science and Technology, Federal Information 1790 Processing Standard (FIPS) 180-1, April 1993. 1792 Authors' Addresses 1794 Dave Katz 1795 Juniper Networks 1796 1194 N. Mathilda Ave. 1797 Sunnyvale, California 94089-1206 USA 1798 Phone: +1-408-745-2000 1799 Email: dkatz@juniper.net 1801 Dave Ward 1802 Cisco Systems 1803 170 W. Tasman Dr. 1804 San Jose, CA 95134 USA 1805 Phone: +1-408-526-4000 1806 Email: dward@cisco.com 1808 Changes from the previous draft 1810 The primary technical change in this draft from the previous version 1811 is an updated state machine, and an updated packet format to effect 1812 it (with an appropriate change to the version number.) This version 1813 of the draft is incompatible with previous versions, and will not 1814 interoperate with them (but the two versions will ignore one 1815 another.) 1817 The packet transmission rules were relaxed to allow multiple "extra" 1818 packets to be sent between regularly scheduled transmissions, in 1819 order to take advantage of the new state machine to speed up session 1820 establishment. 1822 Verbiage regarding the Poll/Final bits was updated to state that 1823 Polls must be sent when in Up state and the timing parameters change 1824 (but that Finals in response to Polls are sent in any state.) 1826 A mistake in the description of the calculation of the Detection Time 1827 while in Demand Mode was corrected. 1829 The fact that SHA1 authentication is mandatory only when implementing 1830 authentication was clarified. 1832 Otherwise, the changes in this draft from the previous version are 1833 cosmetic and/or editorial. 1835 IPR Notice 1837 The IETF has been notified of intellectual property rights claimed in 1838 regard to some or all of the specification contained in this 1839 document. For more information consult the online list of claimed 1840 rights. 1842 The IETF takes no position regarding the validity or scope of any 1843 intellectual property or other rights that might be claimed to 1844 pertain to the implementation or use of the technology described in 1845 this document or the extent to which any license under such rights 1846 might or might not be available; neither does it represent that it 1847 has made any effort to identify any such rights. Information on the 1848 IETF's procedures with respect to rights in standards-track and 1849 standards-related documentation can be found in BCP-11. Copies of 1850 claims of rights made available for publication and any assurances of 1851 licenses to be made available, or the result of an attempt made to 1852 obtain a general license or permission for the use of such 1853 proprietary rights by implementors or users of this specification can 1854 be obtained from the IETF Secretariat. 1856 The IETF invites any interested party to bring to its attention any 1857 copyrights, patents or patent applications, or other proprietary 1858 rights which may cover technology that may be required to practice 1859 this standard. Please address the information to the IETF Executive 1860 Director. 1862 Full Copyright Notice 1864 Copyright (C) The Internet Society (2005). This document is subject 1865 to the rights, licenses and restrictions contained in BCP 78, and 1866 except as set forth therein, the authors retain all their rights. 1868 This document and the information contained herein are provided on an 1869 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1870 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1871 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1872 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1873 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1874 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1876 Acknowledgement 1878 Funding for the RFC Editor function is currently provided by the 1879 Internet Society. 1881 This document expires in September, 2005.