draft-ietf-bfd-optimizing-authentication-05.txt		draft-ietf-bfd-optimizing-authentication-06.txt
	Network Working Group M. Jethanandani		Network Working Group M. Jethanandani
	Internet-Draft		Internet-Draft VMware
	Intended status: Standards Track A. Mishra		Intended status: Standards Track A. Mishra
	Expires: November 26, 2018 SES Networks		Expires: April 14, 2019 SES Networks
	A. Saxena		A. Saxena
	Ciena Corporation		Ciena Corporation
	M. Bhatia		M. Bhatia
	Nokia		Nokia
	May 25, 2018		October 11, 2018
	Optimizing BFD Authentication		Optimizing BFD Authentication
	draft-ietf-bfd-optimizing-authentication-05		draft-ietf-bfd-optimizing-authentication-06
	Abstract		Abstract
	This document describes an optimization to BFD Authentication as		This document describes an optimization to BFD Authentication as
	described in Section 6.7 of BFD RFC5880.		described in Section 6.7 of BFD RFC5880.
	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
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 November 26, 2018.		This Internet-Draft will expire on April 14, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 3, line 6 ¶		skipping to change at page 3, line 6 ¶
	authenticating every packet even more difficult to achieve.		authenticating every packet even more difficult to achieve.
	This document proposes that only BFD frames that signal a state		This document proposes that only BFD frames that signal a state
	change in BFD be authenticated. Rest of the frames can be		change in BFD be authenticated. Rest of the frames can be
	transmitted and received without authentication enabled. Most frames		transmitted and received without authentication enabled. Most frames
	that are transmitted and received have no state change associated		that are transmitted and received have no state change associated
	with them. Limiting authentication to frames that affect a BFD		with them. Limiting authentication to frames that affect a BFD
	session state allows more sessions to be supported for		session state allows more sessions to be supported for
	authentication. Moreover, most BFD frames that signal a state change		authentication. Moreover, most BFD frames that signal a state change
	are generally transmitted at a slower interval of 1s leaving enough		are generally transmitted at a slower interval of 1s leaving enough
	time to compute the hash.		time to compute the hash. To detect a Man In the Middle (MITM)
			attack, it is also proposed that a non-state change frame be
			authenticated occasionally. The interval of this non-state change
			frame can be configured depending on the detect multiplier and the
			capability of the system. As an example, this could be equal to the
			detect multiplier number of packets.
	Section 2 talks about the changes to authentication mode as described		The rest of the document is structured as follows. Section 2 talks
	in BFD [RFC5880].		about the changes to authentication mode as described in BFD
			[RFC5880]. Section 3 goes into the details of the new Authentication
			TLV.
	2. Authentication Mode		2. Authentication Mode
	The cryptographic authentication mechanisms specified in BFD		The cryptographic authentication mechanisms specified in BFD
	[RFC5880] describes enabling and disabling of authentication as a one		[RFC5880] describes enabling and disabling of authentication as a one
	time operation. As a security precaution, it mentions that		time operation. As a security precaution, it mentions that
	authentication state be allowed to change at most once. Once		authentication state be allowed to change at most once. Once
	enabled, every packet must have Authentication Bit set and the		enabled, every packet must have Authentication Bit set and the
	associated Authentication TLV appended. In addition, it states that		associated Authentication TLV appended. In addition, it states that
	an implementation SHOULD NOT allow the authentication state to be		an implementation SHOULD NOT allow the authentication state to be
	changed based on the receipt of a BFD Control packet.		changed based on the receipt of a BFD Control packet.
	This document proposes that the authentication mode be modified to be		This document proposes that the authentication mode be modified to be
	enabled on demand. Instead of authenticating every packet, BFD peers		enabled on demand. Instead of authenticating every packet, BFD peers
	decide which frames need to be authenticated, and authenticate only		are configured for which frames need to be authenticated, and
	those frames. For example, the two ends can decide that BFD frames		authenticate only those frames. Rest of the frames can be
	that indicate a state change should be authenticated and enable		transmitted and received without authentication. For example, the
	authentication on those frames only. If the two ends have not		two ends can be configured such that BFD frames that indicate a state
	previously negotiated which frames they will transmit or receive with		change should be authenticated and enable authentication on those
	authentication enabled, then the BFD session will fail to come up,		frames only. If the two ends have previously been configured as
	because at least one end will expect every frame to be authenticated.		such, but at least one side decides not to authenticate a state
			change frame, then the BFD session will fail to come up.
			This proposal outlines which frames need to be authenticated (carry
			the A-bit), and which frames can be transmitted or received without
			authentication enabled. A frame that fails authentication is
			discarded, or a frame that was supposed to be authenticated, but was
			not, e.g. a state-change frame, is discarded. However, there is no
			change to the state machine for BFD, as the decision of a state
			change is still decided by how many valid consecutive frames were
			received, authenticated or otherwise.
	The state changes for which authentication is being suggested		The state changes for which authentication is being suggested
	include:		include:
	Read : On state change from <column> to <row>		Read : On state change from <column> to <row>
	Auth : Authenticate frame		Auth : Authenticate frame
	NULL : No Authentication. Use NULL AUTH TLV.		NULL : No Authentication. Use NULL AUTH TLV.
	n/a : Invalid state transition.		n/a : Invalid state transition.
	Select : Most frames NULL AUTH. Selective (periodic)		Select : Most frames NULL AUTH. Selective (periodic)
	frames authenticated.		frames authenticated.
	+--------+--------+--------+--------+--------+--------+		+--------+--------+--------+--------+--------+--------+
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 38 ¶
	MUST contain the TLV specified in Section 3. This enables a		MUST contain the TLV specified in Section 3. This enables a
	monotonically increasing sequence number to be carried in each frame,		monotonically increasing sequence number to be carried in each frame,
	and prevents man-in-the-middle from capturing and replaying the same		and prevents man-in-the-middle from capturing and replaying the same
	frame again. Since all frames still carry a sequence number, the		frame again. Since all frames still carry a sequence number, the
	logic for sequence number maintenance remains unchanged from		logic for sequence number maintenance remains unchanged from
	[RFC5880]. If at a later time, a different scheme is adopted for		[RFC5880]. If at a later time, a different scheme is adopted for
	changing sequence number, this method can use the updated scheme		changing sequence number, this method can use the updated scheme
	without any impact.		without any impact.
	Most frames transmitted on a BFD session are BFD CC UP frames.		Most frames transmitted on a BFD session are BFD CC UP frames.
	Authenticating a small subset of these frames (one per configured		Authenticating a small subset of these frames, for example, a detect
	period) significantly reduces the computational demand for the system		multiplier number of packets per configured period, significantly
	while maintaining security of the session across the configured		reduces the computational demand for the system while maintaining
	authentication periods. The configuration of the periodic		security of the session across the configured authentication periods.
	authentication interval for BFD CC UP frames is an open issue.		The configuration of the periodic authentication interval for BFD CC
			UP frames is an open issue, left for implementations to decide.
	3. NULL Auth TLV		3. NULL Auth TLV
	This section describes a new Authentication TLV as:		This section describes a new Authentication TLV as:
	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 | Reserved |		| Auth Type | Auth Len | Auth Key ID | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	NULL Auth TLV		NULL Auth TLV
	where:		where:
	Auth Type: The Authentication Type, which in this case is 0 (NULL		Auth Type: The Authentication Type, which in this case is TBD (NULL
	Auth TL)		Auth TLV, to be assigned by IANA)
	Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes		Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes
	Auth Key ID: The authentication key ID in use for this packet. Must		Auth Key ID: The authentication key ID in use for this packet. Must
	be set to zero.		be set to zero.
	Reserved: The authentication key ID in use for this packet. This		Reserved: This byte MUST be set to zero on transmit and ignored on
	allows multiple keys to be active simultaneously.		receive.
	Sequence Number: The sequence number for this packet. Implementation		Sequence Number: The sequence number for this packet. Implementation
	may use sequence numbers as defined in [RFC5880], or secure sequence		may use sequence numbers as defined in [RFC5880], or secure sequence
	numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers].		numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers].
	The NULL Auth TLV must be used for all frames that are not		The NULL Auth TLV must be used for all frames that are not
	authenticated. This protects against replay-attacks by allowing the		authenticated. This protects against replay-attacks by allowing the
	session to maintain an incrementing sequence number for all frames		session to maintain an incrementing sequence number for all frames
	(authenticated and un-authenticated).		(authenticated and un-authenticated).
	In the future, if a new scheme is adopted for changing the sequence		In the future, if a new scheme is adopted for changing the sequence
	number, this method can adopt the new scheme without any impact.		number, this method can adopt the new scheme without any impact.
	4. IANA Considerations		4. IANA Considerations
	This document requests an update to the registry titled "BFD		This document requests an update to the registry titled "BFD
	Authentication Types". IANA is requested to update the Value of 0		Authentication Types". IANA is requested to to assign a new BFD Auth
	which is currently named as Reserved to NULL (see Section 3).		Type for "NULL Auth TLV" (see Section 3).
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	5. Security Considerations		5. Security Considerations
	The approach described in this document enhances the ability to		The approach described in this document enhances the ability to
	authentication a BFD session by taking away the onerous requirement		authentication a BFD session by taking away the onerous requirement
	that every frame be authenticated. By authenticating frames that		that every frame be authenticated. By authenticating frames that
	affect the state of the session, the security of the BFD session is		affect the state of the session, the security of the BFD session is
	maintained. As such this document does not change the security		maintained. As such this document does not change the security
	considerations for BFD.		considerations for BFD.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-bfd-secure-sequence-numbers]		[I-D.ietf-bfd-secure-sequence-numbers]
	Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and		Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and
	A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd-		A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd-
	secure-sequence-numbers-01 (work in progress), November		secure-sequence-numbers-02 (work in progress), May 2018.
	2017.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	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
	Mahesh Jethanandani		Mahesh Jethanandani
			VMware
	USA		USA
	Email: mjethanandani@gmail.com		Email: mjethanandani@gmail.com
	Ashesh Mishra		Ashesh Mishra
	SES Networks		SES Networks
	Email: mishra.ashesh@gmail.com		Email: mishra.ashesh@gmail.com
	Ankur Saxena		Ankur Saxena
End of changes. 14 change blocks.
	28 lines changed or deleted		47 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/