draft-ietf-bfd-generic-crypto-auth-02.txt   draft-ietf-bfd-generic-crypto-auth-03.txt 
Network Working Group M. Bhatia Network Working Group M. Bhatia
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track V. Manral Intended status: Standards Track V. Manral
Expires: December 9, 2012 Hewlett-Packard Co. Expires: April 22, 2013 Hewlett-Packard Co.
D. Zhang D. Zhang
Huawei Huawei
June 7, 2012 October 19, 2012
BFD Generic Cryptographic Authentication BFD Generic Cryptographic Authentication
draft-ietf-bfd-generic-crypto-auth-02 draft-ietf-bfd-generic-crypto-auth-03
Abstract Abstract
This document proposes an extension to Bidirectional Forwarding This document proposes an extension to Bidirectional Forwarding
Detection (BFD) to allow the use of any cryptographic authentication Detection (BFD) to allow the use of any cryptographic authentication
algorithm in addition to the already-documented authentication algorithm in addition to the already-documented authentication
schemes described in the base specification. This document adds the schemes described in the base specification. This document adds the
basic infrastructure that is required for supporting algorithm and basic infrastructure that is required for supporting algorithm and
key agility for BFD. key agility for BFD.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 9, 2012. This Internet-Draft will expire on April 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2. BFD Security Association . . . . . . . . . . . . . . . . . . . 4 2. BFD Security Association . . . . . . . . . . . . . . . . . . . 4
3. Authentication Procedures . . . . . . . . . . . . . . . . . . 5 3. Authentication Procedures . . . . . . . . . . . . . . . . . . 5
3.1. Authentication Types . . . . . . . . . . . . . . . . . . . 5 3.1. Authentication Types . . . . . . . . . . . . . . . . . . . 5
3.2. Authentication Section Format . . . . . . . . . . . . . . 6 3.2. Authentication Section Format . . . . . . . . . . . . . . 6
3.3. Procedures at the Sending Side . . . . . . . . . . . . . . 6 3.3. Procedures at the Sending Side . . . . . . . . . . . . . . 6
3.4. Procedure at the Receiving Side . . . . . . . . . . . . . 7 3.4. Procedure at the Receiving Side . . . . . . . . . . . . . 7
3.5. Key Selection for BFD Packet Transmission . . . . . . . . 8 3.5. Key Selection for BFD Packet Transmission . . . . . . . . 8
3.6. Replay Protection using Extended Sequence Numbers . . . . 9 3.6. Replay Protection using Extended Sequence Numbers . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The base specification of bidirectional Forwarding Detection (BFD) The base specification of bidirectional Forwarding Detection (BFD)
[RFC5880] defines five authentication schemes: Simple Password, Keyed [RFC5880] defines five authentication schemes: Simple Password, Keyed
MD5 , Meticulous Keyed MD5, Keyed SHA-1, and Meticulous SHA-1. In MD5 , Meticulous Keyed MD5, Keyed SHA-1, and Meticulous SHA-1. In
Simple Password, passwords are transferred in plaintext. An attacker Simple Password, passwords are transferred in plaintext. An attacker
with physical access to the network can easily eavesdrop on the with physical access to the network can easily eavesdrop on the
password and compromise the security of the BFD packet exchanges. In password and compromise the security of the BFD packet exchanges. In
Keyed MD5 and Meticulous Keyed MD5, the BFD devices on the both sides Keyed MD5 and Meticulous Keyed MD5, the BFD devices on the both sides
skipping to change at page 3, line 43 skipping to change at page 3, line 43
vulnerability to replay attacks. In non-meticulous authentication vulnerability to replay attacks. In non-meticulous authentication
schemes, sequence numbers are only increased occasionally. This schemes, sequence numbers are only increased occasionally. This
behavior can be taken advantage of by an attacker to perform intra- behavior can be taken advantage of by an attacker to perform intra-
session replay attacks. In meticulous authentication schemes, session replay attacks. In meticulous authentication schemes,
sequence numbers are required to monotonically increase with each sequence numbers are required to monotonically increase with each
successive packet, which eliminates the possibility of intra-session successive packet, which eliminates the possibility of intra-session
replay attacks. replay attacks.
BFD session timers are often defined with the granularity of BFD session timers are often defined with the granularity of
microseconds. Although in practice BFD devices send packets at microseconds. Although in practice BFD devices send packets at
millisecond intervals, they can potentially, send packets at a much millisecond intervals, they can potentially send packets at a much
higher rate. Since the cryptographic sequence number space is only higher rate. Since the cryptographic sequence number space is only
32 bits, when using Meticulous Authentication, a sequence number used 32 bits, when using Meticulous Authentication, a sequence number used
in a BFD session can reach its maximum value and roll over within a in a BFD session can reach its maximum value and roll over within a
short period. For instance, if the value of a sequence number is short period. For instance, if the value of a sequence number is
increased by one every millisecond, then it will reach its maximum in increased by one every millisecond, then it will reach its maximum in
less than 8 weeks. This can potentially be exploited to launch less than 8 weeks. This can potentially be exploited to launch
inter-session replay attacks. inter-session replay attacks.
In order to address the issues mentioned above, this document In order to address the issues mentioned above, this document
proposes two new authentication types that can be used to secure the proposes two new authentication types that can be used to secure the
BFD packets. The two authentication types are - Cryptographic BFD packets. The two authentication types are - Cryptographic
Authentication (CRYPTO_AUTH) and Meticulous Cryptographic Authentication (CRYPTO_AUTH) and Meticulous Cryptographic
Authentication (MET_ CRYPTO_AUTH). Unlike earlier authentication Authentication (MET_ CRYPTO_AUTH). Unlike earlier authentication
types that were defined in BFD, the proposed authentication types are types that were defined in BFD, the proposed authentication types are
not tied to any particular authentication algorithm or a construct. not tied to any particular authentication algorithm or construct.
These can use different authentication algorithms and constructs like These can use different authentication algorithms and constructs like
MD5, SHA-1, SHA-2, HMAC-SHA1, HMAC-SHA2, etc. to provide MD5, SHA-1, SHA-2, HMAC-SHA1, HMAC-SHA2, etc. to provide
authentication and data integrity protection for BFD control packets. authentication and data integrity protection for BFD control packets.
The packet replay mechanism has also been modified to improve its The packet replay mechanism has also been modified to improve its
capability in handling inter and intra-session replay attacks. capability in handling inter and intra-session replay attacks.
It should be noted that this document attempts to fix the manual key It should be noted that this document attempts to fix the manual key
management procedure that currently exists within BFD, as part of the management procedure that currently exists within BFD, as part of the
Phase One described in KARP-design-guide Phase One described in KARP-design-guide
skipping to change at page 4, line 31 skipping to change at page 4, line 31
considered in this document. However, the solution described in this considered in this document. However, the solution described in this
document is generic and does not preclude the possibility of document is generic and does not preclude the possibility of
supporting keys derived from an automated key management protocol. supporting keys derived from an automated key management protocol.
2. BFD Security Association 2. BFD Security Association
The BFD protocol does not include an in-band mechanism to create or The BFD protocol does not include an in-band mechanism to create or
manage BFD Security Associations (BFD SA). A BFD SA contains a set manage BFD Security Associations (BFD SA). A BFD SA contains a set
of shared parameters between any two legitimate BFD devices. of shared parameters between any two legitimate BFD devices.
Parameters associated with a BFD SA: The parameters associated with a BFD SA are listed as follows:
o Authentication Algorithm : This indicates the authentication o Authentication Algorithm : This indicates the authentication
algorithm to be used with the BFD SA. This information SHOULD never algorithm to be used with the BFD SA. This information SHOULD never
be sent in plaintext over the wire. be sent in plaintext over the wire.
o Authentication Key : This indicates the cryptographic key o Authentication Key : This indicates the cryptographic key
associated with this BFD SA. The length of this key is variable and associated with this BFD SA. The length of this key is variable and
depends upon the authentication algorithm specified by the BFD SA. depends upon the authentication algorithm specified by the BFD SA.
Operators MUST ensure that this is never sent over the network in Operators MUST ensure that this is never sent over the network in
clear-text via any protocol. Care should also be taken to ensure clear-text via any protocol. Care should also be taken to ensure
skipping to change at page 6, line 12 skipping to change at page 6, line 12
As a result of this, in the Cryptographic Authentication scheme, a As a result of this, in the Cryptographic Authentication scheme, a
replay attack is possible till the next sequence number is sent out. replay attack is possible till the next sequence number is sent out.
3.2. Authentication Section Format 3.2. Authentication Section Format
A new authentication type, 6 or 7, indicating the generic A new authentication type, 6 or 7, indicating the generic
cryptographic authentication mechanism in use, is inserted in the cryptographic authentication mechanism in use, is inserted in the
first octet of Authentication Section of the BFD control packet. first octet of Authentication Section of the BFD control packet.
For a BFD packet, if the Authentication Present (A) bit is set in the For a BFD packet, if the Authentication Present (A) bit is set in the
header, and the Authentication Type field if 6 (Generic Cryptographic header and the Authentication Type field is 6 (Generic Cryptographic
Authentication) or 7 (Generic Meticulous Cryptographic Authentication) or 7 (Generic Meticulous Cryptographic
Authentication), the Authentication Section has the following format: Authentication), 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | | Auth Type | Auth Len | Auth Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (High Order 32 Bits) | | Sequence Number (High Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Low Order 32 Bits) | | Sequence Number (Low Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Authentication Data (Variable) | | Authentication Data (Variable) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Auth Type: The Authentication Type, which in this case is 6 o Auth Type: The Authentication Type, which in this case is 6
(Cryptographic Authentication) or 7 (Meticulous Cryptographic (Cryptographic Authentication) or 7 (Meticulous Cryptographic
Authentication). Authentication).
o Auth Len: Length of the Authentication Section. o Auth Len: The length of the Authentication Section.
o Auth Key ID: The Key ID of the authentication key used for this o Auth Key ID: The Key ID of the authentication key used for this
packet, enabling multiple keys to be active simultaneously. packet, enabling multiple keys to be active simultaneously.
o Sequence Number: A 64-bit sequence number that is used to prevent o Sequence Number: A 64-bit sequence number that is used to prevent
replay attacks. For Cryptographic Authentication this value is replay attacks. For Cryptographic Authentication this value is
incremented occasionally. For Meticulous Cryptographic incremented occasionally. For Meticulous Cryptographic
Authentication, this value is incremented for each successive Authentication, this value is incremented for each successive
packet transmitted for a session. packet transmitted for a session.
o Authentication Data: This field carries the digest computed by o Authentication Data: This field carries the digest computed by
whatever Cryptographic Authentication algorithm is being used to whatever Cryptographic Authentication algorithm is being used to
authenticate the BFD control packet. authenticate the BFD control packet.
3.3. Procedures at the Sending Side 3.3. Procedures at the Sending Side
Before a BFD device sends a BFD packet out, the device needs to Before a BFD device sends a BFD packet out, the device needs to
select an appropriate BFD SA from its local key table if a keyed select an appropriate BFD SA from its local key database if a keyed
digest for the packet is required. If no appropriate SA is digest for the packet is required. If no appropriate SA is
available, the BFD packet MUST be discarded. available, the BFD packet MUST be discarded.
If an appropriate SA is available, the device then derives the key If an appropriate SA is available, the device then derives the key
and the associated authentication algorithm from the SA. and the associated authentication algorithm from the SA.
The device sets the Authentication Present (A) bit in the packet The device sets the Authentication Present (A) bit in the packet
header. header.
The device MUST fill the Auth Type and the Auth length before the The device MUST fill the Auth Type and the Auth Len fields before the
authentication data is computed. The Sequence Number field MUST be authentication data is computed. The Sequence Number field MUST be
set to bfd.XmitAuthSeq. set to bfd.XmitAuthSeq.
The Auth length in the Authentication section is set as per the The Auth Len field in the Authentication section is set as per the
authentication algorithm that is being used. authentication algorithm that is being used.
The Key ID is filled. The Key ID field is filled.
The computation of the digest is performed. The computing process The computation of the digest is performed. The computing process
can be various when different algorithms are adopted and is out of can be various when different algorithms are adopted and is out of
the scope of this document. the scope of this document.
The generated digest is placed in the Authentication data, following The generated digest is placed in the Authentication Data field.
the Key ID.
3.4. Procedure at the Receiving Side 3.4. Procedure at the Receiving Side
When a BFD Control packet is received, the following procedure MUST When a BFD Control packet is received, the following procedure MUST
be followed, in the order specified. be followed, in the order specified.
If the Authentication Present (A) bit is set in the packet header and If the Authentication Present (A) bit is set in the packet header and
the receiver will try to find a appropriate BFD SA in its local key the receiver will try to find a appropriate BFD SA in its local key
table to process the packet. The BFD SA is identified by the Key ID table to process the packet. The BFD SA is identified by the Key ID
in the Authentication Section of the incoming BFD packet. field in the Authentication Section of the incoming BFD packet.
If the Auth Key ID field does not match the ID of any configured If the Auth Key ID field does not match the ID of any configured
authentication key or the associated key is not in its valid period, authentication key or the associated key is not in its valid period,
the received packet MUST be discarded. the received packet MUST be discarded.
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Cryptographic Authentication, if the Sequence Number lies outside of Cryptographic Authentication, if the Sequence Number lies outside of
the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult)
inclusive (when treated as an unsigned 32 bit circular number space), inclusive (when treated as an unsigned 32 bit circular number space),
the received packet MUST be discarded. For Meticulous Cryptographic the received packet MUST be discarded. For Meticulous Cryptographic
skipping to change at page 8, line 6 skipping to change at page 8, line 4
Cryptographic Authentication, if the Sequence Number lies outside of Cryptographic Authentication, if the Sequence Number lies outside of
the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult)
inclusive (when treated as an unsigned 32 bit circular number space), inclusive (when treated as an unsigned 32 bit circular number space),
the received packet MUST be discarded. For Meticulous Cryptographic the received packet MUST be discarded. For Meticulous Cryptographic
Authentication, if the Sequence Number lies outside of the range of Authentication, if the Sequence Number lies outside of the range of
bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32 bit circular number space, the received treated as an unsigned 32 bit circular number space, the received
packet MUST be discarded. packet MUST be discarded.
The device then prepares for generating a digest of the packet. The device then prepares for generating a digest of the packet.
First of all, the authentication data in the Authentication Value First of all, the authentication data in the Authentication Value
field needs to be saved somewhere else. Then the Authentication field needs to be saved somewhere else. Then the Authentication
Value field is set with a certain value (which may be various in Value field is set with a pre-specified value (which may be various
different security algorithms) according the authentication algorithm in different security algorithms) according the authentication
indicated in the SA. After this, the device starts performing the algorithm indicated in the SA. After this, the device starts
digest generating operations. The work of defining actual digest performing the digest generating operations. The work of defining
generating operations is out of the scope of this document. actual digest generating operations is out of the scope of this
document.
The calculated data is compared with the received authentication data The calculated data is compared with the received authentication data
in the packet and the packet MUST be discarded if the two do not in the packet and the packet MUST be discarded if the two do not
match. In such a case, an error event SHOULD be logged. match. In such a case, an error event SHOULD be logged.
An implementation MAY have a transition mode where it includes An implementation MAY have a transition mode where it includes
CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but
does not verify this information. This is provided as a transition does not verify this information. This is provided as a transition
aid for networks in the process of migrating to the new CRYPTO_AUTH aid for networks in the process of migrating to the new CRYPTO_AUTH
and MET_CRYPTO_AUTH based authentication schemes. and MET_CRYPTO_AUTH based authentication schemes.
3.5. Key Selection for BFD Packet Transmission 3.5. Key Selection for BFD Packet Transmission
This section describes how the proposed security solution selects In [I-D.ietf-karp-crypto-key-table], a conceptual key database called
long-lived keys from key tables [I-D.ietf-karp-crypto-key-table]. "key table" is introduce. A key table is located in the middle of
Generally, a key used for BFD packet authentication should satisfy key management protocols and security protocols so that a security
the following requirements: protocol can derive long-term keys from the key table but does not
have to know the details of key management. This section describes
how the proposed security solution selects long-lived keys from key
tables [I-D.ietf-karp-crypto-key-table].
o The key time period as defined by Not Before Time and Not After Assume that a device R1 tries to send a unicast BFD packet from its
Time must include the current time. interface I1 to the interface R2 of a remote device R2 at time T.
Because the key should be shared by the by both R1 and R2 to protect
the communication between I1 and I2, R1 needs to provide a protocol
("BFD"), an interface identifier (I1) and a peer identifier (R2) into
the key selection function. Any key that satisfies the following
conditions may be selected:
o The key can be used for the desired security algorithm. o The Peer field includes the device ID of R2.
In the remainder of this section, additional requirements for keys o the Protocol field matches "BFD"
are enumerated. Assume that a device R1 tries to send a unicast BFD
packet from its interface I1 to the interface R2 of a remote device
R2 at time T. Because the key should be shared by the by both R1 and
R2 to protect the communication between I1 and I2, the key should
satisfy the following requirements:
o The Peer field includes the device ID of R2. o The PeerKeyName field is not "unknown".
o The PeerKeyID field is not "unknown". o The Interface field includes I1 or "all".
o The Interfaces field includes I1. o The Direction field is either "out" or "both".
o SendNotBefore <= current time <= SendNotAfter.
After a set of keys are provided, a BFD implementation should support
selection of keys based on algorithm preference.
Upon R2 receives the BFD packet from R1, R2 provides the protocol
("BFD"), the peer identifier (R1), the key identifier derived from
the incoming packet (L), and the interface (I2) to the key table.
Any key that satisfies the following conditions may be selected:
o The Peer field includes the device ID of R1.
o the Protocol field matches "BFD"
o the LocalKeyName is L
o The Interface field includes I2 or "all".
o The Direction field is either "out" or "both". o The Direction field is either "out" or "both".
o SendNotBefore <= current time <= SendNotAfter.
3.6. Replay Protection using Extended Sequence Numbers 3.6. Replay Protection using Extended Sequence Numbers
As described in Section 1, if the BFD packets in a session are As described in Section 1, if the BFD packets in a session are
transferred with a high frequency, a 32-bit sequence number may reach transferred with a high frequency, a 32-bit sequence number may reach
its maximum and have to roll back before the session finishes. A its maximum and have to roll back before the session finishes. A
attacker thus can replay the packets intercepted before the sequence attacker thus can replay the packets intercepted before the sequence
number wrapped without being detected. To address this problem, the number wrapped without being detected. To address this problem, the
length of the sequence number in the proposed authentication section length of the sequence number in the proposed authentication section
has been extended to 64 bits. After the extension, the sequence has been extended to 64 bits. After the extension, the sequence
number space of a device will not be exhausted within half of a number space of a device will not be exhausted within half of a
skipping to change at page 10, line 21 skipping to change at page 10, line 41
5. Security Considerations 5. Security Considerations
The proposed sequence number extension offers most of the benefits of The proposed sequence number extension offers most of the benefits of
of more complicated mechanisms involving challenges. There are, of more complicated mechanisms involving challenges. There are,
however, a couple drawbacks to this approach. First, it requires the however, a couple drawbacks to this approach. First, it requires the
BFD implementation to be able to save its boot count in non-volatile BFD implementation to be able to save its boot count in non-volatile
storage. If the non-volatile storage is ever repaired or upgraded storage. If the non-volatile storage is ever repaired or upgraded
such that the contents are lost or the BFD device is replaced with a such that the contents are lost or the BFD device is replaced with a
model, the keys MUST be changed to prevent replay attacks. Second, model, the keys MUST be changed to prevent replay attacks. Second,
if a device is taken out of service completely (either intentionally if a device is taken out of service completely (either intentionally
or due to a persistent failure), the potential exists for or due to a persistent failure), the potential exists for re-
reestablishment of a BFD adjacency by replaying the entire BFD establishment of a BFD adjacency by replaying the entire BFD session
session establishment. This scenario is however, extremely unlikely establishment. This scenario is however, extremely unlikely and can
and can be easily avoided. For instance, after recovering from a be easily avoided. For instance, after recovering from a system
system failure, a BFD device has to re-establish BFD sessions. At failure, a BFD device has to re-establish BFD sessions. At this
this stage, if the device randomly selects its discriminators to stage, if the device randomly selects its discriminators to identify
identify new BFD sessions, the possibility of reestablishing a BFD new BFD sessions, the possibility of reestablishing a BFD session by
session by replaying the entire BFD session establishment will be replaying the entire BFD session establishment will be eliminated.
eliminated. For the implementations in which discriminators are not For the implementations in which discriminators are not randomly
randomly selected, this issue can be addressed by integrating the selected, this issue can be largely mitigated by integrating the boot
boot count of the remote BFD router in the generation of the count of the remote BFD router in the generation of the
authentication data for outgoing BFD packets. Of course, this attack authentication data for outgoing BFD packets. Of course, this attack
could also be thwarted by changing the relevant manual keys. could also be thwarted by changing the relevant manual keys.
There is a transition mode suggested where devices can ignore the There is a transition mode suggested where devices can ignore the
CRYPTO_AUTH or the MET_CRYPTO_AUTH information carried in the CRYPTO_AUTH or the MET_CRYPTO_AUTH information carried in the
packets. The operator must ensure that this mode is only used when packets. The operator must ensure that this mode is only used when
migrating to the new CRYPTO_AUTH/MET_CRYPTO_AUTH based authentication migrating to the new CRYPTO_AUTH/MET_CRYPTO_AUTH based authentication
scheme as this leaves the device vulnerable to an attack. scheme as this leaves the device vulnerable to an attack.
6. Acknowledgements 6. Acknowledgements
skipping to change at page 11, line 13 skipping to change at page 11, line 31
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References 7.2. Informative References
[Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996. [Dobb96a] Dobbertin, H., "Cryptanalysis of MD5 Compress", May 1996.
[Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack", [Dobb96b] Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes", 1996. CryptoBytes", 1996.
[I-D.ietf-karp-crypto-key-table] [I-D.ietf-karp-crypto-key-table]
Housley, R. and T. Polk, "Database of Long-Lived Symmetric Housley, R., Polk, T., Hartman, S., and D. Zhang,
Cryptographic Keys", draft-ietf-karp-crypto-key-table-02 "Database of Long-Lived Symmetric Cryptographic Keys",
(work in progress), October 2011. draft-ietf-karp-crypto-key-table-03 (work in progress),
June 2012.
[I-D.ietf-karp-design-guide] [I-D.ietf-karp-design-guide]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", Routing Protocols (KARP) Design Guidelines",
draft-ietf-karp-design-guide-10 (work in progress), draft-ietf-karp-design-guide-10 (work in progress),
December 2011. December 2011.
[MD5-attack] [MD5-attack]
Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for Wang, X., Feng, D., Lai, X., and H. Yu, "Collisions for
Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", Hash Functions MD4, MD5, HAVAL-128 and RIPEMD",
 End of changes. 29 change blocks. 
55 lines changed or deleted 80 lines changed or added

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