--- 1/draft-ietf-bfd-base-10.txt 2010-01-15 07:11:02.000000000 +0100 +++ 2/draft-ietf-bfd-base-11.txt 2010-01-15 07:11:02.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group D. Katz Internet Draft Juniper Networks Intended status: Proposed Standard D. Ward Juniper Networks -Expires: July, 2010 January 5, 2010 +Expires: July, 2010 January 14, 2010 Bidirectional Forwarding Detection - draft-ietf-bfd-base-10.txt + draft-ietf-bfd-base-11.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -85,42 +85,42 @@ 6.7.2 Simple Password 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.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28 6.8.1 State Variables . . . . . . . . . . . . . . . . . 29 6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32 6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32 6.8.4 Calculating the Detection Time . . . . . . . . . . 34 6.8.5 Detecting Failures with the Echo Function . . . . 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.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.12 Detect Multiplier Change . . . . . . . . . . . . 42 6.8.13 Enabling or Disabling the Echo Function . . . . . 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.17 Concatenated Paths . . . . . . . . . . . . . . . 43 6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 44 7. Operational Considerations . . . . . . . . . . . . . . . . . 45 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46 9. Security Considerations . . . . . . . . . . . . . . . . . . 47 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . 48 - 10.1 Normative References . . . . . . . . . . . . . . . . . 48 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . 49 + 10.1 Normative References . . . . . . . . . . . . . . . . . 49 10.2 Informative References . . . . . . . . . . . . . . . . 49 Backward Compatibility (Non-Normative) . . . . . . . . . . . . 49 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 50 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 51 Changes from the previous draft . . . . . . . . . . . . . . . . 51 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 @@ -551,22 +551,22 @@ The Sequence Number for this packet. For Keyed MD5 Authentication, this value is incremented occasionally. For Meticulous Keyed MD5 Authentication, this value is incremented for each successive packet transmitted for a session. This provides protection against replay attacks. Auth Key/Digest This field carries the 16 byte MD5 digest for the packet. When the digest is calculated, the shared MD5 key is stored in this - field. The shared key MUST be encoded and configured to section - 6.7.3. The shared key MUST be 16 bytes in length. + field, padded to 16 bytes with trailing zero bytes if needed. The + shared key MUST be encoded and configured to section 6.7.3. 4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1), the Authentication Section has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -602,23 +602,23 @@ The Sequence Number for this packet. For Keyed SHA1 Authentication, this value is incremented occasionally. For Meticulous Keyed SHA1 Authentication, this value is incremented for each successive packet transmitted for a session. This provides protection against replay attacks. Auth Key/Hash 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 20 bytes in length. 5. BFD Echo Packet Format BFD Echo packets are sent in an encapsulation appropriate to the environment. See the appropriate application documents for the specifics of particular environments. The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received @@ -1004,23 +1004,24 @@ Transmission Using Simple Password Authentication The currently selected password and Key ID for the session MUST be stored in the Authentication Section of each outgoing BFD Control 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 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. + length. For interoperability, the management interface by which + the password 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. Reception Using Simple Password Authentication If the received BFD Control packet does not contain an Authentication Section, or the Auth Type is not 1 (Simple Password), then the received packet MUST be discarded. If the Auth Key ID field does not match the ID of a configured password, the received packet MUST be discarded. @@ -1051,24 +1052,26 @@ or strictly greater than the last sequence number received (for Meticulous Keyed MD5.) Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key ID field MUST be set to the ID of the current authentication key. The Sequence Number field MUST be set to bfd.XmitAuthSeq. - The authentication key value is a binary string of 16 bytes, and - MUST be placed into the Auth Key/Digest field. All - implementations MUST support the configuration of any arbitrary - binary string to ensure interoperability. Other configuration + The authentication key value is a binary string of up to 16 bytes, + and MUST be placed into the Auth Key/Digest field, padded with + trailing zero bytes as necessary. For interoperability, the + 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. 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 fashion (when treated as an unsigned 32 bit value.) bfd.XmitAuthSeq SHOULD be incremented when the session state @@ -1136,25 +1139,27 @@ Meticulous Keyed SHA1.) Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 Authentication The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key ID field MUST be set to the ID of the current authentication key. The Sequence Number field MUST be set to bfd.XmitAuthSeq. - The authentication key value is a binary string of 20 bytes, and - MUST be placed into the Auth Key/Hash field. All implementations - MUST support the configuration of any arbitrary binary string to - ensure interoperability. Other configuration methods MAY be - supported. + The authentication key value is a binary string of up to 20 bytes, + and MUST be placed into the Auth Key/Hash field, padding with + trailing zero bytes as necessary. For interoperability, the + 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. 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 fashion (when treated as an unsigned 32 bit value.) bfd.XmitAuthSeq SHOULD be incremented when the session state changes, or when the transmitted BFD Control packet carries @@ -2085,26 +2090,30 @@ read [HMAC] and its references. If both systems randomize their Local Discriminator values at the beginning of a session, replay attacks may be further mitigated, regardless of the authentication type in use. Since the Local Discriminator may be changed at any time during a session, this mechanism may also help mitigate attacks. 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 + local to the transmitting system and outside the scope of this + specification. However, since Echo packets are defined and processed + 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 - packet, so spoofing is possible from one hop away. The use of - cryptographic authentication can mitigate the risk of spoofing. + packet, so spoofing is possible from one hop away. 10. References 10.1. Normative References [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. @@ -2194,21 +2204,18 @@ Dave Ward Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, California 94089-1206 USA Phone: +1-408-745-2000 Email: dward@juniper.net Changes from the Previous Draft - The primary technical change is to make the jitter of transmitted - packets a MUST rather than a SHOULD, in order to make congestion - detection possible. More comprehensive text on congestion control - was added. Configuration requirements for passwords and secret keys - was clarified. Text describing packet transmission was consolidated. - 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. + The definition and configuration of passwords and authentication keys + was changed slightly to improve interoperability with deployed code. + The security considerations for the Echo protocol was changed + slightly. + + All other changes are purely editorial in nature. This document expires in July, 2010.