draft-ietf-bfd-generic-crypto-auth-05.txt		draft-ietf-bfd-generic-crypto-auth-06.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: April 18, 2014 Hewlett-Packard Co.		Expires: October 19, 2014 Hewlett-Packard Co.
	D. Zhang		D. Zhang
	Huawei		Huawei
	October 15, 2013		M. Jethanandani
			Ciena Corporation
			April 17, 2014
	BFD Generic Cryptographic Authentication		BFD Generic Cryptographic Authentication
	draft-ietf-bfd-generic-crypto-auth-05		draft-ietf-bfd-generic-crypto-auth-06
	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 arbitary cryptographic		Detection (BFD) to allow the use of arbitrary cryptographic
	authentication algorithms in addition to the already-documented		authentication algorithms in addition to the already-documented
	authentication schemes described in the base specification. This		authentication schemes described in the base specification. This
	document adds the basic infrastructure that is required for		document adds the basic infrastructure that is required for
	supporting algorithm and key agility for BFD.		supporting algorithm and key agility for BFD.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	skipping to change at page 1, line 44		skipping to change at page 1, line 46
	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 April 18, 2014.		This Internet-Draft will expire on October 19, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 28		skipping to change at page 2, line 33
	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 . . . . . . . . . . . . . . 5		3.2. Authentication Section Format . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The base specification of bidirectional Forwarding Detection (BFD)		The base specification of Bidirectional Forwarding Detection
	[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 plain text. An
	with physical access to the network can easily eavesdrop on the		attacker with physical access to the network can easily eavesdrop on
	password and compromise the security of the BFD packet exchanges. In		the password and compromise the security of the BFD packet exchanges.
	Keyed MD5 and Meticulous Keyed MD5, the BFD devices on the both sides		In Keyed MD5 and Meticulous Keyed MD5, the BFD devices on the both
	of a BFD session share a secret key which is used to generate a keyed		sides of a BFD session share a secret key which is used to generate a
	MD5 digest for each packet, and a monotonically increasing sequence		keyed MD5 digest for each packet, and a monotonically increasing
	number scheme is used to prevent replay attacks. Keyed SHA-1 and		sequence number scheme is used to prevent replay attacks. Keyed
	Meticulous SHA-1 modes are similar to MD5, and it uses SHA-1 instead		SHA-1 and Meticulous SHA-1 modes are similar to MD5, and it uses
	of MD5 to generate a digest for each packet.		SHA-1 instead of MD5 to generate a digest for each packet.
	A concern with existing authentication schemes of BFD is that the
	security strength of the cryptographic algorithms adopted in the
	schemes is relatively weak. Both the MD5 algorithm and the SHA-1
	algorithm are known to be vulnerable to collision attacks. In
	[MD5-attack] and [Dobb96a, Dobb96b], several methods of generating		The security strength of the cryptographic algorithms adopted in the
	hash collisions for some applications of MD5 are proposed. Similar		authentication schemes are relatively weak. Both the MD5 algorithm
	security vulnerabilities of SHA-1 are introduced in [SHA-1-attack1]		and the SHA-1 algorithm are known to be vulnerable to collision
	and [SHA-1-attack2]. It is therefore desired that BFD must support		attacks. In MD5-attack [MD5-attack] and Dobb96a [Dobb96a], Dobb96b
	newer algorithms that have not yet been broken. Additionally, the		[Dobb96b], several methods of generating hash collisions for some
	transition mechanism from one algorithm to the other must be		applications of MD5 are proposed. Similar security vulnerabilities
	seamless.		of SHA-1 are introduced in SHA-1-attack1 [SHA-1-attack1] and
			SHA-1-attack2 [SHA-1-attack2]. It is therefore desired that BFD must
			support newer algorithms that have not yet been broken.
			Additionally, the transition mechanism from one algorithm to the
			other must be seamless.
	The other issue with the existing authentication schemes is the		The other issue with the existing authentication schemes is the
	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.
	skipping to change at page 4, line 7		skipping to change at page 4, line 4
	not tied to any particular authentication algorithm or 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 enhanced to improve its		The packet replay mechanism has also been enhanced 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 security		It should be noted that this document attempts to fix the security
	issues raised by the manual key management procedure that currently		issues raised by the manual key management procedure that currently
	exists within BFD, as part of the Phase One described in KARP-design-		exists within BFD, as part of the Phase One described in KARP Design
	guide [I-D.ietf-karp-design-guide]. Therefore, only the pre-shared		Guidelines [RFC6518]. Therefore, only the pre-shared keys is
	keys is considered in this document. However, the solution described		considered in this document. However, the solution described in this
	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.
	The parameters associated with a BFD SA are listed as follows:		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
	be sent in plaintext over the wire.		never be sent in plain text over the wire.
	o Authentication Key : This indicates the cryptographic key
	associated with this BFD SA. The length of this key is variable and
	depends upon the authentication algorithm specified by the BFD SA.
	Operators MUST ensure that this is never sent over the network in
	clear-text via any protocol. Care should also be taken to ensure
	that the selected key is unpredictable, avoiding any keys known to be
	weak for the algorithm in use. [RFC4086] contains helpful
	information on both key generation techniques and cryptographic
	randomness.
	o Authentication Key Identifier (Key ID) : This is a two octet		o Authentication Key : This indicates the cryptographic key
	unsigned integer used to uniquely identify the BFD SA. This ID could		associated with this BFD SA. The length of this key is variable
	be manually configured by the network operator (or, in the future,		and depends upon the authentication algorithm specified by the BFD
	possibly by some key management protocol specified by the IETF). The		SA. Operators MUST ensure that this is never sent over the
	receiver determines the active SA by looking at this field in the		network in clear-text via any protocol. Care should also be taken
	incoming packet. The sender puts this Key ID in the BFD packet based		to ensure that the selected key is unpredictable, avoiding any
	on the active configuration. Using Key IDs makes changing keys while		keys known to be weak for the algorithm in use. Randomness
	maintaining protocol operation convenient. Normally, an		Requirements for Security [RFC4086] contains helpful information
	implementation would allow the network operator to configure a set of		on both key generation techniques and cryptographic randomness.
	keys in a key chain, with each key in the chain having fixed
	lifetime. The actual operation of these mechanisms is outside the
	scope of this document.
	A key ID indicates a tuple of an authentication key and an associated		o Authentication Key Identifier (Key ID) : This is a two octet
	authentication algorithm. If a key is expected to be applied with		unsigned integer used to uniquely identify the BFD SA. This ID
	different algorithms, different Key IDs must be used to identify the		could be manually configured by the network operator (or, in the
	associations of the key with its authentication algorithms		future, possibly by some key management protocol specified by the
	respectively. However, the application of a key for different		IETF). The receiver determines the active SA by looking at this
	purposes must be very careful, since it may make an adversary easier		field in the incoming packet. The sender puts this Key ID in the
	to collect more material to compromise the key.		BFD packet based on the active configuration. Using Key IDs makes
			changing keys while maintaining protocol operation convenient.
			Normally, an implementation would allow the network operator to
			configure a set of keys in a key chain, with each key in the chain
			having fixed lifetime. The actual operation of these mechanisms
			is outside the scope of this document. A key ID indicates a tuple
			of an authentication key and an associated authentication
			algorithm. If a key is expected to be applied with different
			algorithms, different Key IDs must be used to identify the
			associations of the key with its authentication algorithms
			respectively. However, the application of a key for different
			purposes must be very careful, since it may make an adversary
			easier to collect more material to compromise the key.
	o Not Before Time : The time point before which the key should not be		o Not Before Time : The time point before which the key should not
	used.		be used.
	o Not After Time : The time point after which the key should not be		o Not After Time : The time point after which the key should not be
	used.		used.
	3. Authentication Procedures		3. Authentication Procedures
	In the proposed authentication extension, an optional authentication		In the proposed authentication extension, an optional authentication
	section (Generic Authentication Section) and two authentication types		section (Generic Authentication Section) and two authentication types
	(Generic Cryptographic Authentication and Generic Meticulous		(Generic Cryptographic Authentication and Generic Meticulous
	Cryptographic Authentication) are specified.		Cryptographic Authentication) are specified.
	3.1. Authentication Types		3.1. Authentication Types
	The Authentication section is only present in a BFD packet if the		The Authentication section is only present in a BFD packet if the
	Authentication Present (A) bit is set in the packet header. The Auth		Authentication Present (A) bit is set in the packet header. The Auth
	Type in the Authentication section is set to 6 when Generic		Type in the Authentication section is set to TBD1 when Generic
	Cryptographic Authentication is in use, while it is set to 7 when		Cryptographic Authentication is in use, while it is set to TBD2 when
	Generic Meticulous Cryptographic Authentication is in use.		Generic Meticulous Cryptographic Authentication is in use.
	Both the authentication types use a monotonically increasing sequence		Both the authentication types use a monotonically increasing sequence
	number to protect the BFD session against reply attacks. The only		number to protect the BFD session against reply attacks. The only
	difference between the two types is that the sequence number is		difference between the two types is that the sequence number is
	occasionally incremented in the Cryptographic Authentication mode, as		occasionally incremented in the Cryptographic Authentication mode, as
	against the Meticulous Cryptographic Authentication mode, where it is		against the Meticulous Cryptographic Authentication mode, where it is
	incremented on every packet.		incremented on every packet.
	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, TBD1 or TBD2, 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 is 6 (Generic Cryptographic		header and the Authentication Type field is TBD1 (Generic
	Authentication) or 7 (Generic Meticulous Cryptographic		Cryptographic Authentication) or TBD2 (Generic Meticulous
	Authentication), the Authentication Section has the following format:		Cryptographic 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 TBD1
	(Cryptographic Authentication) or 7 (Meticulous Cryptographic		(Cryptographic Authentication) or TBD2 (Meticulous Cryptographic
	Authentication).		Authentication).
	o Auth Len: The 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
	skipping to change at page 6, line 47		skipping to change at page 7, line 5
	select an appropriate BFD SA from its local key database 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 Len fields before the		The device MUST fill the Auth Type, the Auth Len fields and the
	authentication data is computed. The Sequence Number field MUST be		Sequence Number field to bfd.XmitAuthSeq before the authentication
	set to bfd.XmitAuthSeq.		data is computed.
	The Auth Len field 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 field 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 field.		The generated digest is placed in the Authentication Data field.
	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 Auth Type is TBD1 or TBD2, the receiver is to find an appropriate
	table to process the packet. The BFD SA is identified by the Key ID		BFD SA in its local key table to process the packet. The BFD SA is
	field in the Authentication Section of the incoming BFD packet.		identified by the Key ID 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 64 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 64 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 pre-specified value (which may be various		Value field is set with a pre-specified value (which may be various
	in different security algorithms) according the authentication		in different security algorithms) according the authentication
	algorithm indicated in the SA. After this, the device starts		algorithm indicated in the SA. After this, the device starts
	performing the digest generating operations. The work of defining		performing the digest generating operations. The work of defining
	actual digest generating operations is out of the scope of this		actual digest generating operations is out of the scope of this
	skipping to change at page 8, line 14		skipping to change at page 8, line 20
	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
	In [I-D.ietf-karp-crypto-key-table], a conceptual key database called		In [I-D.ietf-karp-crypto-key-table], a conceptual key database called
	"key table" is introduce. A key table is located in the middle of		"key table" is introduced. A key table is located in the middle of
	key management protocols and security protocols so that a security		key management protocols and security protocols so that a security
	protocol can derive long-term keys from the key table but does not		protocol can derive long-term keys from the key table but does not
	have to know the details of key management. This section describes		have to know the details of key management. This section describes
	how the proposed security solution selects long-lived keys from key		how the proposed security solution selects long-lived keys from key
	tables [I-D.ietf-karp-crypto-key-table].		tables [I-D.ietf-karp-crypto-key-table].
	Assume that a device R1 tries to send a unicast BFD packet from its		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.		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		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		the communication between I1 and I2, R1 needs to provide a protocol
	("BFD"), an interface identifier (I1) and a peer identifier (R2) into		("BFD"), an interface identifier (I1) and a peer identifier (R2) into
	the key selection function. Any key that satisfies the following		the key selection function. Any key that satisfies the following
	conditions may be selected:		conditions may be selected:
	o The Peer field includes the device ID of R2.		o The Peer field includes the device ID of R2.
	o the Protocol field matches "BFD"		o The Protocol field matches "BFD"
	o The PeerKeyName field is not "unknown".		o The PeerKeyName field is not "unknown".
	o The Interface field includes I1 or "all".		o The Interface field includes I1 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.		o SendNotBefore <= current time <= SendNotAfter.
	After a set of keys are provided, a BFD implementation should support		After a set of keys are provided, a BFD implementation should support
	selection of keys based on algorithm preference.		selection of keys based on algorithm preference.
	Upon R2 receives the BFD packet from R1, R2 provides the protocol		Upon reception of a BFD packet from R1, R2 provides the protocol
	("BFD"), the peer identifier (R1), the key identifier derived from		("BFD"), the peer identifier (R1), the key identifier derived from
	the incoming packet (L), and the interface (I2) to the key table.		the incoming packet (L), and the interface (I2) to the key table.
	Any key that satisfies the following conditions may be selected:		Any key that satisfies the following conditions may be selected:
	o The Peer field includes the device ID of R1.		o The Peer field includes the device ID of R1.
	o the Protocol field matches "BFD"		o The Protocol field matches "BFD"
	o the LocalKeyName is L
			o The LocalKeyName is L
	o The Interface field includes I2 or "all".		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.		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 for half of a million
	million years even if the device sends out a BFD packet in every		years even if the device sends out a BFD packet in every micro-
	micro-second. Therefore, the replay attack risks caused by the		second. Therefore, the replay attack risks caused by the limited
	limited sequence number space can be largely addressed. However, in		sequence number space can be largely addressed. However, in Generic
	Generic Cryptographic Authentication, the sequence number is only		Cryptographic Authentication, the sequence number is only required to
	required to increase occasionally. Therefore, a replayed packet may		increase occasionally. Therefore, a replayed packet may be regarded
	be regarded as a legal one until the packet with a larger sequence		as a legal one until the packet with a larger sequence number is
	number is received. This type of intra-session replay attack cannot		received. This type of intra-session replay attack cannot be
	be addressed only by extending the length of sequence numbers.		addressed only by extending the length of sequence numbers.
	An anti-replay solution for BFD also needs to consider the scenarios		An anti-replay solution for BFD also needs to consider the scenarios
	where a BFD device loses its prior sequence number state (e.g.,		where a BFD device loses its prior sequence number state (e.g.,
	system crash, loss of power). In such cases, a BFD device has to re-		system crash, loss of power). In such cases, a BFD device has to re-
	initialize its sequence number. Taking this opportunity, an attacker		initialize its sequence number. Otherwise, an attacker may be able
	may be able to replay the antique packets intercepted in previous		to replay a previously intercepted without being detected.
	sessions without being detected.
	To address this problem, in the proposed solution, the most		To address this problem, in the proposed solution, the most
	significant 32-bit value of the sequence number is used to contain a		significant 32-bit value of the sequence number is used to contain a
	boot count, and the remainder 32-bit value is used as an ordinary		boot count, and the remainder 32-bit value is used as an ordinary
	32-bit monotonically increasing sequence number. In Generic		32-bit monotonically increasing sequence number. In Generic
	Cryptographic Authentication, the remainder 32-bit value is required		Cryptographic Authentication, the remainder 32-bit value is required
	to increase occasionally, while in Generic Meticulous Cryptographic		to increase occasionally, while in Generic Meticulous Cryptographic
	Authentication, the lower order 32-bit sequence number MUST be		Authentication, the lower order 32-bit sequence number MUST be
	incremented for every BFD packet sent by a BFD device. The BFD		incremented for every BFD packet sent by a BFD device. The BFD
	implementations are required to retain the boot count in non-volatile		implementations are required to retain the boot count in non-volatile
	skipping to change at page 10, line 12		skipping to change at page 10, line 18
	used for this purpose. However, maintaining a separate boot count		used for this purpose. However, maintaining a separate boot count
	solely for BFD sequence numbers has the advantage of decoupling SNMP		solely for BFD sequence numbers has the advantage of decoupling SNMP
	re-initialization and BFD re-initialization. Also, in the rare event		re-initialization and BFD re-initialization. Also, in the rare event
	that the lower order 32- bit sequence number wraps, the boot count		that the lower order 32- bit sequence number wraps, the boot count
	can be incremented to preserve the strictly increasing property of		can be incremented to preserve the strictly increasing property of
	the aggregate sequence number. Hence, a separate BFD boot count is		the aggregate sequence number. Hence, a separate BFD boot count is
	RECOMMENDED.		RECOMMENDED.
	4. IANA Considerations		4. IANA Considerations
	This document currently defines a value of 6 to be used to denote		IANA is requested to assign two authentication types from the "BFD
	Cryptographic Authentication mechanism for authenticating BFD control		Authentication Types" sub-registry within the "Bidirectional
	packets and 7 for Meticulous Cryptographic Authentication.		Forwarding Detection (BFD) Parameters" registry.
			+---------+-----------------------------------------+---------------+
			| Address | BFD Authentication Type Name | Reference |
			+---------+-----------------------------------------+---------------+
			| TBD1 | Cryptographic Authentication | This document |
			| TBD2 | Meticulous Cryptographic Authentication | This document |
			+---------+-----------------------------------------+---------------+
	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,		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.
	BFD implementation to be able to save its boot count in non-volatile
	storage. If the non-volatile storage is ever repaired or upgraded		First, it requires the BFD implementation to be able to save its boot
	such that the contents are lost or the BFD device is replaced with a		count in non-volatile storage. If the non-volatile storage is ever
	model, the keys MUST be changed to prevent replay attacks. Second,		repaired or upgraded such that the contents are lost or the BFD
	if a device is taken out of service completely (either intentionally		device is replaced with a model, the keys MUST be changed to prevent
	or due to a persistent failure), the potential exists for re-		replay attacks.
	establishment of a BFD adjacency by replaying the entire BFD session
	establishment. This scenario is however, extremely unlikely and can		Second, if a device is taken out of service completely (either
	be easily avoided. For instance, after recovering from a system		intentionally or due to a persistent failure), the potential exists
	failure, a BFD device has to re-establish BFD sessions. At this		for re-establishment of a BFD adjacency by replaying the entire BFD
	stage, if the device randomly selects its discriminators to identify		session establishment. This scenario is however, extremely unlikely
	new BFD sessions, the possibility of reestablishing a BFD session by		and can be easily avoided. For instance, after recovering from a
	replaying the entire BFD session establishment will be eliminated.		system failure, a BFD device has to re-establish BFD sessions. At
	For the implementations in which discriminators are not randomly		this stage, if the device randomly selects its discriminators to
	selected, this issue can be largely mitigated by integrating the boot		identify new BFD sessions, the possibility of re-establishing a BFD
	count of the remote BFD router in the generation of the		session by replaying the entire BFD session establishment will be
			eliminated. For the implementations in which discriminators are not
			randomly selected, this issue can be largely mitigated by integrating
			the boot 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
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
			(BFD)", RFC 5880, June 2010.
	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., Polk, T., Hartman, S., and D. Zhang,		Housley, R., Polk, T., Hartman, S., and D. Zhang,
	"Database of Long-Lived Symmetric Cryptographic Keys",		"Database of Long-Lived Symmetric Cryptographic Keys",
	draft-ietf-karp-crypto-key-table-08 (work in progress),		draft-ietf-karp-crypto-key-table-10 (work in progress),
	July 2013.		December 2013.
	[I-D.ietf-karp-design-guide]
	Lebovitz, G. and M. Bhatia, "Keying and Authentication for
	Routing Protocols (KARP) Design Guidelines", draft-ietf-
	karp-design-guide-10 (work in progress), 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", August		Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August
	2004.		2004.
	[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.		April 1992.
	[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness		[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	Requirements for Security", BCP 106, RFC 4086, June 2005.		Requirements for Security", BCP 106, RFC 4086, June 2005.
	[RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF		[RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF
	Version 2 Packets and Congestion Avoidance", BCP 112, RFC		Version 2 Packets and Congestion Avoidance", BCP 112, RFC
	4222, October 2005.		4222, October 2005.
	[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
	(BFD)", RFC 5880, June 2010.		Routing Protocols (KARP) Design Guidelines", RFC 6518,
			February 2012.
	[SHA-1-attack1]		[SHA-1-attack1]
	Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the		Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
	Full SHA-1", 2005.		Full SHA-1", 2005.
	[SHA-1-attack2]		[SHA-1-attack2]
	Wang, X., Yao, A., and F. Yao, "New Collision Search for		Wang, X., Yao, A., and F. Yao, "New Collision Search for
	SHA-1", 2005.		SHA-1", 2005.
	Authors' Addresses		Authors' Addresses
	skipping to change at line 546		skipping to change at page 13, line 4
	USA		USA
	Email: vishwas.manral@hp.com		Email: vishwas.manral@hp.com
	Dacheng Zhang		Dacheng Zhang
	Huawei		Huawei
	Beijing		Beijing
	China		China
	Email: zhangdacheng@huawei.com		Email: zhangdacheng@huawei.com
			Mahesh Jethanandani
			Ciena Corporation
			3939 North 1st Street
			San Jose, CA 95110
			USA
			Phone: +1 (408) 904-2160
			Fax: +1 (408) 944-9290
			Email: mjethanandani@gmail.com
End of changes. 36 change blocks.
	135 lines changed or deleted		146 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/