draft-ietf-bfd-base-10.txt		draft-ietf-bfd-base-11.txt
	Network Working Group D. Katz		Network Working Group D. Katz
	Internet Draft Juniper Networks		Internet Draft Juniper Networks
	Intended status: Proposed Standard D. Ward		Intended status: Proposed Standard D. Ward
	Juniper Networks		Juniper Networks
	Expires: July, 2010 January 5, 2010		Expires: July, 2010 January 14, 2010
	Bidirectional Forwarding Detection		Bidirectional Forwarding Detection
	draft-ietf-bfd-base-10.txt		draft-ietf-bfd-base-11.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	6.7.2 Simple Password Authentication . . . . . . . . . . 24		6.7.2 Simple Password Authentication . . . . . . . . . . 24
	6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 25		6.7.3 Keyed MD5 and Meticulous Keyed MD5 Authentication 25
	6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 26		6.7.4 Keyed SHA1 and Meticulous Keyed SHA1 Authentication 26
	6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28		6.8 Functional Specifics . . . . . . . . . . . . . . . . . . 28
	6.8.1 State Variables . . . . . . . . . . . . . . . . . 29		6.8.1 State Variables . . . . . . . . . . . . . . . . . 29
	6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32		6.8.2 Timer Negotiation . . . . . . . . . . . . . . . . 32
	6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32		6.8.3 Timer Manipulation . . . . . . . . . . . . . . . . 32
	6.8.4 Calculating the Detection Time . . . . . . . . . . 34		6.8.4 Calculating the Detection Time . . . . . . . . . . 34
	6.8.5 Detecting Failures with the Echo Function . . . . 35		6.8.5 Detecting Failures with the Echo Function . . . . 35
	6.8.6 Reception of BFD Control Packets . . . . . . . . . 35		6.8.6 Reception of BFD Control Packets . . . . . . . . . 35
	6.8.7 Transmitting BFD Control Packets . . . . . . . . . 37		6.8.7 Transmitting BFD Control Packets . . . . . . . . . 38
	6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 41		6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 41
	6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 41		6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 41
	6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 41		6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 42
	6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 42		6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 42
	6.8.12 Detect Multiplier Change . . . . . . . . . . . . 42		6.8.12 Detect Multiplier Change . . . . . . . . . . . . 42
	6.8.13 Enabling or Disabling the Echo Function . . . . . 42		6.8.13 Enabling or Disabling the Echo Function . . . . . 42
	6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 42		6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 42
	6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 42		6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 43
	6.8.16 Administrative Control . . . . . . . . . . . . . 43		6.8.16 Administrative Control . . . . . . . . . . . . . 43
	6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43		6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 43
	6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 44		6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 44
	7. Operational Considerations . . . . . . . . . . . . . . . . . 45		7. Operational Considerations . . . . . . . . . . . . . . . . . 45
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
	9. Security Considerations . . . . . . . . . . . . . . . . . . 47		9. Security Considerations . . . . . . . . . . . . . . . . . . 47
	10. References . . . . . . . . . . . . . . . . . . . . . . . . 48		10. References . . . . . . . . . . . . . . . . . . . . . . . . 49
	10.1 Normative References . . . . . . . . . . . . . . . . . 48		10.1 Normative References . . . . . . . . . . . . . . . . . 49
	10.2 Informative References . . . . . . . . . . . . . . . . 49		10.2 Informative References . . . . . . . . . . . . . . . . 49
	Backward Compatibility (Non-Normative) . . . . . . . . . . . . 49		Backward Compatibility (Non-Normative) . . . . . . . . . . . . 49
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 50		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 51
	Changes from the previous draft . . . . . . . . . . . . . . . . 51		Changes from the previous draft . . . . . . . . . . . . . . . . 51
	1. Introduction		1. Introduction
	An increasingly important feature of networking equipment is the		An increasingly important feature of networking equipment is the
	rapid detection of communication failures between adjacent systems,		rapid detection of communication failures between adjacent systems,
	in order to more quickly establish alternative paths. Detection can		in order to more quickly establish alternative paths. Detection can
	come fairly quickly in certain circumstances when data link hardware		come fairly quickly in certain circumstances when data link hardware
	comes into play (such as SONET alarms.) However, there are media		comes into play (such as SONET alarms.) However, there are media
	that do not provide this kind of signaling (such as Ethernet), and		that do not provide this kind of signaling (such as Ethernet), and
	skipping to change at page 14, line 21		skipping to change at page 14, line 21
	The Sequence Number for this packet. For Keyed MD5		The Sequence Number for this packet. For Keyed MD5
	Authentication, this value is incremented occasionally. For		Authentication, this value is incremented occasionally. For
	Meticulous Keyed MD5 Authentication, this value is incremented for		Meticulous Keyed MD5 Authentication, this value is incremented for
	each successive packet transmitted for a session. This provides		each successive packet transmitted for a session. This provides
	protection against replay attacks.		protection against replay attacks.
	Auth Key/Digest		Auth Key/Digest
	This field carries the 16 byte MD5 digest for the packet. When		This field carries the 16 byte MD5 digest for the packet. When
	the digest is calculated, the shared MD5 key is stored in this		the digest is calculated, the shared MD5 key is stored in this
	field. The shared key MUST be encoded and configured to section		field, padded to 16 bytes with trailing zero bytes if needed. The
	6.7.3. The shared key MUST be 16 bytes in length.		shared key MUST be encoded and configured to section 6.7.3.
	4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format		4.4. Keyed SHA1 and Meticulous Keyed SHA1 Authentication Section Format
	If the Authentication Present (A) bit is set in the header, and the		If the Authentication Present (A) bit is set in the header, and the
	Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous		Authentication Type field contains 4 (Keyed SHA1) or 5 (Meticulous
	Keyed SHA1), the Authentication Section has the following format:		Keyed SHA1), 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 30		skipping to change at page 15, line 30
	The Sequence Number for this packet. For Keyed SHA1		The Sequence Number for this packet. For Keyed SHA1
	Authentication, this value is incremented occasionally. For		Authentication, this value is incremented occasionally. For
	Meticulous Keyed SHA1 Authentication, this value is incremented		Meticulous Keyed SHA1 Authentication, this value is incremented
	for each successive packet transmitted for a session. This		for each successive packet transmitted for a session. This
	provides protection against replay attacks.		provides protection against replay attacks.
	Auth Key/Hash		Auth Key/Hash
	This field carries the 20 byte SHA1 hash for the packet. When the		This field carries the 20 byte SHA1 hash for the packet. When the
	hash is calculated, the shared SHA1 key is stored in this field.		hash is calculated, the shared SHA1 key is stored in this field,
			padded to a length of 20 bytes with trailing zero bytes if needed.
	The shared key MUST be encoded and configured to section 6.7.4.		The shared key MUST be encoded and configured to section 6.7.4.
	The shared key MUST be 20 bytes in length.
	5. BFD Echo Packet Format		5. BFD Echo Packet Format
	BFD Echo packets are sent in an encapsulation appropriate to the		BFD Echo packets are sent in an encapsulation appropriate to the
	environment. See the appropriate application documents for the		environment. See the appropriate application documents for the
	specifics of particular environments.		specifics of particular environments.
	The payload of a BFD Echo packet is a local matter, since only the		The payload of a BFD Echo packet is a local matter, since only the
	sending system ever processes the content. The only requirement is		sending system ever processes the content. The only requirement is
	that sufficient information is included to demultiplex the received		that sufficient information is included to demultiplex the received
	skipping to change at page 24, line 24		skipping to change at page 24, line 25
	Transmission Using Simple Password Authentication		Transmission Using Simple Password Authentication
	The currently selected password and Key ID for the session MUST be		The currently selected password and Key ID for the session MUST be
	stored in the Authentication Section of each outgoing BFD Control		stored in the Authentication Section of each outgoing BFD Control
	packet. The Auth Type field MUST be set to 1 (Simple Password.)		packet. The Auth Type field MUST be set to 1 (Simple Password.)
	The Auth Len field MUST be set to the proper length (4 to 19		The Auth Len field MUST be set to the proper length (4 to 19
	bytes).		bytes).
	The password is a binary string, and MUST be 1 to 16 bytes in		The password is a binary string, and MUST be 1 to 16 bytes in
	length. All implementations MUST support the configuration of any		length. For interoperability, the management interface by which
	arbitrary binary string to ensure interoperability. Other		the password is configured MUST accept ASCII strings, and SHOULD
	configuration methods MAY be supported.		also allow for the configuration of any arbitrary binary string in
			hexadecimal form. Other configuration methods MAY be supported.
	Reception Using Simple Password Authentication		Reception Using Simple Password Authentication
	If the received BFD Control packet does not contain an		If the received BFD Control packet does not contain an
	Authentication Section, or the Auth Type is not 1 (Simple		Authentication Section, or the Auth Type is not 1 (Simple
	Password), then the received packet MUST be discarded.		Password), then the received packet MUST be discarded.
	If the Auth Key ID field does not match the ID of a configured		If the Auth Key ID field does not match the ID of a configured
	password, the received packet MUST be discarded.		password, the received packet MUST be discarded.
	skipping to change at page 25, line 31		skipping to change at page 25, line 31
	or strictly greater than the last sequence number received (for		or strictly greater than the last sequence number received (for
	Meticulous Keyed MD5.)		Meticulous Keyed MD5.)
	Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication		Transmission Using Keyed MD5 and Meticulous Keyed MD5 Authentication
	The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous		The Auth Type field MUST be set to 2 (Keyed MD5) or 3 (Meticulous
	Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key		Keyed MD5.) The Auth Len field MUST be set to 24. The Auth Key
	ID field MUST be set to the ID of the current authentication key.		ID field MUST be set to the ID of the current authentication key.
	The Sequence Number field MUST be set to bfd.XmitAuthSeq.		The Sequence Number field MUST be set to bfd.XmitAuthSeq.
	The authentication key value is a binary string of 16 bytes, and		The authentication key value is a binary string of up to 16 bytes,
	MUST be placed into the Auth Key/Digest field. All		and MUST be placed into the Auth Key/Digest field, padded with
	implementations MUST support the configuration of any arbitrary		trailing zero bytes as necessary. For interoperability, the
	binary string to ensure interoperability. Other configuration		management interface by which the key is configured MUST accept
			ASCII strings, and SHOULD also allow for the configuration of any
			arbitrary binary string in hexadecimal form. Other configuration
	methods MAY be supported.		methods MAY be supported.
	An MD5 digest MUST be calculated over the entire BFD control		An MD5 digest MUST be calculated over the entire BFD control
	packet. The resulting digest MUST be stored in the Auth		packet. The resulting digest MUST be stored in the Auth
	Key/Digest field prior to transmission (replacing the secret key,		Key/Digest field prior to transmission (replacing the secret key,
	which MUST NOT be carried in the packet.)		which MUST NOT be carried in the packet.)
	For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular		For Keyed MD5, bfd.XmitAuthSeq MAY be incremented in a circular
	fashion (when treated as an unsigned 32 bit value.)		fashion (when treated as an unsigned 32 bit value.)
	bfd.XmitAuthSeq SHOULD be incremented when the session state		bfd.XmitAuthSeq SHOULD be incremented when the session state
	skipping to change at page 27, line 22		skipping to change at page 27, line 23
	Meticulous Keyed SHA1.)		Meticulous Keyed SHA1.)
	Transmission Using Keyed SHA1 and Meticulous Keyed SHA1		Transmission Using Keyed SHA1 and Meticulous Keyed SHA1
	Authentication		Authentication
	The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous		The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous
	Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key		Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key
	ID field MUST be set to the ID of the current authentication key.		ID field MUST be set to the ID of the current authentication key.
	The Sequence Number field MUST be set to bfd.XmitAuthSeq.		The Sequence Number field MUST be set to bfd.XmitAuthSeq.
	The authentication key value is a binary string of 20 bytes, and		The authentication key value is a binary string of up to 20 bytes,
	MUST be placed into the Auth Key/Hash field. All implementations		and MUST be placed into the Auth Key/Hash field, padding with
	MUST support the configuration of any arbitrary binary string to		trailing zero bytes as necessary. For interoperability, the
	ensure interoperability. Other configuration methods MAY be		management interface by which the key is configured MUST accept
	supported.		ASCII strings, and SHOULD also allow for the configuration of any
			arbitrary binary string in hexadecimal form. Other configuration
			methods MAY be supported.
	A SHA1 hash MUST be calculated over the entire BFD control packet.		A SHA1 hash MUST be calculated over the entire BFD control packet.
	The resulting hash MUST be stored in the Auth Key/Hash field prior		The resulting hash MUST be stored in the Auth Key/Hash field prior
	to transmission (replacing the secret key, which MUST NOT be		to transmission (replacing the secret key, which MUST NOT be
	carried in the packet.)		carried in the packet.)
	For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular		For Keyed SHA1, bfd.XmitAuthSeq MAY be incremented in a circular
	fashion (when treated as an unsigned 32 bit value.)		fashion (when treated as an unsigned 32 bit value.)
	bfd.XmitAuthSeq SHOULD be incremented when the session state		bfd.XmitAuthSeq SHOULD be incremented when the session state
	changes, or when the transmitted BFD Control packet carries		changes, or when the transmitted BFD Control packet carries
	skipping to change at page 48, line 29		skipping to change at page 48, line 29
	read [HMAC] and its references.		read [HMAC] and its references.
	If both systems randomize their Local Discriminator values at the		If both systems randomize their Local Discriminator values at the
	beginning of a session, replay attacks may be further mitigated,		beginning of a session, replay attacks may be further mitigated,
	regardless of the authentication type in use. Since the Local		regardless of the authentication type in use. Since the Local
	Discriminator may be changed at any time during a session, this		Discriminator may be changed at any time during a session, this
	mechanism may also help mitigate attacks.		mechanism may also help mitigate attacks.
	The security implications of the use of BFD Echo packets are		The security implications of the use of BFD Echo packets are
	dependent on how those packets are defined, since their structure is		dependent on how those packets are defined, since their structure is
	local to the transmittiong system and outside the scope of this		local to the transmitting system and outside the scope of this
	specification. The risks are essentially the same as those of BFD		specification. However, since Echo packets are defined and processed
	Control packets. [GTSM] could be applied in this case, though the		only by the transmitting system, the use of cryptographic
			authentication does not guarantee that the other system is actually
			alive; an attacker could loop the Echo packets back (without knowing
			any secret keys) and cause the link to be falsely declared to be up.
			This can be mitigated by using a suitable interval for BFD Control
			packets. [GTSM] could be applied to BFD Echo packets, though the
	TTL/Hop Count will be decremented by 1 in the course of echoing the		TTL/Hop Count will be decremented by 1 in the course of echoing the
	packet, so spoofing is possible from one hop away. The use of		packet, so spoofing is possible from one hop away.
	cryptographic authentication can mitigate the risk of spoofing.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism		[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
	(GTSM)", RFC 5082, October 2007.		(GTSM)", RFC 5082, October 2007.
	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	skipping to change at page 51, line 7		skipping to change at page 51, line 23
	Dave Ward		Dave Ward
	Juniper Networks		Juniper Networks
	1194 N. Mathilda Ave.		1194 N. Mathilda Ave.
	Sunnyvale, California 94089-1206 USA		Sunnyvale, California 94089-1206 USA
	Phone: +1-408-745-2000		Phone: +1-408-745-2000
	Email: dward@juniper.net		Email: dward@juniper.net
	Changes from the Previous Draft		Changes from the Previous Draft
	The primary technical change is to make the jitter of transmitted		The definition and configuration of passwords and authentication keys
	packets a MUST rather than a SHOULD, in order to make congestion		was changed slightly to improve interoperability with deployed code.
	detection possible. More comprehensive text on congestion control		The security considerations for the Echo protocol was changed
	was added. Configuration requirements for passwords and secret keys		slightly.
	was clarified. Text describing packet transmission was consolidated.
	The minimal required authentication was clarified. The requirement		All other changes are purely editorial in nature.
	to maintain state after a BFD session failure was clarified. The
	Security Considerations section was expanded. All other changes are
	purely editorial in nature.
	This document expires in July, 2010.		This document expires in July, 2010.
End of changes. 16 change blocks.
	38 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/