--- 1/draft-ietf-bfd-base-00.txt 2006-02-04 22:51:06.000000000 +0100 +++ 2/draft-ietf-bfd-base-01.txt 2006-02-04 22:51:06.000000000 +0100 @@ -1,43 +1,46 @@ + Network Working Group D. Katz Internet Draft Juniper Networks D. Ward Cisco Systems -Expires: January, 2005 July, 2004 +Expires: August 2005 February, 2005 Bidirectional Forwarding Detection - draft-ietf-bfd-base-00.txt + draft-ietf-bfd-base-01.txt Status of this Memo - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt + http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + http://www.ietf.org/shadow.html Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. @@ -52,54 +55,60 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Addressing and Session Establishment . . . . . . . . . . . 5 3.2 Operating Modes . . . . . . . . . . . . . . . . . . . . . 5 4. BFD Control Packet Format . . . . . . . . . . . . . . . . . . 7 4.1 Generic BFD Control Packet Format . . . . . . . . . . . . 7 4.2 Simple Password Authentication Section Format . . . . . 11 4.3 Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format . . . . . . . . . . . . . . . . . . . . . 12 - 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 13 - 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 13 - 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 - 6.2 Demultiplexing and the Discriminator Fields . . . . . . 15 - 6.3 The Echo Function and Asymmetry . . . . . . . . . . . . 15 - 6.4 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 16 - 6.5 Authentication . . . . . . . . . . . . . . . . . . . . . 17 - 6.5.1 Simple Password Authentication . . . . . . . . . . 17 - 6.5.2 Keyed MD5 and Meticulous Keyed MD5 Authentication 18 - 6.6 Functional Specifics . . . . . . . . . . . . . . . . . . 20 - 6.6.1 State Variables . . . . . . . . . . . . . . . . . 20 - 6.6.2 Timer Negotiation . . . . . . . . . . . . . . . . 23 - 6.6.3 Timer Manipulation . . . . . . . . . . . . . . . . 24 - 6.6.4 Calculating the Detection Time . . . . . . . . . . 25 - 6.6.5 Detecting Failures with the Echo Function . . . . 26 - 6.6.6 Reception of BFD Control Packets . . . . . . . . . 26 - 6.6.7 Transmitting BFD Control Packets . . . . . . . . . 28 - 6.6.8 Initiation of a Poll Sequence . . . . . . . . . . 31 - 6.6.9 Reception of BFD Echo Packets . . . . . . . . . . 31 - 6.6.10 Transmission of BFD Echo Packets . . . . . . . . 31 - 6.6.11 Min Rx Interval Change . . . . . . . . . . . . . 32 - 6.6.12 Min Tx Interval Change . . . . . . . . . . . . . 32 - 6.6.13 Detect Multiplier Change . . . . . . . . . . . . 32 - 6.6.14 Enabling or Disabling the Echo Function . . . . . 32 - 6.6.15 Enabling or Disabling Demand Mode . . . . . . . . 33 - 6.6.16 Forwarding Plane Reset . . . . . . . . . . . . . 33 - 6.6.17 Administrative Control . . . . . . . . . . . . . 33 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 - Security Considerations . . . . . . . . . . . . . . . . . . . . 34 - Normative References . . . . . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35 - Changes from the previous draft . . . . . . . . . . . . . . . . 36 - IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 4.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication + Section Format . . . . . . . . . . . . . . . . . . . . . 13 + 5. BFD Echo Packet Format . . . . . . . . . . . . . . . . . . . 14 + 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 15 + 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 + 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 16 + 6.3 Demultiplexing and the Discriminator Fields . . . . . . 17 + 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 18 + 6.5 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 18 + 6.6 Authentication . . . . . . . . . . . . . . . . . . . . . 19 + 6.6.1 Enabling and Disabling Authentication . . . . . . 20 + 6.6.2 Simple Password Authentication . . . . . . . . . . 20 + 6.6.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 21 + 6.6.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 23 + 6.7 Functional Specifics . . . . . . . . . . . . . . . . . . 24 + 6.7.1 State Variables . . . . . . . . . . . . . . . . . 25 + 6.7.2 Timer Negotiation . . . . . . . . . . . . . . . . 27 + 6.7.3 Timer Manipulation . . . . . . . . . . . . . . . . 28 + 6.7.4 Calculating the Detection Time . . . . . . . . . . 29 + 6.7.5 Detecting Failures with the Echo Function . . . . 30 + 6.7.6 Reception of BFD Control Packets . . . . . . . . . 30 + 6.7.7 Transmitting BFD Control Packets . . . . . . . . . 33 + 6.7.8 Initiation of a Poll Sequence . . . . . . . . . . 35 + 6.7.9 Reception of BFD Echo Packets . . . . . . . . . . 36 + 6.7.10 Transmission of BFD Echo Packets . . . . . . . . 36 + 6.7.11 Min Rx Interval Change . . . . . . . . . . . . . 37 + 6.7.12 Min Tx Interval Change . . . . . . . . . . . . . 37 + 6.7.13 Detect Multiplier Change . . . . . . . . . . . . 37 + 6.7.14 Enabling or Disabling the Echo Function . . . . . 37 + 6.7.15 Enabling or Disabling Demand Mode . . . . . . . . 37 + 6.7.16 Forwarding Plane Reset . . . . . . . . . . . . . 38 + 6.7.17 Administrative Control . . . . . . . . . . . . . 38 + 6.7.18 Concatenated Paths . . . . . . . . . . . . . . . 38 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 + Security Considerations . . . . . . . . . . . . . . . . . . . . 39 + Normative References . . . . . . . . . . . . . . . . . . . . . 41 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 41 + Changes from the previous draft . . . . . . . . . . . . . . . . 41 + IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction An increasingly important feature of networking equipment is the rapid detection of communication failures between adjacent systems, in order to more quickly establish alternative paths. Currently, detection can come fairly quickly in certain circumstances when data link hardware comes into play (such as SONET alarms.) However, there are media that do not provide this kind of signaling (such as Ethernet), and some media may not detect certain kinds of failures in @@ -254,21 +263,21 @@ the Echo packets back signals that it will allow it, and when the system that sends the Echo packets decides it wishes to. Demand mode is useful in situations where the overhead of a periodic protocol might prove onerous, such as a system with a very large number of BFD sessions. It is also useful when the Echo function is being used symmetrically. Demand mode has the disadvantage that detection times are essentially driven by the heuristics of the system implementation and are not known to the BFD protocol. Demand mode also may not be used when the path round trip time is greater - than the desired detection time. See section 6.4 for more details. + than the desired detection time. See section 6.5 for more details. 4. BFD Control Packet Format 4.1. Generic BFD Control Packet Format BFD Control packets are sent in an encapsulation appropriate to the environment, which is outside of the scope of this document. See the appropriate application document for encapsulation details. The BFD Control packet has a Mandatory Section and an optional @@ -303,32 +312,32 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (Vers) The version number of the protocol. This document defines protocol version 0. Diagnostic (Diag) A diagnostic code specifying the local system's reason for the - last transition of the session from Up to some other state. - Values are: + last session state change. Values are: 0 -- No Diagnostic 1 -- Control Detection Time Expired 2 -- Echo Function Failed 3 -- Neighbor Signaled Session Down 4 -- Forwarding Plane Reset 5 -- Path Down 6 -- Concatenated Path Down 7 -- Administratively Down - 8-31 -- Reserved for future use + 8 -- Reverse Concatenated Path Down + 9-31 -- Reserved for future use This field allows remote systems to determine the reason that the previous session failed, for example. I Hear You (H) This bit is set to 0 if the transmitting system either is not receiving BFD packets from the remote system, or is in the process of tearing down the BFD session for some reason. This bit is set to 1 if the transmitting system believes it is communicating with @@ -416,21 +425,23 @@ Auth Type The authentication type in use, if the Authentication Present (A) bit is set. 0 - Reserved 1 - Simple Password 2 - Keyed MD5 3 - Meticulous Keyed MD5 - 4-255 - Reserved for future use + 4 - Keyed SHA1 + 5 - Meticulous Keyed SHA1 + 6-255 - Reserved for future use Auth Len The length, in bytes, of the authentication section, including the Auth Type and Auth Len fields. 4.2. Simple Password Authentication Section Format If the Autentication Present (A) bit is set in the header, and the Authentication Type field contains 1 (Simple Password), the @@ -507,21 +518,72 @@ The Sequence Number for this packet. For Keyed MD5 Authentication, this value is incremented periodically. For Meticulous Keyed MD5 Authentication, this value is incremented for each successive packet transmitted for a session. This provides protection against replay attacks. Auth Key/Checksum This field carries the 16 byte MD5 checksum for the packet. When the checksum is calculated, the shared MD5 key is stored in this - field. (See section 6.5.2 for details.) + field. (See section 6.6.3 for details.) + +4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format + + If the Authentication Present (A) bit is set in the header, and the + Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous + Keyed SHA1), the Authentication Section has the following format: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Auth Type | Auth Len | Auth Key ID | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Auth Key/Checksum... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Auth Type + + The Authentication Type, which in this case is 4 (Keyed SHA1) or 5 + (Meticulous Keyed SHA1). + + Auth Len + + The length of the Authentication Section, in bytes. For Keyed + SHA1 and Meticulous Keyed SHA1 authentication, the length is 28. + + Auth Key ID + + The authentication key ID in use for this packet. This allows + multiple keys to be active simultaneously. + + Reserved + + This byte must be set to zero on transmit, and ignored on receipt. + + Sequence Number + + The Sequence Number for this packet. For Keyed SHA1 + Authentication, this value is incremented periodically. For + Meticulous Keyed SHA1 Authentication, this value is incremented + for each successive packet transmitted for a session. This + provides protection against replay attacks. + + Auth Key/Checksum + + This field carries the 20 byte SHA1 checksum for the packet. When + the checksum is calculated, the shared SHA1 key is stored in this + field. (See section 6.6.4 for details.) 5. BFD Echo Packet Format BFD Echo packets are sent in an encapsulation appropriate to the environment. See the appropriate application document for the specifics of particular environments. The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received @@ -531,21 +593,21 @@ 6. Elements of Procedure This section discusses the normative requirements of the protocol in order to achieve interoperability. It is important for implementors to enforce only the requirements specified in this section, as misguided pedantry has been proven by experience to adversely affect interoperability. Remember that all references of the form "bfd.Xx" refer to internal - state variables (defined in section 6.6.1), whereas all references to + state variables (defined in section 6.7.1), whereas all references to "the Xxx field" refer to fields in the protocol packets themselves (defined in section 4). 6.1. Overview A system may take either an Active role or a Passive role in session initialization. A system taking the Active role MUST send BFD Control packets for a particular session, regardless of whether it has received any BFD packets for that session. A system taking the Passive role MUST NOT begin sending BFD packets for a particular @@ -570,21 +632,21 @@ detection time requirements for the session. If both systems signal that they want to use Demand mode, the transmission of BFD Control packets ceases once the session is Up. Other means of implying connectivity are used to keep the session alive. If one of the systems wishes to verify connectivity, it can initiate a short exchange (a "Poll Sequence") of BFD Control packets to verify this. If Demand mode is not active, and no Control packets are received in - the calculated detection time (see section 6.6.4), the session is + the calculated detection time (see section 6.7.4), the session is declared down, and signalled to the remote end by sending a zero value in the I Hear You field in outgoing packets. If sufficient Echo packets are lost, the session is declared down in the same manner. If Demand mode is active and no appropriate Control packets are received in response to a Poll Sequence, the session is declared down in the same manner. @@ -593,21 +655,60 @@ rate. Once a session has been declared down, it cannot come back up until the remote end first signals that it is down (by setting its outgoing I Hear You field to zero), thus implementing a three-way handshake. A session may be kept administratively down by always setting its outgoing I Hear You field to zero, and sending an explanatory diagnostic code in the Diagnostic field. -6.2. Demultiplexing and the Discriminator Fields +6.2. BFD State Machine + + The BFD state machine is quite straightforward. There are four + states through which a session normally proceeds, two for + establishing a session (Init and Up) and two for tearing down a + session (Failing and Down.) This allows a three-way handshake for + both session establishment and session teardown (assuring that both + systems are aware of all session state changes.) A fifth state + (AdminDown) exists so that a session can be administratively put down + indefinitely. + + Failing state indicates that the session has just failed (or has just + been created.) A session remains in Failing state until the remote + system indicates that it agrees that the session is down by sending a + BFD Control packet with I Hear You = 0. When this occurs, the + session advances to the Down state. + + Down state means that the session is down and both systems know as + much. A session will remain in Down state only until the next BFD + Control packet is received from the remote system. If that packet + signals I Hear You = 0, the session advances to Init state; if that + packet signals I Hear You = 1, the session advances to Up state. + + Init state means that the remote system is communicating, and the + local system desires to bring the session up, but the remote system + does not yet realize it. A session will remain in Init state until + either a BFD Control Packet is received that is signalling I Hear You + = 1 (in which case the session advances to Up state) or until the + detection time expires, meaning that communication with the remote + system has been lost (in which case the session advances to Failing + state.) + + Up state means that the BFD session has successfully been + established, and implies that connectivity between the systems is + working. The session will remain in the Up state until either + connectivity fails, or the session is taken down administratively. + If either the remote system signals I Hear You = 0, or the detection + time expires, the session advances to Failing state. + +6.3. Demultiplexing and the Discriminator Fields Since multiple BFD sessions may be running between two systems, there needs to be a mechanism for demultiplexing received BFD packets to the proper session. Each system MUST choose an opaque discriminator value that identifies each session, and which MUST be unique among all BFD sessions on the system. The local discriminator is sent in the My Discriminator field in the BFD Control packet, and is echoed back in the Your Discriminator field of packets sent from the remote end. @@ -623,47 +724,48 @@ Discriminator is zero) is application-dependent, and is thus outside the scope of this specification. Note that it is permissible for a system to change its discriminator during a session (without affecting the session state), since only that system uses its discriminator for demultiplexing purposes (by having the other system reflect it back.) The implications on an implementation for changing the discriminator value is outside the scope of this specification. -6.3. The Echo Function and Asymmetry +6.4. The Echo Function and Asymmetry The Echo function can be run independently in each direction between a pair of systems. For whatever reason, a system may advertise that it is willing to receive (and loop back) Echo packets, but may not wish to ever send any. The fact that a system is sending Echo packets is not directly signalled to the system looping them back. When a system is using the Echo function, it is advantageous to choose a sedate transmission rate for Control packets, since liveness detection is being handled by the Echo packets. This can be controlled by manipulating the Desired Min TX Interval field (see - section 6.6.3.) + section 6.7.3.) + If the Echo function is only being run in one direction, the system not running the Echo function will more likely wish to send fairly rapid Control packets in order to achieve its desired detection time. Since BFD allows independent transmission rates in each direction, this is easily accomplished. A system SHOULD always advertise the lowest value of Required Min RX Interval and Required Min Echo RX Interval that it can under the circumstances, to give the other system more freedom in choosing its transmission rate. Note that a system is committing to be able to receive both streams of packets at the rate it advertises, so this should be taken into account when choosing the values to advertise. -6.4. Demand Mode +6.5. Demand Mode Demand mode is negotiated by virtue of both systems setting the Demand (D) bit in its BFD Control packets. Both systems must request Demand mode for it to become active. Demand mode requires that some other mechanism is used to imply continuing connectivity between the two systems. The mechanism used does not have to be the same in both directions, and is outside of the scope of this specification. One possible mechanism is the receipt of traffic from the remote system; another is the use of the @@ -680,57 +782,88 @@ Control packet of its own, with the Poll (P) bit clear, and the Final (F) bit set. The receipt of a reply to a Poll terminates the Poll Sequence. If no response is received to a Poll, the Poll is repeated until the detection time expires, at which point the session is declared to be down. The detection time in Demand mode is calculated differently than in Asynchronous mode; it is based on the transmit rate of the local system, rather than the transmit rate of the remote system. This ensures that the Poll Sequence mechanism works properly. See section - 6.6.8 for more details. + 6.7.8 for more details. Note that this mechanism requires that the detection time negotiated is greater than the round trip time between the two systems, or the Poll mechanism will always fail. Enforcement of this requirement is outside the scope of this specification. Demand mode MAY be enabled or disabled at any time by setting or clearing the Demand (D) bit in the BFD Control packet, without affecting the BFD session state. Because the underlying detection mechanism is unspecified, and may differ between the two systems, the overall detection time characteristics of the path will not be fully known to either system. The total detection time for a particular system is the sum of the time prior to the initiation of the Poll Sequence, plus the calculated detection time. -6.5. Authentication +6.6. Authentication An optional Authentication Section may be present in the BFD Control packet. In its generic form, the purpose of the Authentication Section is to carry all necessary information, based on the authentication type in use, to allow the receiving system to determine the validity of the received packet. The exact mechanism depends on the authentication type in use, but in general the transmitting system will put information in the Authentication Section that vouches for the packet's validity, and the receiving system will examine the Authentication Section and either accept the packet for further processing, or discard it. Note that in the subsections below, to "accept" a packet means only that the packet has passed authentication; it may in fact be discarded for other reasons as described in the general packet - reception rules described in section 6.6.6. + reception rules described in section 6.7.6. -6.5.1. Simple Password Authentication + Implementations MUST support SHA1 authentication. Other froms of + authentication are optional. + +6.6.1. Enabling and Disabling Authentication + + It may be desirable to enable or disable authentication on a session + without disturbing the session state. The exact mechanism for doing + so is outside the scope of this specification. However, it is useful + to point out some issues in supporting this mechanism. + + In a simple implementation, a BFD session will fail when + authentication is either turned on or turned off, because the packet + acceptance rules essentially require the local and remote machines to + do so in a more or less synchronized fashion (within the detect + time)--a packet with authentication will only be accepted if + authentication is "in use" (and likewise packets without + authentication. + + One possible approach is to build an implementation such that + authentication is configured, but not considered "in use" until the + first packet containing a matching authentication section is received + (providing the necessary synchronization.) Likewise, authentication + could be configured off, but still considered "in use" until the + receipt of the first packet without the authentication section. + + In order to avoid security risks, implementations using this method + should only allow the authentication state to be changed once without + some form of intervention (so that authentication cannot be turned on + and off repeatedly simply based on the receipt of BFD Control packets + from remote systems.) + +6.6.2. Simple Password Authentication The most straightforward (and weakest) form of authentication is Simple Password Authentication. In this method of authentication, one or more Passwords (with corresponding Key IDs) are configured in each system and one of these Password/ID pairs is carried in each BFD Control packet. The receiving system accepts the packet if the Password and Key ID matches one of the Password/ID pairs configured in that system. Transmission Using Simple Password Authentication @@ -751,61 +884,63 @@ password, the received packet MUST be discarded. If the Auth Len field is not equal to the length of the password selected by the Key ID, plus three, the packet MUST be discarded. If the Password field does not match the password selected by the Key ID, the packet MUST be discarded. Otherwise, the packet MUST be accepted. -6.5.2. Keyed MD5 and Meticulous Keyed MD5 Authentication +6.6.3. Keyed MD5 and Meticulous Keyed MD5 Authentication The Keyed MD5 and Meticulous Keyed MD5 Authentication mechanisms are very similar to those used in other protocols. In these methods of authentication, one or more secret keys (with corresponding Key IDs) are configured in each system. One of the Keys is included in an MD5 - checksum calculated over the outgoing BFD Control packet, but the Key - itself is not carried in the packet. To help avoid replay attacks, a - sequence number is also carried in each packet. For Keyed MD5, the - sequence number is occasionally incremented. For Meticulous Keyed - MD5, the sequence number is incremented on every packet. + [MD5] checksum calculated over the outgoing BFD Control packet, but + the Key itself is not carried in the packet. To help avoid replay + attacks, a sequence number is also carried in each packet. For Keyed + MD5, the sequence number is occasionally incremented. For Meticulous + Keyed MD5, the sequence number is incremented on every packet. The receiving system accepts the packet if the Key ID matches one of the configured Keys, an MD5 checksum including the selected key matches that carried in the packet, and if the sequence number is greater than or equal to the last sequence number received (for Keyed MD5), or strictly greater than the last sequence number received (for Meticulous Keyed MD5.) + Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key ID field MUST be set to the ID of the current authentication key. - The Sequence Number field MUST be set to bfd.XmitMD5Seq. + + The Sequence Number field MUST be set to bfd.XmitAuthSeq. The current authentication key value MUST be placed into the Auth Key/Checksum field. An MD5 checksum MUST be calculated over the entire BFD control packet. The resulting checksum MUST be stored in the Auth Key/Checksum field prior to transmission (replacing the secret key, which MUST NOT be carried in the packet.) - For Keyed MD5, bfd.XmitMD5Seq MAY be incremented in a circular + For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular fashion (when treated as an unsigned 32 bit value.) - bfd.XmitMD5Seq SHOULD be incremented when the session state + bfd.XmitAuthSeq SHOULD be incremented when the session state changes, or when the transmitted BFD Control packet carries different contents than the previously transmitted packet. The - decision as to when to increment bfd.XmitMD5Seq is outside the + decision as to when to increment bfd.XmitAuthSeq is outside the scope of this specification. See the section entitled "Security Considerations" below for a discussion. - For Meticulous Keyed MD5, bfd.XmitMD5Seq MUST be incremented in a + For Meticulous Keyed MD5, bfd.XmitAuthSeq MUST be incremented in a circular fashion (when treated as an unsigned 32 bit value.) Receipt Using Keyed MD5 and Meticulous Keyed MD5 Authentication If the received BFD Control packet does not contain an Authentication Section, or the Auth Type is not correct (2 for Keyed MD5, or 3 for Meticulous Keyed MD5), then the received packet MUST be discarded. If the Auth Key ID field does not match the ID of a configured @@ -813,51 +948,130 @@ If the Auth Len field is not equal to 24, the packet MUST be discarded. Replace the contents of the Auth Key/Checksum field with the authentication key selected by the received Auth Key ID field. If the MD5 checksum of the entire BFD Control packet is not equal to the received value of the Auth Key/Checksum field, the received packet MUST be discarded. - If bfd.MD5SeqKnown is 1, examine the Sequence Number field. For + If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For Keyed MD5, if the Sequence Number lies outside of the range of - bfd.RcvMD5Seq to bfd.RcvMD5Seq+(3*Detect Mult) inclusive (when + bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32 bit circular number space), the received packet MUST be discarded. For Meticulous Keyed MD5, if the - Sequence Number lies outside of the range of bfd.RcvMD5Seq+1 to - bfd.RcvMD5Seq+(3*Detect Mult) inclusive (when treated as an + Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to + bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32 bit circular number space, the received packet MUST be discarded. - Otherwise (bfd.MD5SeqKnown is 0), bfd.MD5SeqKnown MUST be set to - 1, bfd.RcvMD5Seq MUST be set to the value of the received Sequence - Number field, and the received packet MUST be accepted. + Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to + 1, bfd.RcvAuthSeq MUST be set to the value of the received + Sequence Number field, and the received packet MUST be accepted. -6.6. Functional Specifics +6.6.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication + + The Keyed SHA1 and Meticulous Keyed SHA1 Authentication mechanisms + are very similar to those used in other protocols. In these methods + of authentication, one or more secret keys (with corresponding Key + IDs) are configured in each system. One of the Keys is included in a + SHA1 [SHA1] checksum calculated over the outgoing BFD Control packet, + but the Key itself is not carried in the packet. To help avoid + replay attacks, a sequence number is also carried in each packet. + For Keyed SHA1, the sequence number is occasionally incremented. For + Meticulous Keyed SHA1, the sequence number is incremented on every + packet. + + The receiving system accepts the packet if the Key ID matches one of + the configured Keys, a SHA1 checksum including the selected key + matches that carried in the packet, and if the sequence number is + greater than or equal to the last sequence number received (for Keyed + SHA1), or strictly greater than the last sequence number received + (for Meticulous Keyed SHA1.) + + Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 + Authentication + + The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous + Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key + ID field MUST be set to the ID of the current authentication key. + The Sequence Number field MUST be set to bfd.XmitAuthSeq. + + The current authentication key value MUST be placed into the Auth + Key/Checksum field. A SHA1 checksum MUST be calculated over the + entire BFD control packet. The resulting checksum MUST be stored + in the Auth Key/Checksum field prior to transmission (replacing + the secret key, which MUST NOT be carried in the packet.) + + For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular + fashion (when treated as an unsigned 32 bit value.) + bfd.XmitAuthSeq SHOULD be incremented when the session state + changes, or when the transmitted BFD Control packet carries + different contents than the previously transmitted packet. The + decision as to when to increment bfd.XmitAuthSeq is outside the + scope of this specification. See the section entitled "Security + Considerations" below for a discussion. + + For Meticulous Keyed SHA1, bfd.XmitAuthSeq MUST be incremented in + a circular fashion (when treated as an unsigned 32 bit value.) + + Receipt Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication + + If the received BFD Control packet does not contain an + Authentication Section, or the Auth Type is not correct (4 for + Keyed SHA1, or 5 for Meticulous Keyed SHA1), then the received + packet MUST be discarded. + + If the Auth Key ID field does not match the ID of a configured + authentication key, the received packet MUST be discarded. + + If the Auth Len field is not equal to 28, the packet MUST be + discarded. + + Replace the contents of the Auth Key/Checksum field with the + authentication key selected by the received Auth Key ID field. If + the SHA1 checksum of the entire BFD Control packet is not equal to + the received value of the Auth Key/Checksum field, the received + packet MUST be discarded. + + If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For + Keyed SHA1, if the Sequence Number lies outside of the range of + bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when + treated as an unsigned 32 bit circular number space), the received + packet MUST be discarded. For Meticulous Keyed SHA1, if the + Sequence Number lies outside of the range of bfd.RcvAuthSeq+1 to + bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an + unsigned 32 bit circular number space, the received packet MUST be + discarded. + + Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to + 1, bfd.RcvAuthSeq MUST be set to the value of the received + Sequence Number field, and the received packet MUST be accepted. + +6.7. Functional Specifics The following section of this specification is normative. The means by which this specification is achieved is outside the scope of this specification. When a system is said to have "the Echo function active," it means that the system is sending BFD Echo packets, implying that the session is Up and the other system has signalled its willingness to loop back Echo packets. When a system is said to have "Demand mode active," it means that bfd.DemandModeDesired is 1 in the local system (see State Variables below), the remote system is signalling with the Demand (D) bit set, and that the session is Up. -6.6.1. State Variables +6.7.1. State Variables A minimum amount of information about a session needs to be tracked in order to achieve the elements of procedure described here. The following is a set of state variables that are helpful in describing the mechanisms of BFD. Any means of tracking this state may be used so long as the protocol behaves as described. All state variables in this specification are of the form "bfd.Xx" and should not be confused with fields carried in the protocol packets, which are always spelled out to match the names in section @@ -868,105 +1082,105 @@ The perceived state of the session (Init, Up, Failing, Down, or AdminDown.) The exact action taken when the session state changes is outside the scope of this specification, though it is expected that this state change (particularly to and from Up state) is reported to other components of the system. This variable MUST be initialized to Failing. bfd.LocalDiscr The local discriminator for this BFD session, used to uniquely - identify it. It MUST be unique on this system, and nonzero. - It MAY be set to a random (but still unique) value to improve - security. The value is otherwise outside the scope of this - specification. + identify it. It MUST be unique across all BFD sessions on this + system, and nonzero. It SHOULD be set to a random (but still + unique) value to improve security. The value is otherwise + outside the scope of this specification. bfd.RemoteDiscr The remote discriminator for this BFD session. This is the discriminator chosen by the remote system, and is totally opaque to the local system. This MUST be initialized to zero. bfd.RemoteHeard This variable is set to 1 if the local system is actively receiving BFD packets from the remote system, and is set to 0 if the local system has not received BFD packets recently (within the detection time) or if the local system is attempting to tear down the BFD session. This MUST be initialized to zero. bfd.LocalDiag - The diagnostic code specifying the reason the local session - state most recently transitioned from Up to some other state. - This MUST be initialized to zero (No Diagnostic.) + The diagnostic code specifying the reason for the most recent + local session state chage. This MUST be initialized to zero + (No Diagnostic.) bfd.DesiredMinTxInterval The minimum interval, in microseconds, between transmitted BFD Control packets that this system would like to use at the current time. The actual interval is negotiated between the two systems. This MUST be initialized to a value of at least one second (1,000,000 microseconds) according to the rules - described in section 6.6.3. The setting of this variable is + described in section 6.7.3. The setting of this variable is otherwise outside the scope of this specification. bfd.RequiredMinRxInterval The minimum interval, in microseconds, between received BFD Control packets that this system requires. The setting of this variable is outside the scope of this specification. bfd.DemandModeDesired Set to 1 if the local system wishes to use Demand mode, or 0 if not. bfd.DetectMult The desired detect time multiplier for BFD Control packets. The negotiated Control packet transmission interval, multiplied by this variable, will be the detection time for this session (as seen by the remote system.) This variable MUST be a nonzero integer, and is otherwise outside the scope of this - specification. See section 6.6.4 for further information. + specification. See section 6.7.4 for further information. bfd.AuthType The authentication type in use for this session, as defined in section 4.1, or zero if no authentication is in use. - bfd.RcvMD5Seq + bfd.RcvAuthSeq A 32 bit unsigned integer containing the next sequence number - for keyed MD5 authentication expected to be received. The - initial value is unimportant. + for keyed MD5 or SHA1 authentication expected to be received. + The initial value is unimportant. - bfd.XmitMD5Seq + bfd.XmitAuthSeq A 32 bit unsigned integer containing the next sequence number - for keyed MD5 authentication to be transmitted. This variable - MUST be initialized to a random 32 bit value. + for keyed MD5 or SHA1 authentication to be transmitted. This + variable MUST be initialized to a random 32 bit value. - bfd.MD5SeqKnown + bfd.AuthSeqKnown - Set to 1 if the next sequence number for keyed MD5 + Set to 1 if the next sequence number for keyed MD5 or SHA1 authentication expected to be received is known, or 0 if it is not known. This variable MUST be initialized to zero. This variable MUST be set to zero after no packets have been received on this session for at least twice the Detection Time. - This ensures that the MD5 sequence number can be resynchronized - if the remote system restarts. + This ensures that the sequence number can be resynchronized if + the remote system restarts. -6.6.2. Timer Negotiation +6.7.2. Timer Negotiation The time values used to determine BFD packet transmission intervals and the session detection time are continuously negotiated, and thus may be changed at any time. The negotiation and time values are independent in each direction for each session. Packets are always periodically transmitted in Asynchronous mode, and are periodically transmitted during Poll Sequences when in Demand mode. Each system reports in the BFD Control packet how rapidly it would like to transmit BFD packets, as well as how rapidly it is prepared @@ -998,35 +1212,36 @@ next paragraph, once such an extra packet has been transmitted, a system MUST NOT send another BFD Control packet until the next scheduled transmission. If a BFD Control packet is received with the Poll (P) bit set to 1, the receiving system MUST transmit a BFD Control packet with the Poll (P) bit clear and the Final (F) bit set as soon as practicable, without respect to the transmission timer or any other transmission limitations, and without respect to whether Demand mode is active. -6.6.3. Timer Manipulation +6.7.3. Timer Manipulation The time values used to determine BFD packet transmission intervals and the session detection time may be modified at any time without affecting the state of the session. When the timer parameters are changed for any reason, the requirements of this section apply. If Demand mode is active, and either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST - be initiated (see section 6.6.8). + be initiated (see section 6.7.8). If Demand mode is not active, and either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, all subsequent transmitted Control packets MUST be sent with the Poll (P) bit set - until a packet is received with the Final (F) bit set. + until a packet is received with the Final (F) bit set (except for + those packets sent in response to received Polls.) If bfd.DesiredMinTxInterval is increased, the actual transmission interval used MUST NOT change until a Control packet is received with the Final (F) bit set. This is to ensure that the remote system updates its Detect Time before the transmission interval increases. If bfd.RequiredMinRxInterval is reduced, the calculated detection time for the remote system MUST NOT change until a Control packet is received with the Final (F) bit set. This is to ensure that the remote system is transmitting packets at the higher rate (and those @@ -1038,21 +1253,21 @@ (1,000,000 microseconds.) This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD. When the Echo function is active, a system SHOULD set bfd.DesiredMinTxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to keep BFD Control traffic at a negligible level, since the actual detection function is being performed using BFD Echo packets. -6.6.4. Calculating the Detection Time +6.7.4. Calculating the Detection Time The Detection Time (the period of time without receiving BFD packets after which the session is determined to have failed) is not carried explicitly in the protocol. Rather, it is calculated independently in each direction by the receiving system based on the negotiated transmit interval and the detection multiplier. Note that, in Asynchronous mode, there may be different detection times in each direction. The calculation of the Detection Time is slightly different when in @@ -1085,35 +1300,35 @@ If Demand mode is active, and a period of time equal to the Detection Time passes after the initiation of a Poll Sequence (the transmission of the first BFD Control packet with the Poll bit set), the session has gone down--the local system MUST set bfd.SessionState to Failing, bfd.RemoteHeard to zero, and bfd.LocalDiag to 1 (Control Detection Time Expired.) (Note that a packet is considered to have been received, for the purposes of Detection Time expiration, only if it has not been - "discarded" according to the rules of section 6.6.6.) + "discarded" according to the rules of section 6.7.6.) -6.6.5. Detecting Failures with the Echo Function +6.7.5. Detecting Failures with the Echo Function When the Echo function is active and a sufficient number of Echo packets have not arrived as they should, the session has gone down--the local system MUST set bfd.SessionState to Failing, bfd.RemoteHeard to zero, and bfd.LocalDiag to 2 (The Echo Function Failed.) The means by which the Echo function failures are detected is outside of the scope of this specification. Any means which will detect a communication failure is acceptable. -6.6.6. Reception of BFD Control Packets +6.7.6. Reception of BFD Control Packets When a BFD Control packet is received, the following procedure MUST be followed, in the order specified. If the packet is discarded according to these rules, processing of the packet MUST cease at that point. If the version number is not correct (0), the packet MUST be discarded. If the Length field is less than the minimum correct value (24 if @@ -1145,38 +1360,38 @@ discarded. This choice is outside the scope of this specification. If the A bit is set and no authentication is in use (bfd.AuthType is zero), the packet MUST be discarded. If the A bit is clear and authentication is in use (bfd.AuthType is nonzero), the packet MUST be discarded. If the A bit is set, the packet MUST be authenticated under the - rules of section 6.5, based on the authentication type in use + rules of section 6.6, based on the authentication type in use (bfd.AuthType.) This may cause the packet to be discarded. Set bfd.RemoteDiscr to the value of My Discriminator. If the Required Min Echo RX Interval field is zero, the transmission of Echo packets, if any, MUST cease. If Demand mode is active, a Poll Sequence is being transmitted by the local system, and the Final (F) bit in the received packet is set, the Poll Sequence MUST be terminated. If Demand mode is not active, the Final (F) bit in the received packet is set, and the local system has been transmitting packets with the Poll (P) bit set, the Poll (P) bit MUST be set to zero in subsequent transmitted packets. - Update the Detection Time as described in section 6.6.4. + Update the Detection Time as described in section 6.7.4. If bfd.SessionState is Down Set bfd.RemoteHeard to 1 If I Hear You is zero Set bfd.SessionState to Init Else Set bfd.SessionState to Up Else if bfd.SessionState is AdminDown Discard the packet @@ -1189,57 +1404,60 @@ Else if bfd.SessionState is Up If I Hear You is zero Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Failing Set bfd.RemoteHeard to 0 Else if bfd.SessionState is Failing If I Hear You is zero, set bfd.SessionState to Down - Update the transmit interval as described in section 6.6.2. + Update the transmit interval as described in section 6.7.2. If the Demand (D) bit is set and bfd.DemandModeDesired is 1, and bfd.SessionState is Up, Demand mode is active. If the Demand (D) bit is clear or bfd.DemandModeDesired is 0, or bfd.SessionState is not Up, Demand mode is not active. If the Poll (P) bit is set, send a BFD Control packet to the remote system with the Poll (P) bit clear, and the Final (F) bit set. If the packet was not discarded, it has been received for purposes of - the Detection Time expiration rules in section 6.6.4. + the Detection Time expiration rules in section 6.7.4. -6.6.7. Transmitting BFD Control Packets +6.7.7. Transmitting BFD Control Packets BFD Control packets MUST be transmitted periodically at the rate - determined according to section 6.6.2, except as specified in this + determined according to section 6.7.2, except as specified in this section. The transmit interval MUST be recalculated whenever bfd.DesiredMinTxInterval changes, or whenever the received Required Min RX Interval changes, and is equal to the greater of those two - values. See sections 6.6.2 and 6.6.3 for details on transmit timers. + values. See sections 6.7.2 and 6.7.3 for details on transmit timers. A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is zero and the system is taking the Passive role. A system MUST NOT periodically transmit BFD Control packets if Demand mode is active and a Poll Sequence is not being transmitted. A system MUST send a BFD Control packet in response to a received BFD Control Packet with the Poll (P) bit set. The packet sent in response MUST NOT have the Poll (P) bit set, and MUST have the Final - (F) bit set. + (F) bit set. A system MAY limit the rate at which such packets are + transmitted. If rate limiting is in effect, the advertised value of + Desired Min TX Interval must be greater than or equal to the interval + between transmitted packets imposed by the rate limiting function. A single BFD Control packet SHOULD be transmitted between normally scheduled transmissions when the contents of that packet would differ from those in the previously transmitted packet (other than the Poll and Final bits) in order to more rapidly communicate a change in state. The contents of transmitted BFD Control packets MUST be set as follows: @@ -1255,21 +1473,21 @@ Set to bfd.RemoteHeard. Demand (D) Set to bfd.DemandModeDesired. Poll (P) Set to 1 if the local system is sending a Poll Sequence or is - required to do so according to the requirements of section 6.6.3, + required to do so according to the requirements of section 6.7.3, or 0 if not. Final (F) Set to 1 if the local system is responding to a Control packet received with the Poll (P) bit set, or 0 if not. Control Plane Independent (C) Set to 1 if the local system's BFD implementation is independent @@ -1311,184 +1530,204 @@ Required Min Echo RX Interval Set to the minimum required Echo packet receive interval for this session. If this field is set to zero, the local system is unwilling or unable to loop back BFD Echo packets to the remote system, and the remote system will not send Echo packets. Authentication Section - Included and set according to the rules in section 6.5 if + Included and set according to the rules in section 6.6 if authentication is in use (bfd.AuthType is nonzero.) Otherwise this section is not present. -6.6.8. Initiation of a Poll Sequence +6.7.8. Initiation of a Poll Sequence If Demand mode is active, a Poll Sequence MUST be initiated whenever the contents of the next BFD Control packet to be sent would be different than the contents of the previous packet, with the exception of the Poll (P) and Final (F) bits. This ensures that parameter changes are transmitted to the remote system. Note that if the I Hear You (H) bit is changing to zero, the session is going down and Demand mode will no longer be active. If Demand mode is active, a Poll Sequence SHOULD be initiated whenever the system feels the need to verify connectivity with the remote system. The conditions under which this is desirable are outside the scope of this specification. If a Poll Sequence is being sent, and a new Poll Sequence is initiated due to one of the above conditions, the detection interval MUST be restarted in order to ensure that a full Poll Sequence is transmitted under the new conditions. -6.6.9. Reception of BFD Echo Packets +6.7.9. Reception of BFD Echo Packets A received BFD Echo packet MUST be demultiplexed to the appropriate session for processing. A means of detecting missing Echo packets MUST be implemented, which most likely involves processing of the Echo packets that are received. The processing of received Echo packets is otherwise outside the scope of this specification. -6.6.10. Transmission of BFD Echo Packets +6.7.10. Transmission of BFD Echo Packets BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not Up. BFD Echo packets MUST NOT be transmitted unless the last BFD Control packet received from the remote system contains a nonzero value in Required Min Echo RX Interval. BFD Echo packets MAY be transmitted when bfd.SessionState is Up. The interval between transmitted BFD Echo packets MUST NOT be less than the value advertised by the remote system in Required Min Echo RX Interval, except as follows: A 25% jitter MAY be applied to the rate of transmission, such that the actual interval MAY be between 75% and 100% of the advertised value. A single BFD Echo packet MAY be transmitted between normally scheduled Echo transmission intervals. The transmission of BFD Echo packets is otherwise outside the scope of this specification. -6.6.11. Min Rx Interval Change +6.7.11. Min Rx Interval Change When it is desired to change the rate at which BFD Control packets arrive from the remote system, bfd.RequiredMinRxInterval can be changed at any time to any value. The new value will be transmitted in the next outgoing Control packet, and the remote system will - adjust accordingly. See sections 6.6.3 and 6.6.8 for further + adjust accordingly. See sections 6.7.3 and 6.7.8 for further requirements. -6.6.12. Min Tx Interval Change +6.7.12. Min Tx Interval Change When it is desired to change the rate at which BFD Control packets are transmitted to the remote system (subject to the requirements of the neighboring system), bfd.DesiredMinTxInterval can be changed at - any time to any value. The rules in sections 6.6.3 and 6.6.8 apply. + any time to any value. The rules in sections 6.7.3 and 6.7.8 apply. -6.6.13. Detect Multiplier Change +6.7.13. Detect Multiplier Change When it is desired to change the detect multiplier, the value of bfd.DetectMult can be changed to any nonzero value. The new value will be transmitted with the next BFD Control packet. See section - 6.6.8 for additional requirements. + 6.7.8 for additional requirements. -6.6.14. Enabling or Disabling The Echo Function +6.7.14. Enabling or Disabling The Echo Function If it is desired to start or stop the transmission of BFD Echo packets, this MAY be done at any time (subject to the transmission - requirements detailed in section 6.6.10.) + requirements detailed in section 6.7.10.) If it is desired to enable or disable the looping back of received BFD Echo packets, this MAY be done at any time by changing the value of Required Min RX Interval to zero or nonzero in outgoing BFD Control packets. -6.6.15. Enabling or Disabling Demand Mode +6.7.15. Enabling or Disabling Demand Mode If it is desired to start or stop Demand mode, this MAY be done at any time by setting bfd.DemandModeDesired to the proper value. If Demand mode is no longer active, the system MUST begin transmitting - periodic BFD Control packets as described in section 6.6.7. + periodic BFD Control packets as described in section 6.7.7. -6.6.16. Forwarding Plane Reset +6.7.16. Forwarding Plane Reset When the forwarding plane in the local system is reset for some reason, such that the remote system can no longer rely on the local forwarding state, the local system MUST set bfd.LocalDiag to 4 (Forwarding Plane Reset), set bfd.SessionState to Failing, and set bfd.RemoteHeard to zero. -6.6.17. Administrative Control +6.7.17. Administrative Control There may be circumstances where it is desirable to administratively enable or disable a BFD session. When this is desired, the following procedure MUST be followed: If enabling session Set bfd.SessionState to Failing Set bfd.RemoteHeard to zero Else Set bfd.SessionState to AdminDown Set bfd.RemoteHeard to zero Set bfd.LocalDiag to an appropriate value Cease the transmission of BFD Echo packets - Specific diagnostic codes are provided for two scenarios. - If signalling is received from outside BFD that the underlying path has failed, an implementation MAY adminstratively disable the session with the diagnostic Path Down. + Other scenarios MAY use the diagnostic Administratively Down. + +6.7.18. Concatenated Paths + If the path being monitored by BFD is concatenated with other paths, - it may be desirable to administratively bring down the BFD session - when a concatenated path fails (as a way of propagating the - failure indication.) In this case, an implementation MAY - administratively disable the BFD session with the diagnostic - Concatenated Path Down. + it may be desirable to propagate the indication of a failure of one + of those paths across the BFD session (providing an interworking + function for liveness monitoring between BFD and other technologies.) - Other scenarios MAY use the diagnostic Administratively Down. + Two diagnostic codes are defined for this purpose: Concatenated Path + Down and Reverse Concatenated Path Down. The first propagates + forward path failures (in which the concatenated path fails in the + direction toward the interworking system), and the second propagates + reverse path failures (in which the concatenated path fails in the + direction away from the interworking system, assuming a bidirectional + link.) + + A system MAY signal one of these failure states by simply setting + bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD + session is not taken down. If Demand Mode is not active, no other + action is necessary, as the diagnostic code will be carried via the + periodic transmission of BFD Control packets. If Demand Mode is + active, a Poll Sequence MUST be initiated to ensure that the + diagnostic code is transmitted. Note that if the BFD session + subsequently fails, the diagnostic code will be overwritten with a + code detailing the cause of the failure, so it is up to the + interworking agent to perform this procedure again, once the BFD + session reaches Up state, if the propagation of the concatenated path + failure is to resume. Contributors Kireeti Kompella and Yakov Rekhter of Juniper Networks were also significant contributors to this document. Acknowledgments This document was inspired by (and is intended to replace) the Protocol Liveness Protocol draft, written by Kireeti Kompella. Demand Mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang et al. The authors would also like to thank Mike Shand, John Scudder, Stewart Bryant, and Pekka Savola for their substantive input. Security Considerations - As BFD may be tied into the stability of the infrastructure (such as - routing protocols), the effects of an attack on a BFD session may be - very serious. This ultimately has denial-of-service effects, as - links may be declared to be down (or falsely declared to be up.) + As BFD may be tied into the stability of the network infrastructure + (such as routing protocols), the effects of an attack on a BFD + session may be very serious. This ultimately has denial-of-service + effects, as links may be declared to be down (or falsely declared to + be up.) When BFD is run over network layer protocols, a significant denial- of-service risk is created, as BFD packets may be trivial to spoof. When the session is directly connected across a single link (physical, or a secure tunnel such as IPsec), the TTL or Hop Count MUST be set to the maximum on transmit, and checked to be equal to the maximum value on reception (and the packet dropped if this is not - the case.) See [GTSM] for mor information on this technique. If BFD - is run across multiple hops or an insecure tunnel (such as GRE), the - Authentication Section should be utilized. + the case.) See [GTSM] for more information on this technique. If + BFD is run across multiple hops or an insecure tunnel (such as GRE), + the Authentication Section SHOULD be utilized. The level of security provided by the Authentication Section varies based on the authentication type used. Simple Password authentication is obviously only as secure as the secrecy of the passwords used, and should be considered only if the BFD session is guaranteed to be run over an infrastructure not subject to packet interception. Its chief advantage is that it minimizes the computational effort required for authentication. Keyed MD5 authentication is much stronger than Simple Password @@ -1501,59 +1740,70 @@ Meticulous Keyed MD5 authentication is stronger yet, as it requires the sequence number to be incremented for every packet. Replay attack vulnerability is reduced due to the requirement that the sequence number must be incremented on every packet, the window size of acceptable packets is small, and the initial sequence number is randomized. There is still a window of attack at the beginning of the session while the sequence number is being determined. This authentication scheme requires an MD5 calculation on every packet transmitted and received. + Using SHA1 rather than MD5 is believed to have stronger security + properties. All comments about MD5 in this section also apply to + SHA1. + If both systems randomize their Local Discriminator values at the beginning of a session, replay attacks may be further mitigated, regardless of the authentication type in use. Since the Local Discriminator may be changed at any time during a session, this mechanism may also help mitigate attacks. Normative References [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004. [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. + [SHA1] "Secure Hash Standard", United States of America, National + Institute of Science and Technology, Federal Information + Processing Standard (FIPS) 180-1, April 1993. + Authors' Addresses Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, California 94089-1206 USA Phone: +1-408-745-2000 Email: dkatz@juniper.net Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 Email: dward@cisco.com Changes from the previous draft The primary technical change in this draft from the previous version - is the addition of authentication. + is the addition of SHA1 authentication, the addition of a method for + enabling and disabling authentication without disturbing BFD session + state, and the modification of the procedures for handling + concatenated paths. Otherwise, the changes in this draft from the previous version are cosmetic and/or editorial. IPR Notice The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. @@ -1573,40 +1823,28 @@ be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. + + This document expires in August, 2005.