draft-ietf-bfd-base-09.txt   draft-ietf-bfd-base-10.txt 
Network Working Group D. Katz Network Working Group D. Katz
Internet Draft Juniper Networks Internet Draft Juniper Networks
Intended status: Proposed Standard D. Ward Intended status: Proposed Standard D. Ward
Cisco Systems Juniper Networks
Expires: August, 2009 February 5, 2009 Expires: July, 2010 January 5, 2010
Bidirectional Forwarding Detection Bidirectional Forwarding Detection
draft-ietf-bfd-base-09.txt draft-ietf-bfd-base-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Abstract Abstract
This document describes a protocol intended to detect faults in the This document describes a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including bidirectional path between two forwarding engines, including
interfaces, data link(s), and to the extent possible the forwarding interfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. independently of media, data protocols, and routing protocols.
Conventions used in this document Conventions used in this document
skipping to change at page 2, line 44 skipping to change at page 2, line 44
6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 16 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . 16
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 17 6.2 BFD State Machine . . . . . . . . . . . . . . . . . . . 17
6.3 Demultiplexing and the Discriminator Fields . . . . . . 19 6.3 Demultiplexing and the Discriminator Fields . . . . . . 19
6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 20 6.4 The Echo Function and Asymmetry . . . . . . . . . . . . 20
6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 20 6.5 The Poll Sequence . . . . . . . . . . . . . . . . . . . 20
6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 21 6.6 Demand Mode . . . . . . . . . . . . . . . . . . . . . . 21
6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 22 6.7 Authentication . . . . . . . . . . . . . . . . . . . . . 22
6.7.1 Enabling and Disabling Authentication . . . . . . 23 6.7.1 Enabling and Disabling Authentication . . . . . . 23
6.7.2 Simple Password Authentication . . . . . . . . . . 24 6.7.2 Simple Password Authentication . . . . . . . . . . 24
6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 24 6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 25
6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 26 6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 26
6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28 6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28
6.8.1 State Variables . . . . . . . . . . . . . . . . . 28 6.8.1 State Variables . . . . . . . . . . . . . . . . . 29
6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32 6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32
6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32 6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32
6.8.4 Calculating the Detection Time . . . . . . . . . . 34 6.8.4 Calculating the Detection Time . . . . . . . . . . 34
6.8.5 Detecting Failures with the Echo Function . . . . 35 6.8.5 Detecting Failures with the Echo Function . . . . 35
6.8.6 Reception of BFD Control Packets . . . . . . . . . 35 6.8.6 Reception of BFD Control Packets . . . . . . . . . 35
6.8.7 Transmitting BFD Control Packets . . . . . . . . . 37 6.8.7 Transmitting BFD Control Packets . . . . . . . . . 37
6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 40 6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 41
6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 41 6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 41
6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 41 6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 41
6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 41 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 42
6.8.12 Detect Multiplier Change . . . . . . . . . . . . 41 6.8.12 Detect Multiplier Change . . . . . . . . . . . . 42
6.8.13 Enabling or Disabling the Echo Function . . . . . 42 6.8.13 Enabling or Disabling the Echo Function . . . . . 42
6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 42 6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 42
6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 42 6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 42
6.8.16 Administrative Control . . . . . . . . . . . . . 42 6.8.16 Administrative Control . . . . . . . . . . . . . 43
6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43
6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 43 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 44
7. Operational Considerations . . . . . . . . . . . . . . . . . 44 7. Operational Considerations . . . . . . . . . . . . . . . . . 45
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . 47 10. References . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1 Normative References . . . . . . . . . . . . . . . . . 47 10.1 Normative References . . . . . . . . . . . . . . . . . 48
10.2 Informative References . . . . . . . . . . . . . . . . 47 10.2 Informative References . . . . . . . . . . . . . . . . 49
Backward Compatibility (Non-Normative) . . . . . . . . . . . . 47 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 49
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 50
Changes from the previous draft . . . . . . . . . . . . . . . . 49 Changes from the previous draft . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
An increasingly important feature of networking equipment is the An increasingly important feature of networking equipment is the
rapid detection of communication failures between adjacent systems, rapid detection of communication failures between adjacent systems,
in order to more quickly establish alternative paths. Detection can in order to more quickly establish alternative paths. Detection can
come fairly quickly in certain circumstances when data link hardware come fairly quickly in certain circumstances when data link hardware
comes into play (such as SONET alarms.) However, there are media comes into play (such as SONET alarms.) However, there are media
that do not provide this kind of signaling (such as Ethernet), and 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 some media may not detect certain kinds of failures in the path, for
skipping to change at page 5, line 44 skipping to change at page 6, line 5
Each system estimates how quickly it can send and receive BFD packets Each system estimates how quickly it can send and receive BFD packets
in order to come to an agreement with its neighbor about how rapidly in order to come to an agreement with its neighbor about how rapidly
detection of failure will take place. These estimates can be detection of failure will take place. These estimates can be
modified in real time in order to adapt to unusual situations. This modified in real time in order to adapt to unusual situations. This
design also allows for fast systems on a shared medium with a slow design also allows for fast systems on a shared medium with a slow
system to be able to more rapidly detect failures between the fast system to be able to more rapidly detect failures between the fast
systems while allowing the slow system to participate to the best of systems while allowing the slow system to participate to the best of
its ability. its ability.
The ability of each system to control the BFD packet transmission
rate in both directions provides a mechanism for congestion control,
particularly when BFD is used across multiple network hops. The
exact algorithm can be independent in each system without affecting
interoperability, and is outside the scope of this specification.
3.1. Addressing and Session Establishment 3.1. Addressing and Session Establishment
A BFD session is established based on the needs of the application A BFD session is established based on the needs of the application
that will be making use of it. It is up to the application to that will be making use of it. It is up to the application to
determine the need for BFD, and the addresses to use--there is no determine the need for BFD, and the addresses to use--there is no
discovery mechanism in BFD. For example, an OSPF [OSPF] discovery mechanism in BFD. For example, an OSPF [OSPF]
implementation may request a BFD session to be established to a implementation may request a BFD session to be established to a
neighbor discovered using the OSPF Hello protocol. neighbor discovered using the OSPF Hello protocol.
3.2. Operating Modes 3.2. Operating Modes
skipping to change at page 10, line 40 skipping to change at page 10, line 40
Multipoint (M) Multipoint (M)
This bit is reserved for future point-to-multipoint extensions to This bit is reserved for future point-to-multipoint extensions to
BFD. It MUST be zero on both transmit and receipt. BFD. It MUST be zero on both transmit and receipt.
Detect Mult Detect Mult
Detection time multiplier. The negotiated transmit interval, 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. receiving system in Asynchronous mode.
Length Length
Length of the BFD Control packet, in bytes. Length of the BFD Control packet, in bytes.
My Discriminator My Discriminator
A unique, nonzero discriminator value generated by the A unique, nonzero discriminator value generated by the
transmitting system, used to demultiplex multiple BFD sessions transmitting system, used to demultiplex multiple BFD sessions
between the same pair of systems. between the same pair of systems.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
Password authentication, the length is equal to the password Password authentication, the length is equal to the password
length plus three. length plus three.
Auth Key ID Auth Key ID
The authentication key ID in use for this packet. This allows The authentication key ID in use for this packet. This allows
multiple keys to be active simultaneously. multiple keys to be active simultaneously.
Password Password
The simple password in use on this session. The password MUST be The simple password in use on this session. The password is a
from 1 to 16 bytes in length. binary string, and MUST be from 1 to 16 bytes in length. The
password MUST be encoded and configured according to section
6.7.2.
4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format 4.3. Keyed MD5 and Meticulous Keyed MD5 Authentication Section Format
The use of MD5-based authentication is strongly discouraged. The use of MD5-based authentication is strongly discouraged.
However, it is documented here for compatibility with existing However, it is documented here for compatibility with existing
implementations. implementations.
If the Authentication Present (A) bit is set in the header, and the If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous Authentication Type field contains 2 (Keyed MD5) or 3 (Meticulous
Keyed MD5), the Authentication Section has the following format: Keyed MD5), the Authentication Section has the following format:
skipping to change at page 14, line 21 skipping to change at page 14, line 21
The Sequence Number for this packet. For Keyed MD5 The Sequence Number for this packet. For Keyed MD5
Authentication, this value is incremented occasionally. For Authentication, this value is incremented occasionally. For
Meticulous Keyed MD5 Authentication, this value is incremented for Meticulous Keyed MD5 Authentication, this value is incremented for
each successive packet transmitted for a session. This provides each successive packet transmitted for a session. This provides
protection against replay attacks. protection against replay attacks.
Auth Key/Digest Auth Key/Digest
This field carries the 16 byte MD5 digest for the packet. When This field carries the 16 byte MD5 digest for the packet. When
the digest is calculated, the shared MD5 key is stored in this the digest is calculated, the shared MD5 key is stored in this
field. (See section 6.7.3 for details.) The shared key MUST be field. The shared key MUST be encoded and configured to section
16 bytes in length. 6.7.3. The shared key MUST be 16 bytes in length.
4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format
If the Authentication Present (A) bit is set in the header, and the If the Authentication Present (A) bit is set in the header, and the
Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous
Keyed SHA1), the Authentication Section has the following format: Keyed SHA1), the Authentication Section has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 31 skipping to change at page 15, line 31
The Sequence Number for this packet. For Keyed SHA1 The Sequence Number for this packet. For Keyed SHA1
Authentication, this value is incremented occasionally. For Authentication, this value is incremented occasionally. For
Meticulous Keyed SHA1 Authentication, this value is incremented Meticulous Keyed SHA1 Authentication, this value is incremented
for each successive packet transmitted for a session. This for each successive packet transmitted for a session. This
provides protection against replay attacks. provides protection against replay attacks.
Auth Key/Hash Auth Key/Hash
This field carries the 20 byte SHA1 hash for the packet. When the This field carries the 20 byte SHA1 hash for the packet. When the
hash is calculated, the shared SHA1 key is stored in this field. hash is calculated, the shared SHA1 key is stored in this field.
(See section 6.7.4 for details.) The shared key MUST be 20 bytes The shared key MUST be encoded and configured to section 6.7.4.
in length. The shared key MUST be 20 bytes in length.
5. BFD Echo Packet Format 5. BFD Echo Packet Format
BFD Echo packets are sent in an encapsulation appropriate to the BFD Echo packets are sent in an encapsulation appropriate to the
environment. See the appropriate application documents for the environment. See the appropriate application documents for the
specifics of particular environments. specifics of particular environments.
The payload of a BFD Echo packet is a local matter, since only the The payload of a BFD Echo packet is a local matter, since only the
sending system ever processes the content. The only requirement is sending system ever processes the content. The only requirement is
that sufficient information is included to demultiplex the received that sufficient information is included to demultiplex the received
skipping to change at page 21, line 39 skipping to change at page 21, line 39
receipt of traffic from the remote system; another is the use of the receipt of traffic from the remote system; another is the use of the
Echo function. Echo function.
When a system in Demand mode wishes to verify bidirectional When a system in Demand mode wishes to verify bidirectional
connectivity, it initiates a Poll Sequence (see section 6.5). If no connectivity, it initiates a Poll Sequence (see section 6.5). If no
response is received to a Poll, the Poll is repeated until the response is received to a Poll, the Poll is repeated until the
Detection Time expires, at which point the session is declared to be Detection Time expires, at which point the session is declared to be
down. Note that if Demand mode is operating only on the local down. Note that if Demand mode is operating only on the local
system, the Poll Sequence is performed by simply setting the Poll (P) system, the Poll Sequence is performed by simply setting the Poll (P)
bit in regular periodic BFD Control packets, as required by section bit in regular periodic BFD Control packets, as required by section
6.6. 6.5.
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 Asynchronous mode; it is based on the transmit rate of the local
system, rather than the transmit rate of the remote system. This system, rather than the transmit rate of the remote system. This
ensures that the Poll Sequence mechanism works properly. See section ensures that the Poll Sequence mechanism works properly. See section
6.8.4 for more details. 6.8.4 for more details.
Note that the Poll mechanism will always fail unless the negotiated Note that the Poll mechanism will always fail unless the negotiated
Detection Time is greater than the round trip time between the two Detection Time is greater than the round trip time between the two
systems. Enforcement of this constraint is outside the scope of this systems. Enforcement of this constraint is outside the scope of this
skipping to change at page 23, line 16 skipping to change at page 23, line 16
information, obviously must be in use by the two systems. The information, obviously must be in use by the two systems. The
negotiation of authentication type, key exchange, etc. are all negotiation of authentication type, key exchange, etc. are all
outside the scope of this specification and are expected to be outside the scope of this specification and are expected to be
performed by means outside of the protocol. performed by means outside of the protocol.
Note that in the subsections below, to "accept" a packet means only Note that in the subsections below, to "accept" a packet means only
that the packet has passed authentication; it may in fact be that the packet has passed authentication; it may in fact be
discarded for other reasons as described in the general packet discarded for other reasons as described in the general packet
reception rules described in section 6.8.6. reception rules described in section 6.8.6.
Implementations supporting authentication MUST support SHA1 Implementations supporting authentication MUST support both types of
authentication. Other forms of authentication are optional. SHA1 authentication. Other forms of authentication are optional.
6.7.1. Enabling and Disabling Authentication 6.7.1. Enabling and Disabling Authentication
It may be desirable to enable or disable authentication on a session It may be desirable to enable or disable authentication on a session
without disturbing the session state. The exact mechanism for doing without disturbing the session state. The exact mechanism for doing
so is outside the scope of this specification. However, it is useful so is outside the scope of this specification. However, it is useful
to point out some issues in supporting this mechanism. to point out some issues in supporting this mechanism.
In a simple implementation, a BFD session will fail when In a simple implementation, a BFD session will fail when
authentication is either turned on or turned off, because the packet authentication is either turned on or turned off, because the packet
skipping to change at page 24, line 21 skipping to change at page 24, line 21
Control packet. The receiving system accepts the packet if the Control packet. The receiving system accepts the packet if the
Password and Key ID matches one of the Password/ID pairs configured Password and Key ID matches one of the Password/ID pairs configured
in that system. in that system.
Transmission Using Simple Password Authentication Transmission Using Simple Password Authentication
The currently selected password and Key ID for the session MUST be The currently selected password and Key ID for the session MUST be
stored in the Authentication Section of each outgoing BFD Control stored in the Authentication Section of each outgoing BFD Control
packet. The Auth Type field MUST be set to 1 (Simple Password.) packet. The Auth Type field MUST be set to 1 (Simple Password.)
The Auth Len field MUST be set to the proper length (4 to 19 The Auth Len field MUST be set to the proper length (4 to 19
bytes.) bytes).
The password is a binary string, and MUST be 1 to 16 bytes in
length. All implementations MUST support the configuration of any
arbitrary binary string to ensure interoperability. Other
configuration methods MAY be supported.
Reception Using Simple Password Authentication Reception Using Simple Password Authentication
If the received BFD Control packet does not contain an If the received BFD Control packet does not contain an
Authentication Section, or the Auth Type is not 1 (Simple Authentication Section, or the Auth Type is not 1 (Simple
Password), then the received packet MUST be discarded. Password), then the received packet MUST be discarded.
If the Auth Key ID field does not match the ID of a configured If the Auth Key ID field does not match the ID of a configured
password, the received packet MUST be discarded. password, the received packet MUST be discarded.
skipping to change at page 25, line 20 skipping to change at page 25, line 31
or strictly greater than the last sequence number received (for or strictly greater than the last sequence number received (for
Meticulous Keyed MD5.) Meticulous Keyed MD5.)
Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication
The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous 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 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. ID field MUST be set to the ID of the current authentication key.
The Sequence Number field MUST be set to bfd.XmitAuthSeq. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
The current authentication key value MUST be placed into the Auth The authentication key value is a binary string of 16 bytes, and
Key/Digest field. An MD5 digest MUST be calculated over the MUST be placed into the Auth Key/Digest field. All
entire BFD control packet. The resulting digest MUST be stored in implementations MUST support the configuration of any arbitrary
the Auth Key/Digest field prior to transmission (replacing the binary string to ensure interoperability. Other configuration
secret key, which MUST NOT be carried in the packet.) methods MAY be supported.
An MD5 digest MUST be calculated over the entire BFD control
packet. The resulting digest MUST be stored in the Auth
Key/Digest field prior to transmission (replacing the secret key,
which MUST NOT be carried in the packet.)
For Keyed MD5, bfd.XmitAuthSeq 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.) fashion (when treated as an unsigned 32 bit value.)
bfd.XmitAuthSeq 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 changes, or when the transmitted BFD Control packet carries
different contents than the previously transmitted packet. The different contents than the previously transmitted packet. The
decision as to when to increment bfd.XmitAuthSeq is outside the decision as to when to increment bfd.XmitAuthSeq is outside the
scope of this specification. See the section entitled "Security scope of this specification. See the section entitled "Security
Considerations" below for a discussion. Considerations" below for a discussion.
skipping to change at page 27, line 7 skipping to change at page 27, line 22
Meticulous Keyed SHA1.) Meticulous Keyed SHA1.)
Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 Transmission Using Keyed SHA1 and Meticulous Keyed SHA1
Authentication Authentication
The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous 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 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. ID field MUST be set to the ID of the current authentication key.
The Sequence Number field MUST be set to bfd.XmitAuthSeq. The Sequence Number field MUST be set to bfd.XmitAuthSeq.
The current authentication key value MUST be placed into the Auth The authentication key value is a binary string of 20 bytes, and
Key/Hash field. A SHA1 hash MUST be calculated over the entire MUST be placed into the Auth Key/Hash field. All implementations
BFD control packet. The resulting hash MUST be stored in the Auth MUST support the configuration of any arbitrary binary string to
Key/Hash field prior to transmission (replacing the secret key, ensure interoperability. Other configuration methods MAY be
which MUST NOT be carried in the packet.) supported.
A SHA1 hash MUST be calculated over the entire BFD control packet.
The resulting hash MUST be stored in the Auth Key/Hash 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 For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular
fashion (when treated as an unsigned 32 bit value.) fashion (when treated as an unsigned 32 bit value.)
bfd.XmitAuthSeq 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 changes, or when the transmitted BFD Control packet carries
different contents than the previously transmitted packet. The different contents than the previously transmitted packet. The
decision as to when to increment bfd.XmitAuthSeq is outside the decision as to when to increment bfd.XmitAuthSeq is outside the
scope of this specification. See the section entitled "Security scope of this specification. See the section entitled "Security
Considerations" below for a discussion. Considerations" below for a discussion.
skipping to change at page 31, line 8 skipping to change at page 31, line 26
bfd.RemoteDemandMode bfd.RemoteDemandMode
Set to 1 if the remote system wishes to use Demand mode, or 0 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 if not. This is the value of the Demand (D) bit in the last
received BFD Control packet. This variable MUST be initialized received BFD Control packet. This variable MUST be initialized
to zero. to zero.
bfd.DetectMult 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 on the local system. The negotiated Control packet
by this variable, will be the Detection Time for this session transmission interval, multiplied by this variable, will be the
(as seen by the remote system.) This variable MUST be a Detection Time for this session (as seen by the remote system.)
nonzero integer, and is otherwise outside the scope of this This variable MUST be a nonzero integer, and is otherwise
specification. See section 6.8.4 for further information. outside the scope of this specification. See section 6.8.4 for
further information.
bfd.AuthType bfd.AuthType
The authentication type in use for this session, as defined in The authentication type in use for this session, as defined in
section 4.1, or zero if no authentication is in use. section 4.1, or zero if no authentication is in use.
bfd.RcvAuthSeq bfd.RcvAuthSeq
A 32 bit unsigned integer containing the next sequence number A 32 bit unsigned integer containing the last sequence number
for keyed MD5 or SHA1 authentication expected to be received. for keyed MD5 or SHA1 authentication that was received. The
The initial value is unimportant. initial value is unimportant.
bfd.XmitAuthSeq bfd.XmitAuthSeq
A 32 bit unsigned integer containing the next sequence number A 32 bit unsigned integer containing the next sequence number
for keyed MD5 or SHA1 authentication to be transmitted. This for keyed MD5 or SHA1 authentication to be transmitted. This
variable MUST be initialized to a random 32 bit value. variable MUST be initialized to a random 32 bit value.
bfd.AuthSeqKnown bfd.AuthSeqKnown
Set to 1 if the next sequence number for keyed MD5 or SHA1 Set to 1 if the next sequence number for keyed MD5 or SHA1
skipping to change at page 32, line 14 skipping to change at page 32, line 31
6.8.2. Timer Negotiation 6.8.2. Timer Negotiation
The time values used to determine BFD packet transmission intervals 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 may be changed at any time. The negotiation and time values are
independent in each direction for each session. independent in each direction for each session.
Each system reports in the BFD Control packet how rapidly it would 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 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 to receive them. This allows either system to unilaterally determine
section, a system MUST NOT transmit BFD Control packets at an the maximum packet rate (minimum interval) in both directions.
interval less than the larger of bfd.DesiredMinTxInterval and
bfd.RemoteMinRxInterval. In other words, the system reporting the
slower rate determines the transmission rate.
The periodic transmission of BFD Control packets SHOULD be jittered
by up to 25%, that is, the interval SHOULD be reduced by a random
value of 0 to 25%, in order to avoid self-synchronization. Thus, the
average interval between packets may be up to 12.5% less than that
negotiated.
If bfd.DetectMult is equal to 1, the interval between transmitted BFD See section 6.8.7 for the details of packet transmission timing and
Control packets MUST be no more than 90% of the negotiated negotiation.
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 6.8.3. Timer Manipulation
The time values used to determine BFD packet transmission intervals 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 affecting the state of the session. When the timer parameters are
changed for any reason, the requirements of this section apply. changed for any reason, the requirements of this section apply.
If either bfd.DesiredMinTxInterval is changed or If either bfd.DesiredMinTxInterval is changed or
bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
skipping to change at page 37, line 40 skipping to change at page 37, line 47
If the Poll (P) bit is set, send a BFD Control packet to the 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 remote system with the Poll (P) bit clear, and the Final (F) bit
set (see section 6.8.7.) set (see section 6.8.7.)
If the packet was not discarded, it has been received for purposes If the packet was not discarded, it has been received for purposes
of the Detection Time expiration rules in section 6.8.4. of the Detection Time expiration rules in section 6.8.4.
6.8.7. Transmitting BFD Control Packets 6.8.7. Transmitting BFD Control Packets
BFD Control packets MUST be transmitted periodically at the rate With the exceptions listed in the remainder of this section, a system
determined according to section 6.8.2, except as specified in this MUST NOT transmit BFD Control packets at an interval less than the
section. larger of bfd.DesiredMinTxInterval and bfd.RemoteMinRxInterval, less
applied jitter (see below). In other words, the system reporting the
slower rate determines the transmission rate.
The periodic transmission of BFD Control packets MUST be jittered on
a per-packet basis by up to 25%, that is, the interval MUST be
reduced by a random value of 0 to 25%, in order to avoid self-
synchronization with other systems on the same subnetwork. Thus, the
average interval between packets will be roughly 12.5% less than that
negotiated.
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 Detection Time does not pass prior to the receipt of
the next BFD Control packet.
The transmit interval MUST be recalculated whenever The transmit interval MUST be recalculated whenever
bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval
changes, and is equal to the greater of those two values. See changes, and is equal to the greater of those two values. See
sections 6.8.2 and 6.8.3 for details on transmit timers. sections 6.8.2 and 6.8.3 for details on transmit timers.
A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is A system MUST NOT transmit BFD Control packets if bfd.RemoteDiscr is
zero and the system is taking the Passive role. zero and the system is taking the Passive role.
A system MUST NOT periodically transmit BFD Control packets if A system MUST NOT periodically transmit BFD Control packets if
skipping to change at page 43, line 17 skipping to change at page 43, line 34
BFD Control packets SHOULD be transmitted for at least a Detection BFD Control packets SHOULD be transmitted for at least a Detection
Time after transitioning to AdminDown state in order to ensure that Time after transitioning to AdminDown state in order to ensure that
the remote system is aware of the state change. BFD Control packets the remote system is aware of the state change. BFD Control packets
MAY be transmitted indefinitely after transitioning to AdminDown MAY be transmitted indefinitely after transitioning to AdminDown
state in order to maintain session state in each system (see section state in order to maintain session state in each system (see section
6.8.18 below.) 6.8.18 below.)
6.8.17. Concatenated Paths 6.8.17. Concatenated Paths
If the path being monitored by BFD is concatenated with other 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 (connected end-to-end in series), it may be desirable to propagate
of those paths across the BFD session (providing an interworking the indication of a failure of one of those paths across the BFD
function for liveness monitoring between BFD and other technologies.) session (providing an interworking function for liveness monitoring
between BFD and other technologies.)
Two diagnostic codes are defined for this purpose: Concatenated Path Two diagnostic codes are defined for this purpose: Concatenated Path
Down and Reverse Concatenated Path Down. The first propagates Down and Reverse Concatenated Path Down. The first propagates
forward path failures (in which the concatenated path fails in the forward path failures (in which the concatenated path fails in the
direction toward the interworking system), and the second propagates direction toward the interworking system), and the second propagates
reverse path failures (in which the concatenated path fails in the reverse path failures (in which the concatenated path fails in the
direction away from the interworking system, assuming a bidirectional direction away from the interworking system, assuming a bidirectional
link.) link.)
A system MAY signal one of these failure states by simply setting A system MAY signal one of these failure states by simply setting
skipping to change at page 44, line 20 skipping to change at page 44, line 36
transmit an arbitrarily large value in the Required Min RX Interval transmit an arbitrarily large value in the Required Min RX Interval
field to control the rate at which it receives packets. field to control the rate at which it receives packets.
Additionally, a system MAY transmit a value of zero for Required Min Additionally, a system MAY transmit a value of zero for Required Min
RX Interval to indicate that the remote system should send no packets RX Interval to indicate that the remote system should send no packets
whatsoever. whatsoever.
So long as the local system continues to transmit BFD Control So long as the local system continues to transmit BFD Control
packets, the remote system is obligated to obey the value carried in packets, the remote system is obligated to obey the value carried in
Required Min RX Interval. If the remote system does not receive any Required Min RX Interval. If the remote system does not receive any
BFD Control packets for a Detection Time, it resets BFD Control packets for a Detection Time, it SHOULD reset
bfd.RemoteMinRxIvl to a small value and then can transmit at its own bfd.RemoteMinRxInterval to its initial value of 1 (per section 6.8.1,
rate. since it is no longer required to maintain previous session state)
and then can transmit at its own rate.
7. Operational Considerations 7. Operational Considerations
BFD is likely to be deployed as a critical part of network BFD is likely to be deployed as a critical part of network
infrastructure. As such, care should be taken to avoid disruption. infrastructure. As such, care should be taken to avoid disruption.
Obviously, any mechanism that blocks BFD packets, such as firewalls Obviously, any mechanism that blocks BFD packets, such as firewalls
or other policy processes, will cause BFD to fail. or other policy processes, will cause BFD to fail.
Mechanisms that control packet scheduling, such as policers, traffic Mechanisms that control packet scheduling, such as policers, traffic
shapers, priority queueing, etc., have the potential of impacting BFD shapers, priority queueing, etc., have the potential of impacting BFD
operations if the Detection Time is similar in scale to the scheduled operations if the Detection Time is similar in scale to the scheduled
packet transmit or receive rate. The delivery of BFD packets is packet transmit or receive rate. The delivery of BFD packets is
time-critical, relative to the magnitude of the Detection Time, so time-critical, relative to the magnitude of the Detection Time, so
this may need to be taken into account in implementation and this may need to be taken into account in implementation and
deployment, particularly when very short Detection Times are to be deployment, particularly when very short Detection Times are to be
used. used.
When BFD is used across multiple hops, a congestion control mechanism
MUST be implemented, and when congestion is detected, the BFD
implementation MUST reduce the amount of traffic it generates. The
exact mechanism used is outside the scope of this specification, and
the requirements of this mechanism may differ depending on how BFD is
deployed, and how it interacts with other parts of the system (for
example, exponential backoff may not be appropriate in cases where
routing protocols are interacting closely with BFD.)
Note that "congestion" is not only a traffic phenomenon, but also a
computational one. It is possible for systems with a large number of
BFD sessions and/or very short packet intervals to become CPU-bound.
As such, a congestion control algorithm SHOULD be used even across
single hops in order to avoid the possibility of catastrophic system
collapse, as such failures have been seen repeatedly in other
periodic hello-based protocols.
The mechanisms for detecting congestion are outside the scope of this
specification, but may include the detection of lost BFD Control
packets (by virtue of holes in the authentication sequence number
space, or by BFD session failure) or other means.
The mechanisms for reducing BFD's traffic load are the control of the
local and remote packet transmission rate via the Min RX Interval and
Min TX Interval fields.
Note that any mechanism that increases the transmit or receive
intervals will increase the Detection Time for the session.
It is worth noting that a single BFD session does not consume a large
amount of bandwidth. An aggressive session that achieves a detection
time of 50 milliseconds, by using a transmit interval of 16.7
milliseconds and a detect multiplier of 3, will generate 60 packets
per second. The maximum length of each packet on the wire is on the
order of 100 bytes, for a total of around 48 kilobits per second of
bandwidth consumption in each direction.
8. IANA Considerations 8. IANA Considerations
This document defines two registries to be administered by IANA. The This document defines two registries to be administered by IANA. The
first is entitled "BFD Diagnostic Codes" (see section 4.1). Initial first is entitled "BFD Diagnostic Codes" (see section 4.1). Initial
values for the BFD Diagnostic Code registry are given below. Further values for the BFD Diagnostic Code registry are given below. Further
assignments are to be made through Expert Review [IANA- assignments are to be made through Expert Review [IANA-
CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name CONSIDERATIONS]. Assignments consist of a BFD Diagnostic Code name
and its associated value. and its associated value.
Value BFD Diagnostic Code Name Value BFD Diagnostic Code Name
----- ------------------------ ----- ------------------------
0 No Diagnostic 0 No Diagnostic
1 Control Detection Time Expired 1 Control Detection Time Expired
2 Echo Function Failed 2 Echo Function Failed
3 Neighbor Signaled Session Down 3 Neighbor Signaled Session Down
4 Forwarding Plane Reset 4 Forwarding Plane Reset
5 Path Down 5 Path Down
6 Concatenated Path Down 6 Concatenated Path Down
7 Administratively Down 7 Administratively Down
8 Reverse Concatenated Path Down 8 Reverse Concatenated Path Down
9-31 Reserved 9-31 Unassigned
The second registry is entitled "BFD Authentication Types" (see section The second registry is entitled "BFD Authentication Types" (see section
4.1). Initial values for the BFD Authentication Type registry are given 4.1). Initial values for the BFD Authentication Type registry are given
below. Further assignments are to be made through Expert Review below. Further assignments are to be made through Expert Review
[IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type [IANA-CONSIDERATIONS]. Assignments consist of a BFD Authentication Type
Code name and its associated value. Code name and its associated value.
Value BFD Diagnostic Code Name Value BFD Authentication Type Name
----- ------------------------ ----- ----------------------------
0 Reserved 0 Reserved
1 Simple Password 1 Simple Password
2 Keyed MD5 2 Keyed MD5
3 Meticulous Keyed MD5 3 Meticulous Keyed MD5
4 Keyed SHA1 4 Keyed SHA1
5 Meticulous Keyed SHA1 5 Meticulous Keyed SHA1
6-255 Reserved 6-255 Unassigned
9. Security Considerations 9. Security Considerations
As BFD may be tied into the stability of the network infrastructure As BFD may be tied into the stability of the network infrastructure
(such as routing protocols), the effects of an attack on a BFD (such as routing protocols), the effects of an attack on a BFD
session may be very serious. This ultimately has denial-of-service session may be very serious: a link may be falsely declared to be
effects, as links may be declared to be down (or falsely declared to down, or falsely declared to be up; in either case, the effect is
be up.) denial-of-service.
When BFD is run over network layer protocols, a significant denial- An attacker who is in complete control of the link between the
of-service risk is created, as BFD packets may be trivial to spoof. systems can easily drop all BFD packets but forward everything else
When the session is directly connected across a single link (causing the link to be falsely declared down), or forward only the
BFD packets but nothing else (causing the link to be falsely declared
up). This attack cannot be prevented by BFD.
To mitigate threats from less capable attackers, BFD specifies two
mechanisms to prevent spoofing of BFD Control packets. The
Generalized TTL Security Mechanism [GTSM] uses the TTL or Hop Count
to prevent off-link attackers from spoofing packets. The
Authentication Section authenticates the BFD Control packets. These
mechanisms are described in more detail below.
When a BFD session is directly connected across a single link
(physical, or a secure tunnel such as IPsec), the TTL or Hop Count (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 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 maximum value on reception (and the packet dropped if this is not
the case.) See [GTSM] for more information on this technique. If the case.) See [GTSM] for more information on this technique. If
BFD is run across multiple hops or an insecure tunnel (such as GRE), BFD is run across multiple hops or an insecure tunnel (such as GRE),
the Authentication Section SHOULD be utilized. the Authentication Section SHOULD be utilized.
The level of security provided by the Authentication Section varies The level of security provided by the Authentication Section varies
based on the authentication type used. Simple Password based on the authentication type used. Simple Password
authentication is obviously only as secure as the secrecy of the authentication is obviously only as secure as the secrecy of the
skipping to change at page 46, line 51 skipping to change at page 48, line 13
sequence number must be incremented on every packet, the window size sequence number must be incremented on every packet, the window size
of acceptable packets is small, and the initial sequence number is of acceptable packets is small, and the initial sequence number is
randomized. There is still a window of attack at the beginning of randomized. There is still a window of attack at the beginning of
the session while the sequence number is being determined. This the session while the sequence number is being determined. This
authentication scheme requires an MD5 calculation on every packet authentication scheme requires an MD5 calculation on every packet
transmitted and received. transmitted and received.
Using SHA1 is believed to have stronger security properties than MD5. Using SHA1 is believed to have stronger security properties than MD5.
All comments about MD5 in this section also apply to SHA1. All comments about MD5 in this section also apply to SHA1.
Both Keyed MD5/SHA1 and Meticulous Keyed MD5/SHA1 use the "secret
suffix" construction (also called "append only") in which the shared
secret key is appended to the data before calculating the hash,
instead of the more common HMAC construction [HMAC]. This
construction is believed to be appropriate for BFD, but designers of
any additional authentication mechanisms for BFD are encouraged to
read [HMAC] and its references.
If both systems randomize their Local Discriminator values at the If both systems randomize their Local Discriminator values at the
beginning of a session, replay attacks may be further mitigated, beginning of a session, replay attacks may be further mitigated,
regardless of the authentication type in use. Since the Local regardless of the authentication type in use. Since the Local
Discriminator may be changed at any time during a session, this Discriminator may be changed at any time during a session, this
mechanism may also help mitigate attacks. mechanism may also help mitigate attacks.
The security implications of the use of BFD Echo packets are
dependent on how those packets are defined, since their structure is
local to the transmittiong system and outside the scope of this
specification. The risks are essentially the same as those of BFD
Control packets. [GTSM] could be applied in this case, though the
TTL/Hop Count will be decremented by 1 in the course of echoing the
packet, so spoofing is possible from one hop away. The use of
cryptographic authentication can mitigate the risk of spoofing.
10. References 10. References
10.1. Normative References 10.1. Normative References
[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992. 1992.
[SHA1] Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, [SHA1] Eastlake, D., "US Secure Hash Algorithm 1 (SHA1)", RFC 3174,
September 2001. September 2001.
10.2. Informative References 10.2. Informative References
[HMAC] Krawczyk, H., et al, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February, 1997.
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, RFC Writing an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998. 5226, May 2008.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
Backward Compatibility (Non-Normative) Backward Compatibility (Non-Normative)
Although Version 0 of this document is unlikely to have been deployed Although Version 0 of this document is unlikely to have been deployed
widely, some implementors may wish to have a backward compatibility widely, some implementors may wish to have a backward compatibility
mechanism. Note that any mechanism may be potentially used that does mechanism. Note that any mechanism may be potentially used that does
not alter the protocol definition, so interoperability should not be not alter the protocol definition, so interoperability should not be
an issue. an issue.
skipping to change at page 48, line 40 skipping to change at page 50, line 22
Acknowledgments Acknowledgments
This document was inspired by (and is intended to replace) the This document was inspired by (and is intended to replace) the
Protocol Liveness Protocol draft, written by Kireeti Kompella. Protocol Liveness Protocol draft, written by Kireeti Kompella.
Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang
et al. et al.
The authors would also like to thank Mike Shand, John Scudder, The authors would also like to thank Mike Shand, John Scudder,
Stewart Bryant, Pekka Savola, and Richard Spencer for their Stewart Bryant, Pekka Savola, Richard Spencer, and Pasi Eronen for
substantive input. their substantive input.
The authors would also like to thank Owen Wheeler for hosting The authors would also like to thank Owen Wheeler for hosting
teleconferences between the authors of this specification and teleconferences between the authors of this specification and
multiple vendors in order address implementation and clarity issues. multiple vendors in order address implementation and clarity issues.
Authors' Addresses Authors' Addresses
Dave Katz Dave Katz
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA Sunnyvale, California 94089-1206 USA
Phone: +1-408-745-2000 Phone: +1-408-745-2000
Email: dkatz@juniper.net Email: dkatz@juniper.net
Dave Ward Dave Ward
Cisco Systems Juniper Networks
170 W. Tasman Dr. 1194 N. Mathilda Ave.
San Jose, CA 95134 USA Sunnyvale, California 94089-1206 USA
Phone: +1-408-526-4000 Phone: +1-408-745-2000
Email: dward@cisco.com Email: dward@juniper.net
Changes from the Previous Draft Changes from the Previous Draft
A note was added about the availability of the timer mechanism for The primary technical change is to make the jitter of transmitted
congestion control. Text was added about the need for out-of-band packets a MUST rather than a SHOULD, in order to make congestion
negotiation of authentication parameters. The sequence number check detection possible. More comprehensive text on congestion control
was moved before the digest/hash calculation (this is a backward was added. Configuration requirements for passwords and secret keys
compatible change.) An Operational Considerations section was added. was clarified. Text describing packet transmission was consolidated.
All other changes are purely editorial in nature. The minimal required authentication was clarified. The requirement
to maintain state after a BFD session failure was clarified. The
Security Considerations section was expanded. All other changes are
purely editorial in nature.
This document expires in August, 2009. This document expires in July, 2010.
 End of changes. 40 change blocks. 
109 lines changed or deleted 200 lines changed or added

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/