--- 1/draft-ietf-bfd-base-06.txt 2008-01-17 08:12:30.000000000 +0100 +++ 2/draft-ietf-bfd-base-07.txt 2008-01-17 08:12:30.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group D. Katz Internet Draft Juniper Networks D. Ward Cisco Systems -Expires: September, 2007 March, 2007 +Expires: July, 2008 January, 2008 Bidirectional Forwarding Detection - draft-ietf-bfd-base-06.txt + draft-ietf-bfd-base-07.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -83,61 +83,61 @@ 6.8.7 Transmitting BFD Control Packets . . . . . . . . . 36 6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 39 6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 39 6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 40 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 40 6.8.12 Detect Multiplier Change . . . . . . . . . . . . 40 6.8.13 Enabling or Disabling the Echo Function . . . . . 40 6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 41 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 41 6.8.16 Administrative Control . . . . . . . . . . . . . 41 - 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 41 + 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 42 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 42 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 43 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 Security Considerations . . . . . . . . . . . . . . . . . . . . 44 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45 Normative References . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 Changes from the previous draft . . . . . . . . . . . . . . . . 46 - IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 47 + IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 46 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. 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 the path, for example, failing interfaces or forwarding engine components. Networks use relatively slow "Hello" mechanisms, usually in routing protocols, to detect failures when there is no hardware signaling to - help out. The time to detect failures ("detection times") available + help out. The time to detect failures ("Detection Times") available in the existing protocols are no better than a second, which is far too long for some applications and represents a great deal of lost data at gigabit rates. Furthermore, routing protocol Hellos are of no help when those routing protocols are not in use, and the semantics of detection are subtly different--they detect a failure in the path between the two routing protocol engines. The goal of BFD is to provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and to the extent possible the forwarding engines themselves. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a - wide range of detection times and overhead, to avoid a proliferation + wide range of Detection Times and overhead, to avoid a proliferation of different methods. This document specifies the details of the base protocol. The use of some mechanisms are application dependent and are specified in a separate series of application documents. These issues are so noted. Note that many of the exact mechanisms are implementation dependent and will not affect interoperability, and are thus outside the scope of this specification. Those issues are so noted. @@ -240,43 +240,43 @@ such a way as to have the other system loop them back through its forwarding path. If a number of packets of the echoed data stream are not received, the session is declared to be down. The Echo function may be used with either Asynchronous or Demand modes. Since the Echo function is handling the task of detection, the rate of periodic transmission of Control packets may be reduced (in the case of Asynchronous mode) or eliminated completely (in the case of Demand mode.) Pure asynchronous mode is advantageous in that it requires half as - many packets to achieve a particular detection time as does the Echo + many packets to achieve a particular Detection Time as does the Echo function. It is also used when the Echo function cannot be supported for some reason. The Echo function has the advantage of truly testing only the forwarding path on the remote system. This may reduce round-trip - jitter and thus allow more aggressive detection times, as well as + jitter and thus allow more aggressive Detection Times, as well as potentially detecting some classes of failure that might not otherwise be detected. The Echo function may be enabled individually in each direction. It is enabled in a particular direction only when the system that loops 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 + Detection Times are essentially driven by the heuristics of the system implementation and are not known to the BFD protocol. Demand mode may not be used when the path round trip time is greater than - the desired detection time. See section 6.6 for more details. + the desired Detection Time. See section 6.6 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. The specific encapsulation is outside of the scope of this specification. See the appropriate application document for encapsulation details. @@ -386,21 +386,21 @@ Demand mode is not active in the transmitting system. Multipoint (M) This bit is reserved for future point-to-multipoint extensions to BFD. It must be zero on both transmit and receipt. Detect Mult Detection time multiplier. The negotiated transmit interval, - multiplied by this value, provides the detection time for the + multiplied by this value, provides the Detection Time for the transmitting system in Asynchronous mode. Length Length of the BFD Control packet, in bytes. My Discriminator A unique, nonzero discriminator value generated by the transmitting system, used to demultiplex multiple BFD sessions @@ -630,31 +630,31 @@ packets. When bidirectional communication is achieved, the BFD session comes Up. Once the BFD session is Up, a system can choose to start the Echo function if it desires to and the other system signals that it will allow it. The rate of transmission of Control packets is typically kept low when the Echo function is active. If the Echo function is not active, the transmission rate of Control packets may be increased to a level necessary to achieve the - detection time requirements for the session. + Detection Time requirements for the session. Once the session is up, a system may signal that it has entered Demand mode, and the transmission of BFD Control packets by the remote system ceases. Other means of implying connectivity are used to keep the session alive. If either system wishes to verify bidirectional connectivity, it can initiate a short exchange of BFD Control packets (a "Poll Sequence"; see section 6.5) to do so. If Demand mode is not active, and no Control packets are received in - the calculated detection time (see section 6.8.4), the session is + the calculated Detection Time (see section 6.8.4), the session is declared Down. This is signaled to the remote end via the State (Sta) field in outgoing packets. If sufficient Echo packets are lost, the session is declared down in the same manner. See section 6.8.5. 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. See section 6.6. @@ -689,50 +689,50 @@ A session remains in Down state until the remote system indicates that it agrees that the session is down by sending a BFD Control packet with the State field set to anything other than Up. If that packet signals Down state, the session advances to Init state; if that packet signals Init state, the session advances to Up state. Semantically, Down state indicates that the forwarding path is unavailable, and that appropriate actions should be taken by the applications monitoring the state of the BFD session. A system MAY hold a session in Down state indefinitely (by simply refusing to advance the session state.) This may be done for operational or - adminstrative reasons, among others. + administrative reasons, among others. 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 signaling Init or Up state (in which case the session advances to Up state) or until the - detection time expires, meaning that communication with the remote + Detection Time expires, meaning that communication with the remote system has been lost (in which case the session advances to Down 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 Down state, or the detection time + If either the remote system signals Down state, or the Detection Time expires, the session advances to Down state. AdminDown state means that the session is being held administratively down. This causes the remote system to enter Down state, and remain there until the local system exits AdminDown state. AdminDown state has no semantic implications for the availability of the forwarding path. The following diagram provides an overview of the state machine. Transitions involving AdminDown state are deleted for clarity (but - are fully specified in section 6.8.6.) The notation on each arc - represents the state of the remote system (as received in the State - field in the BFD Control packet) or indicates the expiration of the - Detection Timer. + are fully specified in sections 6.8.6 and 6.8.16.) The notation on + each arc represents the state of the remote system (as received in + the State field in the BFD Control packet) or indicates the + expiration of the Detection Timer. +--+ | | UP, ADMIN DOWN, TIMER | V DOWN +------+ INIT +------------| |------------+ | | DOWN | | | +-------->| |<--------+ | | | +------+ | | | | | | @@ -785,21 +785,21 @@ packets is not directly signaled to the system looping them back. When a system is using the Echo function, it is advantageous to choose a sedate reception rate for Control packets, since liveness detection is being handled by the Echo packets. This can be controlled by manipulating the Required Min RX Interval field (see section 6.8.3.) If the Echo function is only being run in one direction, the system not running the Echo function will more likely wish to receive fairly - rapid Control packets in order to achieve its desired detection time. + 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 otherwise 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. @@ -848,32 +848,33 @@ 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 Echo function. When a system in Demand mode wishes to verify bidirectional connectivity, it initiates a Poll Sequence (see section 6.5). 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. Note that if Demand mode is operating only on the remote - system, the Poll Sequence is performed on the local system by simply - setting the Poll (P) bit in regular periodic BFD Control packets. + Detection Time expires, at which point the session is declared to be + down. Note that if Demand mode is operating only on the local + system, the Poll Sequence is performed by simply setting the Poll (P) + bit in regular periodic BFD Control packets, as required by section + 6.6. - The detection time in Demand mode is calculated differently than in + 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.8.4 for more details. - Note that this mechanism requires that the detection time negotiated + 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, independently in each direction, by setting or clearing the Demand (D) bit in the BFD Control packet, without affecting the BFD session state. Note that the Demand bit MUST NOT be set unless both systems perceive the session to be Up (the local system thinks the session is Up, and the remote system last reported Up state in the State (Sta) field of the @@ -885,25 +886,25 @@ of the change. If Demand mode is active on either or both systems, 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 and that the remote system acknowledges these changes. Because the underlying detection mechanism is unspecified, and may - differ between the two systems, the overall detection time + 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 + 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. + calculated Detection Time. Note that if Demand mode is enabled in only one direction, continuous bidirectional connectivity verification is lost (only connectivity in the direction from the system in Demand mode to the other system will be verified.) Resolving the issue of one system requesting Demand mode while the other requires continuous bidirectional connectivity verification is outside the scope of this specification. 6.7. Authentication @@ -929,22 +930,22 @@ 6.7.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 detection - time)--a packet with authentication will only be accepted if + do so in a more or less synchronized fashion (within the Detection + 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. @@ -1215,27 +1216,29 @@ 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. + If a period of a Detection Time passes without the receipt of a + valid, authenticated BFD packet from the remote system, this + variable MUST be set to zero. bfd.LocalDiag The diagnostic code specifying the reason for the most recent local session state change to states Down or AdminDown. 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.8.3. The setting of this variable is otherwise outside the scope of this specification. @@ -1260,23 +1263,23 @@ bfd.RemoteDemandMode Set to 1 if the remote system wishes to use Demand mode, or 0 if not. This is the value of the Demand (D) bit in the last received BFD Control packet. This variable MUST be initialized to zero. bfd.DetectMult - The desired detection time multiplier for BFD Control packets. + The desired Detection Time multiplier for BFD Control packets. The negotiated Control packet transmission interval, multiplied - by this variable, will be the detection time for this session + 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.8.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.RcvAuthSeq @@ -1298,21 +1301,21 @@ 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 sequence number can be resynchronized if the remote system restarts. 6.8.2. Timer Negotiation The time values used to determine BFD packet transmission intervals - and the session detection time are continuously negotiated, and thus + 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. 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 to receive them. With the exceptions listed in the remainder of this section, a system MUST NOT transmit BFD Control packets at an interval less than the larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval. In other words, the system reporting the slower rate determines the transmission rate. @@ -1326,44 +1329,44 @@ If bfd.DetectMult is equal to 1, the interval between transmitted BFD Control packets MUST be no more than 90% of the negotiated transmission interval, and MUST be no less than 75% of the negotiated transmission interval. This is to ensure that, on the remote system, the calculated DetectTime does not pass prior to the receipt of the next BFD Control packet. 6.8.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 + 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 either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated (see section 6.5). If the timing is such that a system receiving a Poll Sequence wishes to change the parameters described in this paragraph, the new parameter values may be carried in packets with the Final (F) bit set, even if the Poll Sequence has not yet been sent. If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up, the actual transmission interval used MUST NOT change until the Poll Sequence described above has terminated. This is to ensure that the remote system updates its Detection Time before the transmission interval increases. If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up, the previous value of bfd.RequiredMinRxInterval MUST be used when - calculating the detection time for the remote system until the Poll + calculating the Detection Time for the remote system until the Poll Sequence described above has terminated. This is to ensure that the remote system is transmitting packets at the higher rate (and those - packets are being received) prior to the detection time being + packets are being received) prior to the Detection Time being reduced. When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second (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. If the local system reduces its transmit interval due to bfd.RemoteMinRxInterval being reduced (the remote system has @@ -1377,22 +1380,21 @@ BFD Control packet as soon as practicable. When the Echo function is active, a system SHOULD set bfd.RequiredMinRxInterval to a value of not less than one second (1,000,000 microseconds.) This is intended to keep received BFD Control traffic at a negligible level, since the actual detection function is being performed using BFD Echo packets. In any case other than those explicitly called out above, timing parameter changes MUST be effected immediately (changing the - transmission rate and/or the Detection Time), and a Poll Sequence - SHOULD NOT be sent. + transmission rate and/or the Detection Time). Note that the Poll Sequence mechanism is ambiguous if more than one parameter change is made that would require its use, and those multiple changes are spread across multiple packets (since the semantics of the returning Final are unclear.) Therefore, if multiple changes are made that require the use of a Poll Sequence, there are three choices: 1) they MUST be communicated in a single BFD Control packet (so the semantics of the Final reply are clear), or 2) sufficient time must have transpired since the Poll Sequence was completed to disambiguate the situation (at least a round trip @@ -1402,21 +1404,21 @@ has completed prior to the initiation of another Poll Sequence (this option is not available when Demand mode is active.) 6.8.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 there may - be different detection times in each direction. + be different Detection Times in each direction. The calculation of the Detection Time is slightly different when in Demand mode versus Asynchronous mode. In Asynchronous mode, the Detection Time calculated in the local system is equal to the value of Detect Mult received from the remote system, multiplied by the agreed transmit interval of the remote system (the greater of bfd.RequiredMinRxInterval and the last received Desired Min TX Interval.) The Detect Mult value is (roughly speaking, due to jitter) the number of packets that have to be missed @@ -1545,27 +1547,27 @@ Set bfd.SessionState to Up Else if bfd.SessionState is Init If received State is Init or Up Set bfd.SessionState to Up Else (bfd.SessionState is Up) If received State is Down Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.SessionState to Down - Check to see if Demand mode should become active or not - (see section 6.6). + Check to see if Demand mode should become active or not (see + section 6.6). If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and - bfd.RemoteSessionState is Up, Demand mode is active on the - remote system and the local system MUST cease the periodic - transmission of BFD Control packets (see section 6.8.7.) + bfd.RemoteSessionState is Up, Demand mode is active on the remote + system and the local system MUST cease the periodic transmission + of BFD Control packets (see section 6.8.7.) If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or bfd.RemoteSessionState is not Up, Demand mode is not active on the remote system and the local system MUST send periodic BFD Control packets (see section 6.8.7.) 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 (see section 6.8.7.) @@ -1784,32 +1786,40 @@ procedure MUST be followed: If enabling session Set bfd.SessionState to Down Else Set bfd.SessionState to AdminDown Set bfd.LocalDiag to an appropriate value Cease the transmission of BFD Echo packets - If signaling is received from outside BFD that the underlying - path has failed, an implementation MAY administratively disable - the session with the diagnostic Path Down. + If signaling is received from outside BFD that the underlying path + has failed, an implementation MAY administratively disable the + session with the diagnostic Path Down. Other scenarios MAY use the diagnostic Administratively Down. + BFD Control packets SHOULD be transmitted for at least a Detection + Time after transitioning to AdminDown state in order to ensure that + the remote system is aware of the state change. BFD Control packets + MAY be transmitted indefinitely after transitioning to AdminDown + state in order to maintain session state in each system (see section + 6.8.18 below.) + 6.8.17. Concatenated Paths If the path being monitored by BFD is concatenated with other paths, 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.) + 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 @@ -1854,31 +1864,31 @@ Backward Compatibility (Non-Normative) Although Version 0 of this document is unlikely to have been deployed widely, some implementors may wish to have a backward compatibility mechanism. Note that any mechanism may be potentially used that does not alter the protocol definition, so interoperability should not be an issue. The suggested mechanism described here has the property that it will converge on version 1 if both systems implement it, even if one - system is upgraded from version 0 within a detection time. It will + system is upgraded from version 0 within a Detection Time. It will interoperate with a system that implements only one version (or is configured to support only one version.) A system should obviously not perform this function if it is configured to or is only capable of using a single version. A BFD session will enter a "negotiation holddown" if it is configured for automatic versioning and either has just started up, or the session has been manually cleared. The session is set to AdminDown state and Version 1. During the holddown period, which lasts for one - detection time, the system sends BFD Control packets as usual, but + Detection Time, the system sends BFD Control packets as usual, but ignores received packets. After the holddown time is complete, the state transitions to Down and normal operation resumes. When a system is not in holddown, if it doing automatic versioning and is currently using Version 1, if any Version 0 packet is received for the session, it switches immediately to Version 0. If it is currently using Version 0 and a Version 1 packet is received that indicates that the neighbor is in state AdminDown, it switches to Version 1. If using Version 0 and a Version 1 packet is received indicating a state other than AdminDown, the packet is ignored (per @@ -1898,20 +1908,24 @@ 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, Pekka Savola, and Richard Spencer for their substantive input. + The authors would also like to thank Owen Wheeler for hosting + teleconferences between the authors of this specification and + multiple vendors in order address implementation and clarity issues. + Security Considerations 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. @@ -1958,21 +1972,21 @@ Discriminator may be changed at any time during a session, this mechanism may also help mitigate attacks. IANA Considerations This document has no actions for IANA. Normative References [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism - (GTSM)", RFC 3682, February 2004. + (GTSM)", RFC 5082, October 2007. [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 @@ -1990,47 +2004,27 @@ 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 most significant technical change in this draft is a rework of - Demand Mode, based on bugs turned up by implementation experience. - Additionally, Demand Mode can now be enabled independently in each - direction. - - Text was added requiring that an implementation maintain session - state for a detection time after the session goes down, to ensure - that the remote end can still control the transmit rate of the local - system even when the session isn't up. In conjunction with this, the - semantics of Required Min RX Interval so that a value of zero informs - the remote system that it cannot send any periodic BFD Control - packets. - - Additional state variables were added to support Demand mode, and to - simplify the text elsewhere. - - Text describing how to disambiguate multiple Poll Sequences in the - face of multiple parameter changes was added. - - The pseudocode describing packet reception was reordered slightly. - - Text regarding the semantics of Down and AdminDown state was added. - - Many editorial changes were made. The most significant is to unify - the concept of a Poll Sequence (so that it is independent of Demand - Mode.) Explanatory text was added in a number of places based on - feedback from implementors. + A correction was made to the description of Demand mode in section + 6.6. Another correction was made to the interaction between timing + changes and the transmission of a Poll Sequence in section 6.8.3. + The requirement to clear bfd.RemoteDiscr when the remote system falls + silent was added to section 6.8.1. The continuing transmission of + Control packets in AdminDown state was added to section 6.8.16. All + other changes are purely editorial in nature. 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. The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to @@ -2049,30 +2043,30 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Notice - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). 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 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 September, 2007. + This document expires in July, 2008.