draft-ietf-bfd-optimizing-authentication-01.txt		draft-ietf-bfd-optimizing-authentication-02.txt
	Network Working Group M. Jethanandani		Network Working Group M. Jethanandani
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track A. Mishra		Intended status: Standards Track A. Mishra
	Expires: August 18, 2016 A. Saxena		Expires: July 9, 2017 A. Saxena
	Ciena Corporation		Ciena Corporation
	M. Bhatia		M. Bhatia
	Ionos Networks		Ionos Networks
	February 15, 2016		January 5, 2017
	Optimizing BFD Authentication		Optimizing BFD Authentication
	draft-ietf-bfd-optimizing-authentication-01		draft-ietf-bfd-optimizing-authentication-02
	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 41 ¶		skipping to change at page 1, line 41 ¶
	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 August 18, 2016.		This Internet-Draft will expire on July 9, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	+--------+--------+--------+--------+--------+--------+		+--------+--------+--------+--------+--------+--------+
	Optimized Authentication Map		Optimized Authentication Map
	All frames already carry the sequence number. The NULL AUTH frames		All frames already carry the sequence number. The NULL AUTH frames
	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].		[RFC5880]. If at a later time, a different scheme is adopted for
			changing sequence number, this method can use the updated scheme
			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 (one per configured
	period) significantly reduces the computational demand for the system		period) significantly reduces the computational demand for the system
	while maintaining security of the session across the configured		while maintaining security of the session across the configured
	authentication periods. The configuration of the periodic		authentication periods. The configuration of the periodic
	authentication interval for BFD CC UP frames is an open issue.		authentication interval for BFD CC UP frames is an open issue.
	3. NULL Auth TLV		3. NULL Auth TLV
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 7 ¶
	Sequence Number: The sequence number for this packet. This value is		Sequence Number: The sequence number for this packet. This value is
	incremented for each successive packet transmitted for a session.		incremented for each successive packet transmitted for a session.
	This provides protection against replay attacks. Must use the same		This provides protection against replay attacks. Must use the same
	sequence number counter as the authenticated frames.		sequence number counter as the authenticated frames.
	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
			number, this method can adopt the new scheme without any impact.
	4. IANA Considerations		4. IANA Considerations
	IANA is requested to assign a new Auth Type for the NULL Auth TLV.		This document requests an update to the registry titled "BFD
			Authentication Types". IANA is requested to update the Value of 0
			which is currently named as Reserved to NULL (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
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 45 ¶
	(HMAC)", August 2002.		(HMAC)", August 2002.
	[FIPS-198]		[FIPS-198]
	National Institute of Standards and Technology, FIPS PUB		National Institute of Standards and Technology, FIPS PUB
	198, "The Keyed-Hash Message Authentication Code (HMAC)",		198, "The Keyed-Hash Message Authentication Code (HMAC)",
	March 2002.		March 2002.
	[I-D.ashesh-bfd-stability]		[I-D.ashesh-bfd-stability]
	Mishra, A., Jethanandani, M., Saxena, A., Networks, J.,		Mishra, A., Jethanandani, M., Saxena, A., Networks, J.,
	Chen, M., and P. Fan, "BFD Stability", draft-ashesh-bfd-		Chen, M., and P. Fan, "BFD Stability", draft-ashesh-bfd-
	stability-03 (work in progress), June 2015.		stability-04 (work in progress), March 2016.
	[I-D.ietf-bfd-generic-crypto-auth]		[I-D.ietf-bfd-generic-crypto-auth]
	Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani,		Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani,
	"BFD Generic Cryptographic Authentication", draft-ietf-		"BFD Generic Cryptographic Authentication", draft-ietf-
	bfd-generic-crypto-auth-06 (work in progress), April 2014.		bfd-generic-crypto-auth-06 (work in progress), April 2014.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 8, line 25 ¶		skipping to change at page 8, line 34 ¶
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: ankurpsaxena@gmail.com		Email: ankurpsaxena@gmail.com
	Manav Bhatia		Manav Bhatia
	Ionos Networks		Ionos Networks
	Bangalore		Bangalore
	India		India
	Email: manav@ionosnetworks.com		Email: manavbhatia@gmail.com
End of changes. 10 change blocks.
	8 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/