< draft-ietf-bfd-base-10.txt   draft-ietf-bfd-base-11.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
Juniper Networks Juniper Networks
Expires: July, 2010 January 5, 2010 Expires: July, 2010 January 14, 2010
Bidirectional Forwarding Detection Bidirectional Forwarding Detection
draft-ietf-bfd-base-10.txt draft-ietf-bfd-base-11.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 3, line 7 skipping to change at page 3, line 7
6.7.2 Simple Password Authentication . . . . . . . . . . 24 6.7.2 Simple Password Authentication . . . . . . . . . . 24
6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 25 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 . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . 38
6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 41 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 . . . . . . . . . . . . . 42
6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 42 6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 42
6.8.12 Detect Multiplier Change . . . . . . . . . . . . 42 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 . . . . . . . . . . . . . 43
6.8.16 Administrative Control . . . . . . . . . . . . . 43 6.8.16 Administrative Control . . . . . . . . . . . . . 43
6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43 6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43
6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 44 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 44
7. Operational Considerations . . . . . . . . . . . . . . . . . 45 7. Operational Considerations . . . . . . . . . . . . . . . . . 45
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . 47 9. Security Considerations . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . 48 10. References . . . . . . . . . . . . . . . . . . . . . . . . 49
10.1 Normative References . . . . . . . . . . . . . . . . . 48 10.1 Normative References . . . . . . . . . . . . . . . . . 49
10.2 Informative References . . . . . . . . . . . . . . . . 49 10.2 Informative References . . . . . . . . . . . . . . . . 49
Backward Compatibility (Non-Normative) . . . . . . . . . . . . 49 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 49
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 51
Changes from the previous draft . . . . . . . . . . . . . . . . 51 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
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. The shared key MUST be encoded and configured to section field, padded to 16 bytes with trailing zero bytes if needed. The
6.7.3. The shared key MUST be 16 bytes in length. shared key MUST be encoded and configured to section 6.7.3.
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 30 skipping to change at page 15, line 30
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,
padded to a length of 20 bytes with trailing zero bytes if needed.
The shared key MUST be encoded and configured to section 6.7.4. The shared key MUST be encoded and configured to section 6.7.4.
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 24, line 24 skipping to change at page 24, line 25
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 The password is a binary string, and MUST be 1 to 16 bytes in
length. All implementations MUST support the configuration of any length. For interoperability, the management interface by which
arbitrary binary string to ensure interoperability. Other the password is configured MUST accept ASCII strings, and SHOULD
configuration methods MAY be supported. also allow for the configuration of any arbitrary binary string in
hexadecimal form. 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 31 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 authentication key value is a binary string of 16 bytes, and The authentication key value is a binary string of up to 16 bytes,
MUST be placed into the Auth Key/Digest field. All and MUST be placed into the Auth Key/Digest field, padded with
implementations MUST support the configuration of any arbitrary trailing zero bytes as necessary. For interoperability, the
binary string to ensure interoperability. Other configuration management interface by which the key is configured MUST accept
ASCII strings, and SHOULD also allow for the configuration of any
arbitrary binary string in hexadecimal form. Other configuration
methods MAY be supported. methods MAY be supported.
An MD5 digest MUST be calculated over the entire BFD control An MD5 digest MUST be calculated over the entire BFD control
packet. The resulting digest MUST be stored in the Auth packet. The resulting digest MUST be stored in the Auth
Key/Digest field prior to transmission (replacing the secret key, Key/Digest field prior to transmission (replacing the secret key,
which MUST NOT be carried in the packet.) 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
skipping to change at page 27, line 22 skipping to change at page 27, line 23
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 authentication key value is a binary string of 20 bytes, and The authentication key value is a binary string of up to 20 bytes,
MUST be placed into the Auth Key/Hash field. All implementations and MUST be placed into the Auth Key/Hash field, padding with
MUST support the configuration of any arbitrary binary string to trailing zero bytes as necessary. For interoperability, the
ensure interoperability. Other configuration methods MAY be management interface by which the key is configured MUST accept
supported. ASCII strings, and SHOULD also allow for the configuration of any
arbitrary binary string in hexadecimal form. Other configuration
methods MAY be supported.
A SHA1 hash MUST be calculated over the entire BFD control packet. 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 The resulting hash MUST be stored in the Auth Key/Hash field prior
to transmission (replacing the secret key, which MUST NOT be to transmission (replacing the secret key, which MUST NOT be
carried in the packet.) 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
skipping to change at page 48, line 29 skipping to change at page 48, line 29
read [HMAC] and its references. 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 The security implications of the use of BFD Echo packets are
dependent on how those packets are defined, since their structure is dependent on how those packets are defined, since their structure is
local to the transmittiong system and outside the scope of this local to the transmitting system and outside the scope of this
specification. The risks are essentially the same as those of BFD specification. However, since Echo packets are defined and processed
Control packets. [GTSM] could be applied in this case, though the only by the transmitting system, the use of cryptographic
authentication does not guarantee that the other system is actually
alive; an attacker could loop the Echo packets back (without knowing
any secret keys) and cause the link to be falsely declared to be up.
This can be mitigated by using a suitable interval for BFD Control
packets. [GTSM] could be applied to BFD Echo packets, though the
TTL/Hop Count will be decremented by 1 in the course of echoing 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 packet, so spoofing is possible from one hop away.
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.
skipping to change at page 51, line 7 skipping to change at page 51, line 23
Dave Ward Dave Ward
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: dward@juniper.net Email: dward@juniper.net
Changes from the Previous Draft Changes from the Previous Draft
The primary technical change is to make the jitter of transmitted The definition and configuration of passwords and authentication keys
packets a MUST rather than a SHOULD, in order to make congestion was changed slightly to improve interoperability with deployed code.
detection possible. More comprehensive text on congestion control The security considerations for the Echo protocol was changed
was added. Configuration requirements for passwords and secret keys slightly.
was clarified. Text describing packet transmission was consolidated.
The minimal required authentication was clarified. The requirement All other changes are purely editorial in nature.
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 July, 2010. This document expires in July, 2010.
 End of changes. 16 change blocks. 
38 lines changed or deleted 44 lines changed or added

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