base.txt		issue79.txt
	skipping to change at page 45, line 35		skipping to change at page 45, line 35
	as DoS attacks, or compromise of the router, as described in Sections		as DoS attacks, or compromise of the router, as described in Sections
	4.4.2 and 4.4.3 of [24].		4.4.2 and 4.4.3 of [24].
	9.2.5 Replay Attacks		9.2.5 Replay Attacks
	This attack is described in Section 4.3.1 of [24]. SEND protects		This attack is described in Section 4.3.1 of [24]. SEND protects
	against attacks in Router Solicitation/Router Advertisement and		against attacks in Router Solicitation/Router Advertisement and
	Neighbor Solicitation/Neighbor Advertisement transactions by		Neighbor Solicitation/Neighbor Advertisement transactions by
	including a Nonce option in the solicitation and requiring the		including a Nonce option in the solicitation and requiring the
	advertisement to include a matching option. Together with the		advertisement to include a matching option. Together with the
	signatures this forms a challenge-response protocol. SEND protects		signatures this forms a challenge-response protocol.
	against attacks from unsolicited messages such as Neighbor
	Advertisements, Router Advertisements, and Redirects by including a
	Timestamp option. A window of vulnerability for replay attacks
	exists until the timestamp expires.
	When timestamps are used, SEND nodes are protected against replay		SEND protects against attacks from unsolicited messages such as
	attacks as long as they cache the state created by the message		Neighbor Advertisements, Router Advertisements, and Redirects by
	containing the timestamp. The cached state allows the node to		including a Timestamp option. The following security issues are
	protect itself against replayed messages. However, once the node		relevant only for unsolicited messages:
	flushes the state for whatever reason, an attacker can re-create the
	state by replaying an old message while the timestamp is still valid.		o A window of vulnerability for replay attacks exists until the
			timestamp expires.
			However, such vulnerabilities are only useful for attackers if the
			advertised parameters change during the window. While some
			parameters (such as the remaining lifetime of a prefix) change
			often, radical changes typically happen only in the context of
			some special case, such as switching to a new link layer address
			due to a broken interface adapter.
			SEND nodes are also protected against replay attacks as long as
			they cache the state created by the message containing the
			timestamp. The cached state allows the node to protect itself
			against replayed messages. However, once the node flushes the
			state for whatever reason, an attacker can re-create the state by
			replaying an old message while the timestamp is still valid.
	Since most SEND nodes are likely to use fairly coarse grained		Since most SEND nodes are likely to use fairly coarse grained
	timestamps, as explained in Section 5.3.1, this may affect some		timestamps, as explained in Section 5.3.1, this may affect some
	nodes.		nodes.
			o Attacks against time synchronization protocols such as NTP [25]
			may cause SEND nodes to have an incorrect timestamp value. This
			can be used to launch replay attacks even outside the normal
			window of vulnerability. To protect against such attacks, it is
			recommended that SEND nodes keep independently maintained clocks,
			or apply suitable security measures for the time synchronization
			protocols.
	9.2.6 Neighbor Discovery DoS Attack		9.2.6 Neighbor Discovery DoS Attack
	This attack is described in Section 4.3.2 of [24]. In this attack,		This attack is described in Section 4.3.2 of [24]. In this attack,
	the attacker bombards the router with packets for fictitious		the attacker bombards the router with packets for fictitious
	addresses on the link, causing the router to busy itself with		addresses on the link, causing the router to busy itself with
	performing Neighbor Solicitations for addresses that do not exist.		performing Neighbor Solicitations for addresses that do not exist.
	SEND does not address this threat because it can be addressed by		SEND does not address this threat because it can be addressed by
	techniques such as rate limiting Neighbor Solicitations, restricting		techniques such as rate limiting Neighbor Solicitations, restricting
	the amount of state reserved for unresolved solicitations, and clever		the amount of state reserved for unresolved solicitations, and clever
	cache management. These are all techniques involved in implementing		cache management. These are all techniques involved in implementing
	skipping to change at page 53, line 38		skipping to change at page 53, line 38
	June 2002.		June 2002.
	[23] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API		[23] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API
	for Address Selection", draft-chakrabarti-ipv6-addrselect-02		for Address Selection", draft-chakrabarti-ipv6-addrselect-02
	(work in progress), October 2003.		(work in progress), October 2003.
	[24] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor		[24] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
	Discovery trust models and threats", draft-ietf-send-psreq-04		Discovery trust models and threats", draft-ietf-send-psreq-04
	(work in progress), October 2003.		(work in progress), October 2003.
			[25] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth
			Annual Computer Security Conference Proceedings, December 1990.
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	EMail: jari.arkko@ericsson.com		EMail: jari.arkko@ericsson.com
	James Kempf		James Kempf
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/