< draft-ietf-karp-bfd-analysis-00.txt		draft-ietf-karp-bfd-analysis-01.txt >
	Network Working Group M.B. Bhatia		Network Working Group M. Bhatia
	Internet-Draft Alcatel-Lucent		Internet-Draft Alcatel-Lucent
	Intended status: Informational D. Zhang		Intended status: Informational D. Zhang
	Expires: September 13, 2013 Huawei Technologies co., LTD.		Expires: March 14, 2014 Huawei Technologies co., LTD.
	M.J. Jethanandani		M. Jethanandani
	Ciena Corporation		Ciena Corporation
	March 12, 2013		September 10, 2013
	Analysis of Bidirectional Forwarding Detection (BFD) Security According		Analysis of Bidirectional Forwarding Detection (BFD) Security According
	to KARP Design Guide		to KARP Design Guide
	draft-ietf-karp-bfd-analysis-00		draft-ietf-karp-bfd-analysis-01
	Abstract		Abstract
	This document analyzes the Bidirectional Forwarding Detection		This document analyzes the Bidirectional Forwarding Detection
	protocol (BFD) according to the guidelines set forth in section 4.2		protocol (BFD) according to the guidelines set forth in section 4.2
	of KARP Design Guidelines [RFC6518].		of KARP Design Guidelines [RFC6518].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 September 13, 2013.		This Internet-Draft will expire on March 14, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 6, line 47 ¶		skipping to change at page 6, line 47 ¶
	detected. However, it does require that the two stations exchanging		detected. However, it does require that the two stations exchanging
	BFD packets are synchorizied with respect to time. Alternatively,		BFD packets are synchorizied with respect to time. Alternatively,
	the sequence number can be a nonce number generated using the shared		the sequence number can be a nonce number generated using the shared
	key. But nonce numbers will also run out in 24 weeks.		key. But nonce numbers will also run out in 24 weeks.
	Increasing the sequence number space to 64 bits makes the wrap around		Increasing the sequence number space to 64 bits makes the wrap around
	time be a little less than 2 million years. Combined with nonce or		time be a little less than 2 million years. Combined with nonce or
	part of the number reflecting real time would make replay attacks		part of the number reflecting real time would make replay attacks
	difficult if not impossible.		difficult if not impossible.
			The security risks brought by SHA-1 and MD5 have been well
			understood. However, when using stronger digest algorithm, e.g.,
			SHA-2, the imposed computing overhead will seriously affect the
			performance of BFD implementation. In order to make the trade-off
			between the strong algorithm requirement and the imposed overhead,
			Galois Message Authentication Code (GMAC) can be a candidate option.
			This algorithm is relative effective and has been supported by IPsec
			for data origin authentication. More detailed information can be
			found in [RFC4543].
	7. IANA Considerations		7. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	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.
	8. Security Considerations		8. Security Considerations
	9. Acknowledgements		9. Acknowledgements
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 45 ¶
	[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues		[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
	with Existing Cryptographic Protection Methods for Routing		with Existing Cryptographic Protection Methods for Routing
	Protocols", RFC 6039, October 2010.		Protocols", RFC 6039, October 2010.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-bfd-generic-crypto-auth]		[I-D.ietf-bfd-generic-crypto-auth]
	Bhatia, M., Manral, V., and D. Zhang, "BFD Generic		Bhatia, M., Manral, V., and D. Zhang, "BFD Generic
	Cryptographic Authentication", draft-ietf-bfd-generic-		Cryptographic Authentication", draft-ietf-bfd-generic-
	crypto-auth-03 (work in progress), October 2012.		crypto-auth-04 (work in progress), April 2013.
	[I-D.ietf-bfd-hmac-sha]		[I-D.ietf-bfd-hmac-sha]
	Zhang, D., Bhatia, M., and V. Manral, "Authenticating BFD		Zhang, D., Bhatia, M., and V. Manral, "Authenticating BFD
	using HMAC-SHA-2 procedures", draft-ietf-bfd-hmac-sha-02		using HMAC-SHA-2 procedures", draft-ietf-bfd-hmac-sha-03
	(work in progress), October 2012.		(work in progress), April 2013.
	[I-D.ietf-karp-threats-reqs]		[I-D.ietf-karp-threats-reqs]
	Lebovitz, G., Bhatia, M., and B. Weis, "Keying and		Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
	Authentication for Routing Protocols (KARP) Overview,		Authentication for Routing Protocols (KARP) Overview,
	Threats, and Requirements", draft-ietf-karp-threats-		Threats, and Requirements", draft-ietf-karp-threats-
	reqs-07 (work in progress), December 2012.		reqs-07 (work in progress), December 2012.
			[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
			Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
			May 2006.
	[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic		[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
	Authentication", RFC 4822, February 2007.		Authentication", RFC 4822, February 2007.
	[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,		[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
	and M. Fanto, "IS-IS Generic Cryptographic		and M. Fanto, "IS-IS Generic Cryptographic
	Authentication", RFC 5310, February 2009.		Authentication", RFC 5310, February 2009.
	[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,		[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
	Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic		Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
	Authentication", RFC 5709, October 2009.		Authentication", RFC 5709, October 2009.
End of changes. 9 change blocks.
	9 lines changed or deleted		24 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/