idnits 2.17.1 draft-ietf-bfd-base-01.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 1843. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1835), 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 3 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 1765, 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: August 2005 February, 2005 8 Bidirectional Forwarding Detection 9 draft-ietf-bfd-base-01.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 . . . . . . 17 72 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 18 73 6.5 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 18 74 6.6 Authentication . . . . . . . . . . . . . . . . . . . . . 19 75 6.6.1 Enabling and Disabling Authentication . . . . . . 20 76 6.6.2 Simple Password Authentication . . . . . . . . . . 20 77 6.6.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 21 78 6.6.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 23 79 6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 24 80 6.7.1 State Variables . . . . . . . . . . . . . . . . . 25 81 6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 27 82 6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 28 83 6.7.4 Calculating the Detection Time . . . . . . . . . . 29 84 6.7.5 Detecting Failures with the Echo Function . . . . 30 85 6.7.6 Reception of BFD Control Packets . . . . . . . . . 30 86 6.7.7 Transmitting BFD Control Packets . . . . . . . . . 33 87 6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 35 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 . . . . . . . . 37 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 |H|D|P|F|C|A|Rsv| 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 0. 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 I Hear You (H) 340 This bit is set to 0 if the transmitting system either is not 341 receiving BFD packets from the remote system, or is in the process 342 of tearing down the BFD session for some reason. This bit is set 343 to 1 if the transmitting system believes it is communicating with 344 the remote system. See the Elements of Procedure below for more 345 details. 347 Demand (D) 349 If set, the transmitting system wishes to operate in Demand Mode. 350 If clear, the transmitting system does not wish to or is not 351 capable of operating in Demand Mode. 353 Poll (P) 355 If set, the transmitting system is requesting verification of 356 connectivity, or of a parameter change. If clear, the 357 transmitting system is not requesting verification. 359 Final (F) 361 If set, the transmitting system is responding to a received BFD 362 Control packet that had the Poll (P) bit set. If clear, the 363 transmitting system is not responding to a Poll. 365 Control Plane Independent (C) 367 If set, the transmitting system's BFD implementation does not 368 share fate with its control plane (in other words, BFD is 369 implemented in the forwarding plane and can continue to function 370 through disruptions in the control plane.) If clear, the 371 transmitting system's BFD implementation shares fate with its 372 control plane. 374 The use of this bit is application dependent and is outside the 375 scope of this specification. See specific application 376 specifications for details. 378 Authentication Present (A) 380 If set, the Authentication Section is present and the session is 381 to be authenticated. 383 Reserved (Rsv) 385 These bits must be zero on transmit, and ignored on receipt. 387 Detect Mult 389 Detect time multiplier. The negotiated transmit interval, 390 multiplied by this value, provides the detection time for the 391 transmitting system in Asynchronous mode. 393 Length 395 Length of the BFD Control packet, in bytes. 397 My Discriminator 399 A unique, nonzero discriminator value generated by the 400 transmitting system, used to demultiplex multiple BFD sessions 401 between the same pair of systems. 403 Your Discriminator 405 The discriminator received from the corresponding remote system. 406 This field reflects back the received value of My Discriminator, 407 or is zero if that value is unknown. 409 Desired Min TX Interval 411 This is the minimum interval, in microseconds, that the local 412 system would like to use when transmitting BFD Control packets. 414 Required Min RX Interval 416 This is the minimum interval, in microseconds, between received 417 BFD Control packets that this system is capable of supporting. 419 Required Min Echo RX Interval 421 This is the minimum interval, in microseconds, between received 422 BFD Echo packets that this system is capable of supporting. If 423 this value is zero, the transmitting system does not support the 424 receipt of BFD Echo packets. 426 Auth Type 428 The authentication type in use, if the Authentication Present (A) 429 bit is set. 431 0 - Reserved 432 1 - Simple Password 433 2 - Keyed MD5 434 3 - Meticulous Keyed MD5 435 4 - Keyed SHA1 436 5 - Meticulous Keyed SHA1 437 6-255 - Reserved for future use 439 Auth Len 441 The length, in bytes, of the authentication section, including the 442 Auth Type and Auth Len fields. 444 4.2. Simple Password Authentication Section Format 446 If the Autentication Present (A) bit is set in the header, and the 447 Authentication Type field contains 1 (Simple Password), the 448 Authentication Section has the following format: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Auth Type | Auth Len | Auth Key ID | Password... | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | ... | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Auth Type 460 The Authentication Type, which in this case is 1 (Simple 461 Password.) 463 Auth Len 465 The length of the Authentication Section, in bytes. For Simple 466 Password authentication, the length is equal to the password 467 length plus three. 469 Auth Key ID 471 The authentication key ID in use for this packet. This allows 472 multiple keys to be active simultaneously. 474 Password 476 The simple password in use on this session. The password MUST be 477 from 1 to 16 bytes in length. 479 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 481 If the Authentication Present (A) bit is set in the header, and the 482 Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous 483 Keyed MD5), the Authentication Section has the following format: 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Auth Type | Auth Len | Auth Key ID | Reserved | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Sequence Number | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Auth Key/Checksum... | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | ... | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Auth Type 499 The Authentication Type, which in this case is 2 (Keyed MD5) or 3 500 (Meticulous Keyed MD5). 502 Auth Len 504 The length of the Authentication Section, in bytes. For Keyed MD5 505 and Meticulous Keyed MD5 authentication, the length is 24. 507 Auth Key ID 509 The authentication key ID in use for this packet. This allows 510 multiple keys to be active simultaneously. 512 Reserved 514 This byte must be set to zero on transmit, and ignored on receipt. 516 Sequence Number 518 The Sequence Number for this packet. For Keyed MD5 519 Authentication, this value is incremented periodically. For 520 Meticulous Keyed MD5 Authentication, this value is incremented for 521 each successive packet transmitted for a session. This provides 522 protection against replay attacks. 524 Auth Key/Checksum 526 This field carries the 16 byte MD5 checksum for the packet. When 527 the checksum is calculated, the shared MD5 key is stored in this 528 field. (See section 6.6.3 for details.) 530 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 532 If the Authentication Present (A) bit is set in the header, and the 533 Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous 534 Keyed SHA1), the Authentication Section has the following format: 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Auth Type | Auth Len | Auth Key ID | Reserved | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Sequence Number | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Auth Key/Checksum... | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | ... | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Auth Type 550 The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 551 (Meticulous Keyed SHA1). 553 Auth Len 555 The length of the Authentication Section, in bytes. For Keyed 556 SHA1 and Meticulous Keyed SHA1 authentication, the length is 28. 558 Auth Key ID 560 The authentication key ID in use for this packet. This allows 561 multiple keys to be active simultaneously. 563 Reserved 565 This byte must be set to zero on transmit, and ignored on receipt. 567 Sequence Number 569 The Sequence Number for this packet. For Keyed SHA1 570 Authentication, this value is incremented periodically. For 571 Meticulous Keyed SHA1 Authentication, this value is incremented 572 for each successive packet transmitted for a session. This 573 provides protection against replay attacks. 575 Auth Key/Checksum 577 This field carries the 20 byte SHA1 checksum for the packet. When 578 the checksum is calculated, the shared SHA1 key is stored in this 579 field. (See section 6.6.4 for details.) 581 5. BFD Echo Packet Format 583 BFD Echo packets are sent in an encapsulation appropriate to the 584 environment. See the appropriate application document for the 585 specifics of particular environments. 587 The payload of a BFD Echo packet is a local matter, since only the 588 sending system ever processes the content. The only requirement is 589 that sufficient information is included to demultiplex the received 590 packet to the correct BFD session after it is looped back to the 591 sender. The contents are otherwise outside the scope of this 592 specification. 594 6. Elements of Procedure 596 This section discusses the normative requirements of the protocol in 597 order to achieve interoperability. It is important for implementors 598 to enforce only the requirements specified in this section, as 599 misguided pedantry has been proven by experience to adversely affect 600 interoperability. 602 Remember that all references of the form "bfd.Xx" refer to internal 603 state variables (defined in section 6.7.1), whereas all references to 604 "the Xxx field" refer to fields in the protocol packets themselves 605 (defined in section 4). 607 6.1. Overview 609 A system may take either an Active role or a Passive role in session 610 initialization. A system taking the Active role MUST send BFD 611 Control packets for a particular session, regardless of whether it 612 has received any BFD packets for that session. A system taking the 613 Passive role MUST NOT begin sending BFD packets for a particular 614 session until it has received a BFD packet for that session, and thus 615 has learned the remote system's discriminator value. At least one 616 system MUST take the Active role (possibly both.) The role that a 617 system takes is specific to the application of BFD, and is outside 618 the scope of this specification. 620 A session begins with the periodic, slow transmission of BFD Control 621 packets. When bidirectional communication is achieved (by virtue of 622 the I Hear You field being nonzero in both directions, a three way 623 handshake), the BFD 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 by sending a zero 644 value in the I Hear You 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 setting its outgoing 659 I Hear You field to zero), thus implementing a three-way handshake. 661 A session may be kept administratively down by always setting its 662 outgoing I Hear You field to zero, and sending an explanatory 663 diagnostic code in the Diagnostic field. 665 6.2. BFD State Machine 667 The BFD state machine is quite straightforward. There are four 668 states through which a session normally proceeds, two for 669 establishing a session (Init and Up) and two for tearing down a 670 session (Failing and Down.) This allows a three-way handshake for 671 both session establishment and session teardown (assuring that both 672 systems are aware of all session state changes.) A fifth state 673 (AdminDown) exists so that a session can be administratively put down 674 indefinitely. 676 Failing state indicates that the session has just failed (or has just 677 been created.) A session remains in Failing state until the remote 678 system indicates that it agrees that the session is down by sending a 679 BFD Control packet with I Hear You = 0. When this occurs, the 680 session advances to the Down state. 682 Down state means that the session is down and both systems know as 683 much. A session will remain in Down state only until the next BFD 684 Control packet is received from the remote system. If that packet 685 signals I Hear You = 0, the session advances to Init state; if that 686 packet signals I Hear You = 1, the session advances to Up state. 688 Init state means that the remote system is communicating, and the 689 local system desires to bring the session up, but the remote system 690 does not yet realize it. A session will remain in Init state until 691 either a BFD Control Packet is received that is signalling I Hear You 692 = 1 (in which case the session advances to Up state) or until the 693 detection time expires, meaning that communication with the remote 694 system has been lost (in which case the session advances to Failing 695 state.) 697 Up state means that the BFD session has successfully been 698 established, and implies that connectivity between the systems is 699 working. The session will remain in the Up state until either 700 connectivity fails, or the session is taken down administratively. 701 If either the remote system signals I Hear You = 0, or the detection 702 time expires, the session advances to Failing state. 704 6.3. Demultiplexing and the Discriminator Fields 706 Since multiple BFD sessions may be running between two systems, there 707 needs to be a mechanism for demultiplexing received BFD packets to 708 the proper session. 710 Each system MUST choose an opaque discriminator value that identifies 711 each session, and which MUST be unique among all BFD sessions on the 712 system. The local discriminator is sent in the My Discriminator 713 field in the BFD Control packet, and is echoed back in the Your 714 Discriminator field of packets sent from the remote end. 716 Once the remote end echoes back the local discriminator, all further 717 received packets are demultiplexed based on the Your Discriminator 718 field only (which means that, among other things, the source address 719 field can change or the interface over which the packets are received 720 can change, but the packets will still be associated with the proper 721 session.) 723 The method of demultiplexing the initial packets (in which Your 724 Discriminator is zero) is application-dependent, and is thus outside 725 the scope of this specification. 727 Note that it is permissible for a system to change its discriminator 728 during a session (without affecting the session state), since only 729 that system uses its discriminator for demultiplexing purposes (by 730 having the other system reflect it back.) The implications on an 731 implementation for changing the discriminator value is outside the 732 scope of this specification. 734 6.4. The Echo Function and Asymmetry 736 The Echo function can be run independently in each direction between 737 a pair of systems. For whatever reason, a system may advertise that 738 it is willing to receive (and loop back) Echo packets, but may not 739 wish to ever send any. The fact that a system is sending Echo 740 packets is not directly signalled to the system looping them back. 742 When a system is using the Echo function, it is advantageous to 743 choose a sedate transmission rate for Control packets, since liveness 744 detection is being handled by the Echo packets. This can be 745 controlled by manipulating the Desired Min TX Interval field (see 746 section 6.7.3.) 748 If the Echo function is only being run in one direction, the system 749 not running the Echo function will more likely wish to send fairly 750 rapid Control packets in order to achieve its desired detection time. 751 Since BFD allows independent transmission rates in each direction, 752 this is easily accomplished. 754 A system SHOULD always advertise the lowest value of Required Min RX 755 Interval and Required Min Echo RX Interval that it can under the 756 circumstances, to give the other system more freedom in choosing its 757 transmission rate. Note that a system is committing to be able to 758 receive both streams of packets at the rate it advertises, so this 759 should be taken into account when choosing the values to advertise. 761 6.5. Demand Mode 763 Demand mode is negotiated by virtue of both systems setting the 764 Demand (D) bit in its BFD Control packets. Both systems must request 765 Demand mode for it to become active. 767 Demand mode requires that some other mechanism is used to imply 768 continuing connectivity between the two systems. The mechanism used 769 does not have to be the same in both directions, and is outside of 770 the scope of this specification. One possible mechanism is the 771 receipt of traffic from the remote system; another is the use of the 772 Echo function. 774 Once a BFD session comes up, if Demand mode is active, both systems 775 stop sending periodic BFD Control packets, and depend on the 776 alternative mechanism for maintaining ongoing connectivity. 778 When a system wishes to verify connectivity, it initiates a Poll 779 Sequence. It starts periodically sending BFD Control packets with 780 the Poll (P) bit set, at the negotiated transmission rate. When a 781 system receives such a packet, it immediately replies with a BFD 782 Control packet of its own, with the Poll (P) bit clear, and the Final 783 (F) bit set. The receipt of a reply to a Poll terminates the Poll 784 Sequence. If no response is received to a Poll, the Poll is repeated 785 until the detection time expires, at which point the session is 786 declared to be down. 788 The detection time in Demand mode is calculated differently than in 789 Asynchronous mode; it is based on the transmit rate of the local 790 system, rather than the transmit rate of the remote system. This 791 ensures that the Poll Sequence mechanism works properly. See section 792 6.7.8 for more details. 794 Note that this mechanism requires that the detection time negotiated 795 is greater than the round trip time between the two systems, or the 796 Poll mechanism will always fail. Enforcement of this requirement is 797 outside the scope of this specification. 799 Demand mode MAY be enabled or disabled at any time by setting or 800 clearing the Demand (D) bit in the BFD Control packet, without 801 affecting the BFD session state. 803 Because the underlying detection mechanism is unspecified, and may 804 differ between the two systems, the overall detection time 805 characteristics of the path will not be fully known to either system. 806 The total detection time for a particular system is the sum of the 807 time prior to the initiation of the Poll Sequence, plus the 808 calculated detection time. 810 6.6. Authentication 812 An optional Authentication Section may be present in the BFD Control 813 packet. In its generic form, the purpose of the Authentication 814 Section is to carry all necessary information, based on the 815 authentication type in use, to allow the receiving system to 816 determine the validity of the received packet. The exact mechanism 817 depends on the authentication type in use, but in general the 818 transmitting system will put information in the Authentication 819 Section that vouches for the packet's validity, and the receiving 820 system will examine the Authentication Section and either accept the 821 packet for further processing, or discard it. 823 Note that in the subsections below, to "accept" a packet means only 824 that the packet has passed authentication; it may in fact be 825 discarded for other reasons as described in the general packet 826 reception rules described in section 6.7.6. 828 Implementations MUST support SHA1 authentication. Other froms of 829 authentication are optional. 831 6.6.1. Enabling and Disabling Authentication 833 It may be desirable to enable or disable authentication on a session 834 without disturbing the session state. The exact mechanism for doing 835 so is outside the scope of this specification. However, it is useful 836 to point out some issues in supporting this mechanism. 838 In a simple implementation, a BFD session will fail when 839 authentication is either turned on or turned off, because the packet 840 acceptance rules essentially require the local and remote machines to 841 do so in a more or less synchronized fashion (within the detect 842 time)--a packet with authentication will only be accepted if 843 authentication is "in use" (and likewise packets without 844 authentication. 846 One possible approach is to build an implementation such that 847 authentication is configured, but not considered "in use" until the 848 first packet containing a matching authentication section is received 849 (providing the necessary synchronization.) Likewise, authentication 850 could be configured off, but still considered "in use" until the 851 receipt of the first packet without the authentication section. 853 In order to avoid security risks, implementations using this method 854 should only allow the authentication state to be changed once without 855 some form of intervention (so that authentication cannot be turned on 856 and off repeatedly simply based on the receipt of BFD Control packets 857 from remote systems.) 859 6.6.2. Simple Password Authentication 861 The most straightforward (and weakest) form of authentication is 862 Simple Password Authentication. In this method of authentication, 863 one or more Passwords (with corresponding Key IDs) are configured in 864 each system and one of these Password/ID pairs is carried in each BFD 865 Control packet. The receiving system accepts the packet if the 866 Password and Key ID matches one of the Password/ID pairs configured 867 in that system. 869 Transmission Using Simple Password Authentication 871 The currently selected password and Key ID for the session MUST be 872 stored in the Authentication Section of each outgoing BFD Control 873 packet. The Auth Type field MUST be set to 1 (Simple Password.) 874 The Auth Len field MUST be set to the proper length (4 to 19 875 bytes.) 877 Reception Using Simple Password Authentication 879 If the received BFD Control packet does not contain an 880 Authentication Section, or the Auth Type is not 1 (Simple 881 Password), then the received packet MUST be discarded. 883 If the Auth Key ID field does not match the ID of a configured 884 password, the received packet MUST be discarded. 886 If the Auth Len field is not equal to the length of the password 887 selected by the Key ID, plus three, the packet MUST be discarded. 889 If the Password field does not match the password selected by the 890 Key ID, the packet MUST be discarded. 892 Otherwise, the packet MUST be accepted. 894 6.6.3. Keyed MD5 and Meticulous Keyed MD5 Authentication 896 The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are 897 very similar to those used in other protocols. In these methods of 898 authentication, one or more secret keys (with corresponding Key IDs) 899 are configured in each system. One of the Keys is included in an MD5 900 [MD5] checksum calculated over the outgoing BFD Control packet, but 901 the Key itself is not carried in the packet. To help avoid replay 902 attacks, a sequence number is also carried in each packet. For Keyed 903 MD5, the sequence number is occasionally incremented. For Meticulous 904 Keyed MD5, the sequence number is incremented on every packet. 906 The receiving system accepts the packet if the Key ID matches one of 907 the configured Keys, an MD5 checksum including the selected key 908 matches that carried in the packet, and if the sequence number is 909 greater than or equal to the last sequence number received (for Keyed 910 MD5), or strictly greater than the last sequence number received (for 911 Meticulous Keyed MD5.) 913 Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication 915 The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous 916 Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key 917 ID field MUST be set to the ID of the current authentication key. 919 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 921 The current authentication key value MUST be placed into the Auth 922 Key/Checksum field. An MD5 checksum MUST be calculated over the 923 entire BFD control packet. The resulting checksum MUST be stored 924 in the Auth Key/Checksum field prior to transmission (replacing 925 the secret key, which MUST NOT be carried in the packet.) 927 For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular 928 fashion (when treated as an unsigned 32 bit value.) 929 bfd.XmitAuthSeq SHOULD be incremented when the session state 930 changes, or when the transmitted BFD Control packet carries 931 different contents than the previously transmitted packet. The 932 decision as to when to increment bfd.XmitAuthSeq is outside the 933 scope of this specification. See the section entitled "Security 934 Considerations" below for a discussion. 936 For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a 937 circular fashion (when treated as an unsigned 32 bit value.) 939 Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication 941 If the received BFD Control packet does not contain an 942 Authentication Section, or the Auth Type is not correct (2 for 943 Keyed MD5, or 3 for Meticulous Keyed MD5), then the received 944 packet MUST be discarded. 946 If the Auth Key ID field does not match the ID of a configured 947 authentication key, the received packet MUST be discarded. 949 If the Auth Len field is not equal to 24, the packet MUST be 950 discarded. 952 Replace the contents of the Auth Key/Checksum field with the 953 authentication key selected by the received Auth Key ID field. If 954 the MD5 checksum of the entire BFD Control packet is not equal to 955 the received value of the Auth Key/Checksum field, the received 956 packet MUST be discarded. 958 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 959 Keyed MD5, if the Sequence Number lies outside of the range of 960 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 961 treated as an unsigned 32 bit circular number space), the received 962 packet MUST be discarded. For Meticulous Keyed MD5, if the 963 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 964 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 965 unsigned 32 bit circular number space, the received packet MUST be 966 discarded. 968 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 969 1, bfd.RcvAuthSeq MUST be set to the value of the received 970 Sequence Number field, and the received packet MUST be accepted. 972 6.6.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication 974 The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms 975 are very similar to those used in other protocols. In these methods 976 of authentication, one or more secret keys (with corresponding Key 977 IDs) are configured in each system. One of the Keys is included in a 978 SHA1 [SHA1] checksum calculated over the outgoing BFD Control packet, 979 but the Key itself is not carried in the packet. To help avoid 980 replay attacks, a sequence number is also carried in each packet. 981 For Keyed SHA1, the sequence number is occasionally incremented. For 982 Meticulous Keyed SHA1, the sequence number is incremented on every 983 packet. 985 The receiving system accepts the packet if the Key ID matches one of 986 the configured Keys, a SHA1 checksum including the selected key 987 matches that carried in the packet, and if the sequence number is 988 greater than or equal to the last sequence number received (for Keyed 989 SHA1), or strictly greater than the last sequence number received 990 (for Meticulous Keyed SHA1.) 992 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 993 Authentication 995 The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous 996 Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key 997 ID field MUST be set to the ID of the current authentication key. 998 The Sequence Number field MUST be set to bfd.XmitAuthSeq. 1000 The current authentication key value MUST be placed into the Auth 1001 Key/Checksum field. A SHA1 checksum MUST be calculated over the 1002 entire BFD control packet. The resulting checksum MUST be stored 1003 in the Auth Key/Checksum field prior to transmission (replacing 1004 the secret key, which MUST NOT be carried in the packet.) 1006 For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular 1007 fashion (when treated as an unsigned 32 bit value.) 1008 bfd.XmitAuthSeq SHOULD be incremented when the session state 1009 changes, or when the transmitted BFD Control packet carries 1010 different contents than the previously transmitted packet. The 1011 decision as to when to increment bfd.XmitAuthSeq is outside the 1012 scope of this specification. See the section entitled "Security 1013 Considerations" below for a discussion. 1015 For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in 1016 a circular fashion (when treated as an unsigned 32 bit value.) 1018 Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication 1020 If the received BFD Control packet does not contain an 1021 Authentication Section, or the Auth Type is not correct (4 for 1022 Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received 1023 packet MUST be discarded. 1025 If the Auth Key ID field does not match the ID of a configured 1026 authentication key, the received packet MUST be discarded. 1028 If the Auth Len field is not equal to 28, the packet MUST be 1029 discarded. 1031 Replace the contents of the Auth Key/Checksum field with the 1032 authentication key selected by the received Auth Key ID field. If 1033 the SHA1 checksum of the entire BFD Control packet is not equal to 1034 the received value of the Auth Key/Checksum field, the received 1035 packet MUST be discarded. 1037 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 1038 Keyed SHA1, if the Sequence Number lies outside of the range of 1039 bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when 1040 treated as an unsigned 32 bit circular number space), the received 1041 packet MUST be discarded. For Meticulous Keyed SHA1, if the 1042 Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to 1043 bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an 1044 unsigned 32 bit circular number space, the received packet MUST be 1045 discarded. 1047 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 1048 1, bfd.RcvAuthSeq MUST be set to the value of the received 1049 Sequence Number field, and the received packet MUST be accepted. 1051 6.7. Functional Specifics 1053 The following section of this specification is normative. The means 1054 by which this specification is achieved is outside the scope of this 1055 specification. 1057 When a system is said to have "the Echo function active," it means 1058 that the system is sending BFD Echo packets, implying that the 1059 session is Up and the other system has signalled its willingness to 1060 loop back Echo packets. 1062 When a system is said to have "Demand mode active," it means that 1063 bfd.DemandModeDesired is 1 in the local system (see State Variables 1064 below), the remote system is signalling with the Demand (D) bit set, 1065 and that the session is Up. 1067 6.7.1. State Variables 1069 A minimum amount of information about a session needs to be tracked 1070 in order to achieve the elements of procedure described here. The 1071 following is a set of state variables that are helpful in describing 1072 the mechanisms of BFD. Any means of tracking this state may be used 1073 so long as the protocol behaves as described. 1075 All state variables in this specification are of the form "bfd.Xx" 1076 and should not be confused with fields carried in the protocol 1077 packets, which are always spelled out to match the names in section 1078 4. 1080 bfd.SessionState 1082 The perceived state of the session (Init, Up, Failing, Down, or 1083 AdminDown.) The exact action taken when the session state 1084 changes is outside the scope of this specification, though it 1085 is expected that this state change (particularly to and from Up 1086 state) is reported to other components of the system. This 1087 variable MUST be initialized to Failing. 1089 bfd.LocalDiscr 1091 The local discriminator for this BFD session, used to uniquely 1092 identify it. It MUST be unique across all BFD sessions on this 1093 system, and nonzero. It SHOULD be set to a random (but still 1094 unique) value to improve security. The value is otherwise 1095 outside the scope of this specification. 1097 bfd.RemoteDiscr 1099 The remote discriminator for this BFD session. This is the 1100 discriminator chosen by the remote system, and is totally 1101 opaque to the local system. This MUST be initialized to zero. 1103 bfd.RemoteHeard 1105 This variable is set to 1 if the local system is actively 1106 receiving BFD packets from the remote system, and is set to 0 1107 if the local system has not received BFD packets recently 1108 (within the detection time) or if the local system is 1109 attempting to tear down the BFD session. This MUST be 1110 initialized to zero. 1112 bfd.LocalDiag 1114 The diagnostic code specifying the reason for the most recent 1115 local session state chage. This MUST be initialized to zero 1116 (No Diagnostic.) 1118 bfd.DesiredMinTxInterval 1120 The minimum interval, in microseconds, between transmitted BFD 1121 Control packets that this system would like to use at the 1122 current time. The actual interval is negotiated between the 1123 two systems. This MUST be initialized to a value of at least 1124 one second (1,000,000 microseconds) according to the rules 1125 described in section 6.7.3. The setting of this variable is 1126 otherwise outside the scope of this specification. 1128 bfd.RequiredMinRxInterval 1130 The minimum interval, in microseconds, between received BFD 1131 Control packets that this system requires. The setting of this 1132 variable is outside the scope of this specification. 1134 bfd.DemandModeDesired 1136 Set to 1 if the local system wishes to use Demand mode, or 0 if 1137 not. 1139 bfd.DetectMult 1141 The desired detect time multiplier for BFD Control packets. 1142 The negotiated Control packet transmission interval, multiplied 1143 by this variable, will be the detection time for this session 1144 (as seen by the remote system.) This variable MUST be a 1145 nonzero integer, and is otherwise outside the scope of this 1146 specification. See section 6.7.4 for further information. 1148 bfd.AuthType 1150 The authentication type in use for this session, as defined in 1151 section 4.1, or zero if no authentication is in use. 1153 bfd.RcvAuthSeq 1155 A 32 bit unsigned integer containing the next sequence number 1156 for keyed MD5 or SHA1 authentication expected to be received. 1157 The initial value is unimportant. 1159 bfd.XmitAuthSeq 1161 A 32 bit unsigned integer containing the next sequence number 1162 for keyed MD5 or SHA1 authentication to be transmitted. This 1163 variable MUST be initialized to a random 32 bit value. 1165 bfd.AuthSeqKnown 1167 Set to 1 if the next sequence number for keyed MD5 or SHA1 1168 authentication expected to be received is known, or 0 if it is 1169 not known. This variable MUST be initialized to zero. 1171 This variable MUST be set to zero after no packets have been 1172 received on this session for at least twice the Detection Time. 1173 This ensures that the sequence number can be resynchronized if 1174 the remote system restarts. 1176 6.7.2. Timer Negotiation 1178 The time values used to determine BFD packet transmission intervals 1179 and the session detection time are continuously negotiated, and thus 1180 may be changed at any time. The negotiation and time values are 1181 independent in each direction for each session. Packets are always 1182 periodically transmitted in Asynchronous mode, and are periodically 1183 transmitted during Poll Sequences when in Demand mode. 1185 Each system reports in the BFD Control packet how rapidly it would 1186 like to transmit BFD packets, as well as how rapidly it is prepared 1187 to receive them. With the exceptions listed in the remainder of this 1188 section, a system MUST NOT transmit BFD Control packets with an 1189 interval less than the larger of bfd.DesiredMinTxInterval and the 1190 received Required Min RX Interval field. In other words, the system 1191 reporting the slower rate determines the transmission rate. 1193 The periodic transmission of BFD Control packets SHOULD be jittered 1194 by up to 25%, that is, the interval SHOULD be reduced by a random 1195 value of 0 to 25%, in order to avoid self-synchronization. Thus, the 1196 average interval between packets may be up to 12.5% less than that 1197 negotiated. 1199 If bfd.DetectMult is equal to 1, the interval between transmitted BFD 1200 Control packets MUST be no more than 90% of the negotiated 1201 transmission interval, and MUST be no less than 75% of the negotiated 1202 transmission interval. This is to ensure that, on the remote system, 1203 the calculated DetectTime does not pass prior to the receipt of the 1204 next BFD Control packet. 1206 An extra, single BFD Control packet SHOULD be transmitted during the 1207 interval between periodic Control packet transmissions if there is a 1208 state change that needs to be communicated, in order to more rapidly 1209 converge. (For example, if the local system determines that the BFD 1210 session has gone down, it SHOULD communicate this without waiting for 1211 the next periodic transmission.) With the exception listed in the 1212 next paragraph, once such an extra packet has been transmitted, a 1213 system MUST NOT send another BFD Control packet until the next 1214 scheduled transmission. 1216 If a BFD Control packet is received with the Poll (P) bit set to 1, 1217 the receiving system MUST transmit a BFD Control packet with the Poll 1218 (P) bit clear and the Final (F) bit set as soon as practicable, 1219 without respect to the transmission timer or any other transmission 1220 limitations, and without respect to whether Demand mode is active. 1222 6.7.3. Timer Manipulation 1224 The time values used to determine BFD packet transmission intervals 1225 and the session detection time may be modified at any time without 1226 affecting the state of the session. When the timer parameters are 1227 changed for any reason, the requirements of this section apply. 1229 If Demand mode is active, and either bfd.DesiredMinTxInterval is 1230 changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST 1231 be initiated (see section 6.7.8). 1233 If Demand mode is not active, and either bfd.DesiredMinTxInterval is 1234 changed or bfd.RequiredMinRxInterval is changed, all subsequent 1235 transmitted Control packets MUST be sent with the Poll (P) bit set 1236 until a packet is received with the Final (F) bit set (except for 1237 those packets sent in response to received Polls.) 1239 If bfd.DesiredMinTxInterval is increased, the actual transmission 1240 interval used MUST NOT change until a Control packet is received with 1241 the Final (F) bit set. This is to ensure that the remote system 1242 updates its Detect Time before the transmission interval increases. 1244 If bfd.RequiredMinRxInterval is reduced, the calculated detection 1245 time for the remote system MUST NOT change until a Control packet is 1246 received with the Final (F) bit set. This is to ensure that the 1247 remote system is transmitting packets at the higher rate (and those 1248 packets are being received) prior to the detection time being 1249 reduced. 1251 When bfd.SessionState is not Up, the system MUST set 1252 bfd.DesiredMinTxInterval to a value of not less than one second 1253 (1,000,000 microseconds.) This is intended to ensure that the 1254 bandwidth consumed by BFD sessions that are not Up is negligible, 1255 particularly in the case where a neighbor may not be running BFD. 1257 When the Echo function is active, a system SHOULD set 1258 bfd.DesiredMinTxInterval to a value of not less than one second 1259 (1,000,000 microseconds.) This is intended to keep BFD Control 1260 traffic at a negligible level, since the actual detection function is 1261 being performed using BFD Echo packets. 1263 6.7.4. Calculating the Detection Time 1265 The Detection Time (the period of time without receiving BFD packets 1266 after which the session is determined to have failed) is not carried 1267 explicitly in the protocol. Rather, it is calculated independently 1268 in each direction by the receiving system based on the negotiated 1269 transmit interval and the detection multiplier. Note that, in 1270 Asynchronous mode, there may be different detection times in each 1271 direction. 1273 The calculation of the Detection Time is slightly different when in 1274 Demand mode versus Asynchronous mode. 1276 In Asynchronous mode, the Detection Time calculated in the local 1277 system is equal to the value of Detect Mult received from the remote 1278 system, multiplied by the agreed transmit interval (the greater of 1279 bfd.RequiredMinRxInterval and the last received Desired Min TX 1280 Interval.) The Detect Mult value is (roughly speaking, due to 1281 jitter) the number of packets that have to be missed in a row to 1282 declare the session to be down. 1284 If Demand mode is not active, and a period of time equal to the 1285 Detection Time passes without receiving a BFD Control packet from the 1286 remote system, and bfd.SessionState is Init or Up, the session has 1287 gone down--the local system MUST set bfd.SessionState to Failing, 1288 bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection 1289 Time Expired.) The timeout in Init state is to avoid a potential 1290 deadlock in which one system is in Failing state and the other is in 1291 Init state (which could happen if a packet were lost at the right 1292 time.) 1294 In Demand mode, the Detection Time calculated in the local system is 1295 equal to bfd.DetectMult, multiplied by the agreed transmit interval 1296 (the greater of bfd.RequiredMinRxInterval and the last received 1297 Desired Min TX Interval.) bfd.DetectMult is (roughly speaking, due 1298 to jitter) the number of packets that have to be missed in a row to 1299 declare the session to be down. 1301 If Demand mode is active, and a period of time equal to the Detection 1302 Time passes after the initiation of a Poll Sequence (the transmission 1303 of the first BFD Control packet with the Poll bit set), the session 1304 has gone down--the local system MUST set bfd.SessionState to Failing, 1305 bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection 1306 Time Expired.) 1308 (Note that a packet is considered to have been received, for the 1309 purposes of Detection Time expiration, only if it has not been 1310 "discarded" according to the rules of section 6.7.6.) 1312 6.7.5. Detecting Failures with the Echo Function 1314 When the Echo function is active and a sufficient number of Echo 1315 packets have not arrived as they should, the session has gone 1316 down--the local system MUST set bfd.SessionState to Failing, 1317 bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function 1318 Failed.) 1320 The means by which the Echo function failures are detected is outside 1321 of the scope of this specification. Any means which will detect a 1322 communication failure is acceptable. 1324 6.7.6. Reception of BFD Control Packets 1326 When a BFD Control packet is received, the following procedure MUST 1327 be followed, in the order specified. If the packet is discarded 1328 according to these rules, processing of the packet MUST cease at that 1329 point. 1331 If the version number is not correct (0), the packet MUST be 1332 discarded. 1334 If the Length field is less than the minimum correct value (24 if 1335 the A bit is clear, or 26 if the A bit is set), the packet MUST be 1336 discarded. 1338 If the Length field is greater than the payload of the 1339 encapsulating protocol, the packet MUST be discarded. 1341 If the Detect Mult field is zero, the packet MUST be discarded. 1343 If the My Discriminator field is zero, the packet MUST be 1344 discarded. 1346 If the Your Discriminator field is nonzero, it MUST be used to 1347 select the session with which this BFD packet is associated. If 1348 no session is found, the packet MUST be discarded. 1350 If the Your Discriminator field is zero and the I Hear You field 1351 is nonzero, the packet MUST be discarded. 1353 If the Your Discriminator field is zero, the session MUST be 1354 selected based on some combination of other fields, possibly 1355 including source addressing information, the My Discriminator 1356 field, and the interface over which the packet was received. The 1357 exact method of selection is application-specific and is thus 1358 outside the scope of this specification. If a matching session is 1359 not found, a new session may be created, or the packet may be 1360 discarded. This choice is outside the scope of this 1361 specification. 1363 If the A bit is set and no authentication is in use (bfd.AuthType 1364 is zero), the packet MUST be discarded. 1366 If the A bit is clear and authentication is in use (bfd.AuthType 1367 is nonzero), the packet MUST be discarded. 1369 If the A bit is set, the packet MUST be authenticated under the 1370 rules of section 6.6, based on the authentication type in use 1371 (bfd.AuthType.) This may cause the packet to be discarded. 1373 Set bfd.RemoteDiscr to the value of My Discriminator. 1375 If the Required Min Echo RX Interval field is zero, the 1376 transmission of Echo packets, if any, MUST cease. 1378 If Demand mode is active, a Poll Sequence is being transmitted by 1379 the local system, and the Final (F) bit in the received packet is 1380 set, the Poll Sequence MUST be terminated. 1382 If Demand mode is not active, the Final (F) bit in the received 1383 packet is set, and the local system has been transmitting packets 1384 with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in 1385 subsequent transmitted packets. 1387 Update the Detection Time as described in section 6.7.4. 1389 If bfd.SessionState is Down 1390 Set bfd.RemoteHeard to 1 1391 If I Hear You is zero 1392 Set bfd.SessionState to Init 1393 Else 1394 Set bfd.SessionState to Up 1396 Else if bfd.SessionState is AdminDown 1397 Discard the packet 1399 Else if bfd.SessionState is Init 1400 If I Hear You is nonzero 1401 Set bfd.SessionState to Up 1402 Else 1403 Discard the packet 1405 Else if bfd.SessionState is Up 1406 If I Hear You is zero 1407 Set bfd.LocalDiag to 3 (Neighbor signaled session down) 1408 Set bfd.SessionState to Failing 1409 Set bfd.RemoteHeard to 0 1411 Else if bfd.SessionState is Failing 1412 If I Hear You is zero, set bfd.SessionState to Down 1414 Update the transmit interval as described in section 6.7.2. 1416 If the Demand (D) bit is set and bfd.DemandModeDesired is 1, 1417 and bfd.SessionState is Up, Demand mode is active. 1419 If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, 1420 or bfd.SessionState is not Up, Demand mode is not 1421 active. 1423 If the Poll (P) bit is set, send a BFD Control packet to the 1424 remote system with the Poll (P) bit clear, and the Final (F) bit 1425 set. 1427 If the packet was not discarded, it has been received for purposes of 1428 the Detection Time expiration rules in section 6.7.4. 1430 6.7.7. Transmitting BFD Control Packets 1432 BFD Control packets MUST be transmitted periodically at the rate 1433 determined according to section 6.7.2, except as specified in this 1434 section. 1436 The transmit interval MUST be recalculated whenever 1437 bfd.DesiredMinTxInterval changes, or whenever the received Required 1438 Min RX Interval changes, and is equal to the greater of those two 1439 values. See sections 6.7.2 and 6.7.3 for details on transmit timers. 1441 A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is 1442 zero and the system is taking the Passive role. 1444 A system MUST NOT periodically transmit BFD Control packets if Demand 1445 mode is active and a Poll Sequence is not being transmitted. 1447 A system MUST send a BFD Control packet in response to a received BFD 1448 Control Packet with the Poll (P) bit set. The packet sent in 1449 response MUST NOT have the Poll (P) bit set, and MUST have the Final 1450 (F) bit set. A system MAY limit the rate at which such packets are 1451 transmitted. If rate limiting is in effect, the advertised value of 1452 Desired Min TX Interval must be greater than or equal to the interval 1453 between transmitted packets imposed by the rate limiting function. 1455 A single BFD Control packet SHOULD be transmitted between normally 1456 scheduled transmissions when the contents of that packet would differ 1457 from those in the previously transmitted packet (other than the Poll 1458 and Final bits) in order to more rapidly communicate a change in 1459 state. 1461 The contents of transmitted BFD Control packets MUST be set as 1462 follows: 1464 Version 1466 Set to the current version number (0). 1468 Diagnostic (Diag) 1470 Set to bfd.LocalDiag. 1472 I Hear You (H) 1474 Set to bfd.RemoteHeard. 1476 Demand (D) 1478 Set to bfd.DemandModeDesired. 1480 Poll (P) 1482 Set to 1 if the local system is sending a Poll Sequence or is 1483 required to do so according to the requirements of section 6.7.3, 1484 or 0 if not. 1486 Final (F) 1488 Set to 1 if the local system is responding to a Control packet 1489 received with the Poll (P) bit set, or 0 if not. 1491 Control Plane Independent (C) 1493 Set to 1 if the local system's BFD implementation is independent 1494 of the control plane (it can continue to function through a 1495 disruption of the control plane.) 1497 Authentication Present (A) 1499 Set to 1 if authentication is in use on this session (bfd.AuthType 1500 is nonzero), or 0 if not. 1502 Reserved (Rsvd) 1504 Set to 0. 1506 Detect Mult 1508 Set to bfd.DetectMult. 1510 Length 1512 Set to the appropriate length, based on the fixed header length 1513 (24) plus any Authentication Section. 1515 My Discriminator 1517 Set to bfd.LocalDiscr. 1519 Your Discriminator 1521 Set to bfd.RemoteDiscr. 1523 Desired Min TX Interval 1525 Set to bfd.DesiredMinTxInterval. 1527 Required Min RX Interval 1529 Set to bfd.RequiredMinRxInterval. 1531 Required Min Echo RX Interval 1533 Set to the minimum required Echo packet receive interval for this 1534 session. If this field is set to zero, the local system is 1535 unwilling or unable to loop back BFD Echo packets to the remote 1536 system, and the remote system will not send Echo packets. 1538 Authentication Section 1540 Included and set according to the rules in section 6.6 if 1541 authentication is in use (bfd.AuthType is nonzero.) Otherwise 1542 this section is not present. 1544 6.7.8. Initiation of a Poll Sequence 1546 If Demand mode is active, a Poll Sequence MUST be initiated whenever 1547 the contents of the next BFD Control packet to be sent would be 1548 different than the contents of the previous packet, with the 1549 exception of the Poll (P) and Final (F) bits. This ensures that 1550 parameter changes are transmitted to the remote system. Note that if 1551 the I Hear You (H) bit is changing to zero, the session is going down 1552 and Demand mode will no longer be active. 1554 If Demand mode is active, a Poll Sequence SHOULD be initiated 1555 whenever the system feels the need to verify connectivity with the 1556 remote system. The conditions under which this is desirable are 1557 outside the scope of this specification. 1559 If a Poll Sequence is being sent, and a new Poll Sequence is 1560 initiated due to one of the above conditions, the detection interval 1561 MUST be restarted in order to ensure that a full Poll Sequence is 1562 transmitted under the new conditions. 1564 6.7.9. Reception of BFD Echo Packets 1566 A received BFD Echo packet MUST be demultiplexed to the appropriate 1567 session for processing. A means of detecting missing Echo packets 1568 MUST be implemented, which most likely involves processing of the 1569 Echo packets that are received. The processing of received Echo 1570 packets is otherwise outside the scope of this specification. 1572 6.7.10. Transmission of BFD Echo Packets 1574 BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not 1575 Up. BFD Echo packets MUST NOT be transmitted unless the last BFD 1576 Control packet received from the remote system contains a nonzero 1577 value in Required Min Echo RX Interval. 1579 BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The 1580 interval between transmitted BFD Echo packets MUST NOT be less than 1581 the value advertised by the remote system in Required Min Echo RX 1582 Interval, except as follows: 1584 A 25% jitter MAY be applied to the rate of transmission, such that 1585 the actual interval MAY be between 75% and 100% of the advertised 1586 value. A single BFD Echo packet MAY be transmitted between 1587 normally scheduled Echo transmission intervals. 1589 The transmission of BFD Echo packets is otherwise outside the scope 1590 of this specification. 1592 6.7.11. Min Rx Interval Change 1594 When it is desired to change the rate at which BFD Control packets 1595 arrive from the remote system, bfd.RequiredMinRxInterval can be 1596 changed at any time to any value. The new value will be transmitted 1597 in the next outgoing Control packet, and the remote system will 1598 adjust accordingly. See sections 6.7.3 and 6.7.8 for further 1599 requirements. 1601 6.7.12. Min Tx Interval Change 1603 When it is desired to change the rate at which BFD Control packets 1604 are transmitted to the remote system (subject to the requirements of 1605 the neighboring system), bfd.DesiredMinTxInterval can be changed at 1606 any time to any value. The rules in sections 6.7.3 and 6.7.8 apply. 1608 6.7.13. Detect Multiplier Change 1610 When it is desired to change the detect multiplier, the value of 1611 bfd.DetectMult can be changed to any nonzero value. The new value 1612 will be transmitted with the next BFD Control packet. See section 1613 6.7.8 for additional requirements. 1615 6.7.14. Enabling or Disabling The Echo Function 1617 If it is desired to start or stop the transmission of BFD Echo 1618 packets, this MAY be done at any time (subject to the transmission 1619 requirements detailed in section 6.7.10.) 1621 If it is desired to enable or disable the looping back of received 1622 BFD Echo packets, this MAY be done at any time by changing the value 1623 of Required Min RX Interval to zero or nonzero in outgoing BFD 1624 Control packets. 1626 6.7.15. Enabling or Disabling Demand Mode 1628 If it is desired to start or stop Demand mode, this MAY be done at 1629 any time by setting bfd.DemandModeDesired to the proper value. If 1630 Demand mode is no longer active, the system MUST begin transmitting 1631 periodic BFD Control packets as described in section 6.7.7. 1633 6.7.16. Forwarding Plane Reset 1635 When the forwarding plane in the local system is reset for some 1636 reason, such that the remote system can no longer rely on the local 1637 forwarding state, the local system MUST set bfd.LocalDiag to 4 1638 (Forwarding Plane Reset), set bfd.SessionState to Failing, and set 1639 bfd.RemoteHeard to zero. 1641 6.7.17. Administrative Control 1643 There may be circumstances where it is desirable to administratively 1644 enable or disable a BFD session. When this is desired, the following 1645 procedure MUST be followed: 1647 If enabling session 1648 Set bfd.SessionState to Failing 1649 Set bfd.RemoteHeard to zero 1651 Else 1652 Set bfd.SessionState to AdminDown 1653 Set bfd.RemoteHeard to zero 1654 Set bfd.LocalDiag to an appropriate value 1655 Cease the transmission of BFD Echo packets 1657 If signalling is received from outside BFD that the underlying path 1658 has failed, an implementation MAY adminstratively disable the session 1659 with the diagnostic Path Down. 1661 Other scenarios MAY use the diagnostic Administratively Down. 1663 6.7.18. Concatenated Paths 1665 If the path being monitored by BFD is concatenated with other paths, 1666 it may be desirable to propagate the indication of a failure of one 1667 of those paths across the BFD session (providing an interworking 1668 function for liveness monitoring between BFD and other technologies.) 1670 Two diagnostic codes are defined for this purpose: Concatenated Path 1671 Down and Reverse Concatenated Path Down. The first propagates 1672 forward path failures (in which the concatenated path fails in the 1673 direction toward the interworking system), and the second propagates 1674 reverse path failures (in which the concatenated path fails in the 1675 direction away from the interworking system, assuming a bidirectional 1676 link.) 1678 A system MAY signal one of these failure states by simply setting 1679 bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD 1680 session is not taken down. If Demand Mode is not active, no other 1681 action is necessary, as the diagnostic code will be carried via the 1682 periodic transmission of BFD Control packets. If Demand Mode is 1683 active, a Poll Sequence MUST be initiated to ensure that the 1684 diagnostic code is transmitted. Note that if the BFD session 1685 subsequently fails, the diagnostic code will be overwritten with a 1686 code detailing the cause of the failure, so it is up to the 1687 interworking agent to perform this procedure again, once the BFD 1688 session reaches Up state, if the propagation of the concatenated path 1689 failure is to resume. 1691 Contributors 1693 Kireeti Kompella and Yakov Rekhter of Juniper Networks were also 1694 significant contributors to this document. 1696 Acknowledgments 1698 This document was inspired by (and is intended to replace) the 1699 Protocol Liveness Protocol draft, written by Kireeti Kompella. 1701 Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang 1702 et al. 1704 The authors would also like to thank Mike Shand, John Scudder, 1705 Stewart Bryant, and Pekka Savola for their substantive input. 1707 Security Considerations 1709 As BFD may be tied into the stability of the network infrastructure 1710 (such as routing protocols), the effects of an attack on a BFD 1711 session may be very serious. This ultimately has denial-of-service 1712 effects, as links may be declared to be down (or falsely declared to 1713 be up.) 1715 When BFD is run over network layer protocols, a significant denial- 1716 of-service risk is created, as BFD packets may be trivial to spoof. 1717 When the session is directly connected across a single link 1718 (physical, or a secure tunnel such as IPsec), the TTL or Hop Count 1719 MUST be set to the maximum on transmit, and checked to be equal to 1720 the maximum value on reception (and the packet dropped if this is not 1721 the case.) See [GTSM] for more information on this technique. If 1722 BFD is run across multiple hops or an insecure tunnel (such as GRE), 1723 the Authentication Section SHOULD be utilized. 1725 The level of security provided by the Authentication Section varies 1726 based on the authentication type used. Simple Password 1727 authentication is obviously only as secure as the secrecy of the 1728 passwords used, and should be considered only if the BFD session is 1729 guaranteed to be run over an infrastructure not subject to packet 1730 interception. Its chief advantage is that it minimizes the 1731 computational effort required for authentication. 1733 Keyed MD5 authentication is much stronger than Simple Password 1734 authentication since the keys cannot be discerned by intercepting 1735 packets. It is vulnerable to replay attacks in between increments of 1736 the sequence number. The sequence number can be incremented as 1737 seldom (or as often) as desired, trading off resistance to replay 1738 attacks with the computational effort required for authentication. 1740 Meticulous Keyed MD5 authentication is stronger yet, as it requires 1741 the sequence number to be incremented for every packet. Replay 1742 attack vulnerability is reduced due to the requirement that the 1743 sequence number must be incremented on every packet, the window size 1744 of acceptable packets is small, and the initial sequence number is 1745 randomized. There is still a window of attack at the beginning of 1746 the session while the sequence number is being determined. This 1747 authentication scheme requires an MD5 calculation on every packet 1748 transmitted and received. 1750 Using SHA1 rather than MD5 is believed to have stronger security 1751 properties. All comments about MD5 in this section also apply to 1752 SHA1. 1754 If both systems randomize their Local Discriminator values at the 1755 beginning of a session, replay attacks may be further mitigated, 1756 regardless of the authentication type in use. Since the Local 1757 Discriminator may be changed at any time during a session, this 1758 mechanism may also help mitigate attacks. 1760 Normative References 1762 [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism 1763 (GTSM)", RFC 3682, February 2004. 1765 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 1766 Requirement Levels", RFC 2119, March 1997. 1768 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1769 1992. 1771 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1773 [SHA1] "Secure Hash Standard", United States of America, National 1774 Institute of Science and Technology, Federal Information 1775 Processing Standard (FIPS) 180-1, April 1993. 1777 Authors' Addresses 1779 Dave Katz 1780 Juniper Networks 1781 1194 N. Mathilda Ave. 1782 Sunnyvale, California 94089-1206 USA 1783 Phone: +1-408-745-2000 1784 Email: dkatz@juniper.net 1786 Dave Ward 1787 Cisco Systems 1788 170 W. Tasman Dr. 1789 San Jose, CA 95134 USA 1790 Phone: +1-408-526-4000 1791 Email: dward@cisco.com 1793 Changes from the previous draft 1795 The primary technical change in this draft from the previous version 1796 is the addition of SHA1 authentication, the addition of a method for 1797 enabling and disabling authentication without disturbing BFD session 1798 state, and the modification of the procedures for handling 1799 concatenated paths. 1801 Otherwise, the changes in this draft from the previous version are 1802 cosmetic and/or editorial. 1804 IPR Notice 1806 The IETF has been notified of intellectual property rights claimed in 1807 regard to some or all of the specification contained in this 1808 document. For more information consult the online list of claimed 1809 rights. 1811 The IETF takes no position regarding the validity or scope of any 1812 intellectual property or other rights that might be claimed to 1813 pertain to the implementation or use of the technology described in 1814 this document or the extent to which any license under such rights 1815 might or might not be available; neither does it represent that it 1816 has made any effort to identify any such rights. Information on the 1817 IETF's procedures with respect to rights in standards-track and 1818 standards-related documentation can be found in BCP-11. Copies of 1819 claims of rights made available for publication and any assurances of 1820 licenses to be made available, or the result of an attempt made to 1821 obtain a general license or permission for the use of such 1822 proprietary rights by implementors or users of this specification can 1823 be obtained from the IETF Secretariat. 1825 The IETF invites any interested party to bring to its attention any 1826 copyrights, patents or patent applications, or other proprietary 1827 rights which may cover technology that may be required to practice 1828 this standard. Please address the information to the IETF Executive 1829 Director. 1831 Full Copyright Notice 1833 Copyright (C) The Internet Society (2005). This document is subject 1834 to the rights, licenses and restrictions contained in BCP 78, and 1835 except as set forth therein, the authors retain all their rights. 1837 This document and the information contained herein are provided on an 1838 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1839 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1840 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1841 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1842 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1843 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1845 Acknowledgement 1847 Funding for the RFC Editor function is currently provided by the 1848 Internet Society. 1850 This document expires in August, 2005.