base.txt		issue31.txt
Skipping to change at page 3, line 28:
11.2.3 Duplicate Address Detection DoS Attack . . . .48		11.2.3 Duplicate Address Detection DoS Attack . . . .48
11.2.4 Router Solicitation and Advertisement Attacks 49		11.2.4 Router Solicitation and Advertisement Attacks 49
11.2.5 Replay Attacks . . . . . . . . . . . . . . . .49		11.2.5 Replay Attacks . . . . . . . . . . . . . . . .49
11.2.6 Neighbor Discovery DoS Attack . . . . . . . .49		11.2.6 Neighbor Discovery DoS Attack . . . . . . . .49
11.3 Attacks against SEND Itself . . . . . . . . . . . . 50		11.3 Attacks against SEND Itself . . . . . . . . . . . . 50
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 51		12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 51
13. IANA Considerations . . . . . . . . . . . . . . . . . . . 52		13. IANA Considerations . . . . . . . . . . . . . . . . . . . 52
Normative References . . . . . . . . . . . . . . . . . . . 53		Normative References . . . . . . . . . . . . . . . . . . . 53
Informative References . . . . . . . . . . . . . . . . . . 54		Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55		Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 56		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 57
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 57		B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 58
C. Cache Management . . . . . . . . . . . . . . . . . . . . . 58		C. Cache Management . . . . . . . . . . . . . . . . . . . . . 59
D. Comparison to AH-Based Approach . . . . . . . . . . . . . 59		D. Comparison to AH-Based Approach . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . 62		Intellectual Property and Copyright Statements . . . . . . 63
1. Introduction		1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC 2461 [7].		IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC 2461 [7].
Nodes on the same link use NDP to discover each other's presence, to		Nodes on the same link use NDP to discover each other's presence, to
determine each other's link-layer addresses, to find routers, and to		determine each other's link-layer addresses, to find routers, and to
maintain reachability information about the paths to active		maintain reachability information about the paths to active
neighbors. NDP is used both by hosts and routers. Its functions		neighbors. NDP is used both by hosts and routers. Its functions
include Neighbor Discovery (ND), Router Discovery (RD), Address		include Neighbor Discovery (ND), Router Discovery (RD), Address
Autoconfiguration, Address Resolution, Neighbor Unreachability		Autoconfiguration, Address Resolution, Neighbor Unreachability
Skipping to change at page 7, line 46:
specified in Section 8 of RFC 2461 [7]. It is similar to the		specified in Section 8 of RFC 2461 [7]. It is similar to the
ICMPv4 Redirect function [15].		ICMPv4 Redirect function [15].
o Address Autoconfiguration is used for automatically assigning		o Address Autoconfiguration is used for automatically assigning
addresses to a host [8]. This allows hosts to operate without		addresses to a host [8]. This allows hosts to operate without
explicit configuration related to IP connectivity. The Address		explicit configuration related to IP connectivity. The Address
Autoconfiguration mechanism defined in [8] is stateless. To		Autoconfiguration mechanism defined in [8] is stateless. To
create IP addresses, the hosts use any prefix information		create IP addresses, the hosts use any prefix information
delivered to them during Router Discovery, and then test the newly		delivered to them during Router Discovery, and then test the newly
formed addresses for uniqueness. A stateful mechanism, DHCPv6		formed addresses for uniqueness. A stateful mechanism, DHCPv6
[24], provides additional Autoconfiguration features.		[25], provides additional Autoconfiguration features.
o Duplicate Address Detection (DAD) is used for preventing address		o Duplicate Address Detection (DAD) is used for preventing address
collisions [8], for instance during Address Autoconfiguration. A		collisions [8], for instance during Address Autoconfiguration. A
node that intends to assign a new address to one of its interfaces		node that intends to assign a new address to one of its interfaces
first runs the DAD procedure to verify that there is no other node		first runs the DAD procedure to verify that there is no other node
using the same address. Since the rules forbid the use of an		using the same address. Since the rules forbid the use of an
address until it has been found unique, no higher layer traffic is		address until it has been found unique, no higher layer traffic is
possible until this procedure has been completed. Thus,		possible until this procedure has been completed. Thus,
preventing attacks against DAD can help ensure the availability of		preventing attacks against DAD can help ensure the availability of
communications for the node in question.		communications for the node in question.
Skipping to change at page 37, line 45:
Upon receiving a message for which the receiver has no certificate		Upon receiving a message for which the receiver has no certificate
chain to a trust anchor, the receiver MAY use Authorization		chain to a trust anchor, the receiver MAY use Authorization
Delegation Discovery to learn the certificate chain of the peer.		Delegation Discovery to learn the certificate chain of the peer.
Nodes that use stateless address autoconfiguration, SHOULD generate a		Nodes that use stateless address autoconfiguration, SHOULD generate a
new CGA as specified in Section 4 of [12] for each new		new CGA as specified in Section 4 of [12] for each new
autoconfiguration run. The nodes MAY continue to use the same public		autoconfiguration run. The nodes MAY continue to use the same public
key and modifier, and start the process from Step 4.		key and modifier, and start the process from Step 4.
		By default, a SEND-enabled node SHOULD use only CGAs as its own
		addresses. Other types of addresses MAY be used in testing,
		diagnostics or other purposes. However, this document does not
		describe how to choose between different types of addresses for
		different communications. A dynamic selection can be provided by an
		API, such as the one defined in [24].
This specification does not address the protection of Neighbor		This specification does not address the protection of Neighbor
Discovery packets for nodes that are configured with a static address		Discovery packets for nodes that are configured with a static address
(e.g., PREFIX::1). Future certificate chain based authorization		(e.g., PREFIX::1). Future certificate chain based authorization
specifications are needed for such nodes.		specifications are needed for such nodes.
It is outside the scope of this specification to describe the use of		It is outside the scope of this specification to describe the use of
trust anchor authorization between nodes with dynamically changing		trust anchor authorization between nodes with dynamically changing
addresses. Such dynamically changing addresses may be the result of		addresses. Such dynamically changing addresses may be the result of
stateful or stateless address autoconfiguration, or through the use		stateful or stateless address autoconfiguration, or through the use
of RFC 3041 [19] addresses. If the CGA method is not used, nodes		of RFC 3041 [19] addresses. If the CGA method is not used, nodes
Skipping to change at page 46, line 21:
frame address and the IPv6 address. On an insecure link layer that		frame address and the IPv6 address. On an insecure link layer that
allows nodes to spoof the link layer address of other nodes, an		allows nodes to spoof the link layer address of other nodes, an
attacker could disrupt IP service by sending out a Neighbor		attacker could disrupt IP service by sending out a Neighbor
Advertisement having the source address on the link layer frame of a		Advertisement having the source address on the link layer frame of a
victim, a valid CGA address and a valid signature corresponding to		victim, a valid CGA address and a valid signature corresponding to
itself, and a Target Link-layer Address extension corresponding to		itself, and a Target Link-layer Address extension corresponding to
the victim. The attacker could then proceed to cause a traffic		the victim. The attacker could then proceed to cause a traffic
stream to bombard the victim in a DoS attack. To protect against		stream to bombard the victim in a DoS attack. To protect against
such attacks, link layer security MUST be used. An example of such		such attacks, link layer security MUST be used. An example of such
for 802 type networks is port-based access control defined in the		for 802 type networks is port-based access control defined in the
802.1X standard [28].		802.1X standard [29].
Specifically, the 802.1X standard provides a mechanism by which a		Specifically, the 802.1X standard provides a mechanism by which a
nodes can be authenticated to a particular point of attachment to a		nodes can be authenticated to a particular point of attachment to a
LAN (called a "port" in the standard). If the MAC on frames sent by		LAN (called a "port" in the standard). If the MAC on frames sent by
a node does not correspond to the MAC of the node originally		a node does not correspond to the MAC of the node originally
authenticated to this port, then the point of attachment drops the		authenticated to this port, then the point of attachment drops the
frames. Authorization to use the port is determined by the MAC		frames. Authorization to use the port is determined by the MAC
address of the node that originally authenticated to the port. The		address of the node that originally authenticated to the port. The
way 802.1X protects against this attack is that, if a node		way 802.1X protects against this attack is that, if a node
authenticated to a particular port attempts to spoof the MAC address		authenticated to a particular port attempts to spoof the MAC address
Skipping to change at page 47, line 20:
Multicast-Address-Specific Query to determine whether any listeners		Multicast-Address-Specific Query to determine whether any listeners
are still on the address, at which point the victim can respond to		are still on the address, at which point the victim can respond to
avoid being dropped from the group. This technique will work if the		avoid being dropped from the group. This technique will work if the
router on the link has not been compromised. Other attacks using MLD		router on the link has not been compromised. Other attacks using MLD
are possible, but they primarily lead to extraneous (but not		are possible, but they primarily lead to extraneous (but not
overwhelming) traffic.		overwhelming) traffic.
11.2 How SEND Counters Threats to Neighbor Discovery		11.2 How SEND Counters Threats to Neighbor Discovery
The SEND protocol is designed to counter the threats to IPv6 Neighbor		The SEND protocol is designed to counter the threats to IPv6 Neighbor
Discovery, as outlined in [26]. The following subsections contain a		Discovery, as outlined in [27]. The following subsections contain a
regression of the SEND protocol against the threats, to illustrate		regression of the SEND protocol against the threats, to illustrate
what aspects of the protocol counter each threat.		what aspects of the protocol counter each threat.
11.2.1 Neighbor Solicitation/Advertisement Spoofing		11.2.1 Neighbor Solicitation/Advertisement Spoofing
This threat is defined in Section 4.1.1 of [26]. The threat is that		This threat is defined in Section 4.1.1 of [27]. The threat is that
a spoofed Neighbor Solicitation or Neighbor Advertisement causes a		a spoofed Neighbor Solicitation or Neighbor Advertisement causes a
false entry in a node's Neighbor Cache. There are two cases:		false entry in a node's Neighbor Cache. There are two cases:
1. Entries made as a side effect of a Neighbor Solicitation or		1. Entries made as a side effect of a Neighbor Solicitation or
Router Solicitation. There are two cases:		Router Solicitation. There are two cases:
1. A router receiving a Router Solicitation with a firm IPv6		1. A router receiving a Router Solicitation with a firm IPv6
source address and a Target Link-Layer Address extension		source address and a Target Link-Layer Address extension
inserts an entry for the IPv6 address into its Neighbor		inserts an entry for the IPv6 address into its Neighbor
Cache.		Cache.
Skipping to change at page 48, line 29:
the node's interface identifier either be a CGA, or that the node be		the node's interface identifier either be a CGA, or that the node be
able to produce a certificate authorizing that node to use the public		able to produce a certificate authorizing that node to use the public
key.		key.
The Neighbor Solicitation and Advertisement pairs implement a		The Neighbor Solicitation and Advertisement pairs implement a
challenge-response protocol, as explained in Section 7 and discussed		challenge-response protocol, as explained in Section 7 and discussed
in Section 11.2.5 below.		in Section 11.2.5 below.
11.2.2 Neighbor Unreachability Detection Failure		11.2.2 Neighbor Unreachability Detection Failure
This attack is described in Section 4.1.2 of [26]. SEND counters		This attack is described in Section 4.1.2 of [27]. SEND counters
this attack by requiring a node responding to Neighbor Solicitations		this attack by requiring a node responding to Neighbor Solicitations
sent as NUD probes to include a Signature option and proof of		sent as NUD probes to include a Signature option and proof of
authorization to use the interface identifier in the address being		authorization to use the interface identifier in the address being
probed. If these prerequisites are not met, the node performing NUD		probed. If these prerequisites are not met, the node performing NUD
discards the responses.		discards the responses.
11.2.3 Duplicate Address Detection DoS Attack		11.2.3 Duplicate Address Detection DoS Attack
This attack is described in Section 4.1.3 of [26]. SEND counters		This attack is described in Section 4.1.3 of [27]. SEND counters
this attack by requiring the Neighbor Advertisements sent as		this attack by requiring the Neighbor Advertisements sent as
responses to DAD to include a Signature option and proof of		responses to DAD to include a Signature option and proof of
authorization to use the interface identifier in the address being		authorization to use the interface identifier in the address being
tested. If these prerequisites are not met, the node performing DAD		tested. If these prerequisites are not met, the node performing DAD
discards the responses.		discards the responses.
When a SEND node is used on a link that also connects to non-SEND		When a SEND node is used on a link that also connects to non-SEND
nodes, the SEND node ignores any insecure Neighbor Solicitations or		nodes, the SEND node ignores any insecure Neighbor Solicitations or
Advertisements that may be send by the non-SEND nodes. This protects		Advertisements that may be send by the non-SEND nodes. This protects
the SEND node from DAD DoS attacks by non-SEND nodes or attackers		the SEND node from DAD DoS attacks by non-SEND nodes or attackers
simulating to non-SEND nodes, at the cost of a potential address		simulating to non-SEND nodes, at the cost of a potential address
collision between a SEND node and non-SEND node. The probability and		collision between a SEND node and non-SEND node. The probability and
effects of such an address collision are discussed in [12].		effects of such an address collision are discussed in [12].
11.2.4 Router Solicitation and Advertisement Attacks		11.2.4 Router Solicitation and Advertisement Attacks
These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,		These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
and 4.2.7 of [26]. SEND counters these attacks by requiring Router		and 4.2.7 of [27]. SEND counters these attacks by requiring Router
Advertisements to contain a Signature option, and that the signature		Advertisements to contain a Signature option, and that the signature
is calculated using the public key of a node that can prove its		is calculated using the public key of a node that can prove its
authorization to route the subnet prefixes contained in any Prefix		authorization to route the subnet prefixes contained in any Prefix
Information Options. The router proves its authorization by showing		Information Options. The router proves its authorization by showing
a certificate containing the specific prefix or the indication that		a certificate containing the specific prefix or the indication that
the router is allowed to route any prefix. A Router Advertisement		the router is allowed to route any prefix. A Router Advertisement
without these protections is dropped.		without these protections is dropped.
SEND does not protect against brute force attacks on the router, such		SEND does not protect against brute force attacks on the router, such
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 [26].		4.4.2 and 4.4.3 of [27].
11.2.5 Replay Attacks		11.2.5 Replay Attacks
This attack is described in Section 4.3.1 of [26]. SEND protects		This attack is described in Section 4.3.1 of [27]. 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. SEND protects
against attacks from unsolicited messages such as Neighbor		against attacks from unsolicited messages such as Neighbor
Advertisements, Router Advertisements, and Redirects by including a		Advertisements, Router Advertisements, and Redirects by including a
Timestamp option. A window of vulnerability for replay attacks		Timestamp option. A window of vulnerability for replay attacks
exists until the timestamp expires.		exists until the timestamp expires.
Skipping to change at page 49, line 46:
containing the timestamp. The cached state allows the node to		containing the timestamp. The cached state allows the node to
protect itself against replayed messages. However, once the node		protect itself against replayed messages. However, once the node
flushes the state for whatever reason, an attacker can re-create the		flushes the state for whatever reason, an attacker can re-create the
state by replaying an old message while the timestamp is still valid.		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.
11.2.6 Neighbor Discovery DoS Attack		11.2.6 Neighbor Discovery DoS Attack
This attack is described in Section 4.3.2 of [26]. In this attack,		This attack is described in Section 4.3.2 of [27]. 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
Neighbor Discovery on the router.		Neighbor Discovery on the router.
11.3 Attacks against SEND Itself		11.3 Attacks against SEND Itself
Skipping to change at page 54, line 38:
Addressing Architecture", RFC 3513, April 2003.		Addressing Architecture", RFC 3513, April 2003.
[22] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",		[22] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
draft-arkko-icmpv6-ike-effects-02 (work in progress), March		draft-arkko-icmpv6-ike-effects-02 (work in progress), March
2003.		2003.
[23] Arkko, J., "Manual SA Configuration for IPv6 Link Local		[23] Arkko, J., "Manual SA Configuration for IPv6 Link Local
Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),		Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
June 2002.		June 2002.
[24] Droms, R., "Dynamic Host Configuration Protocol for IPv6		[24] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API
		for Address Selection", draft-chakrabarti-ipv6-addrselect-02
		(work in progress), October 2003.
		[25] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),		(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002.		November 2002.
[25] Kent, S., "IP Encapsulating Security Payload (ESP)",		[26] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.		draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.
[26] Nikander, P., "IPv6 Neighbor Discovery trust models and		[27] Nikander, P., "IPv6 Neighbor Discovery trust models and
threats", draft-ietf-send-psreq-00 (work in progress), October		threats", draft-ietf-send-psreq-00 (work in progress), October
2002.		2002.
[27] International Organization for Standardization, "The Directory		[28] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000.		- Authentication Framework", ISO Standard X.509, 2000.
[28] Institute of Electrical and Electronics Engineers, "Local and		[29] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",		Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.		IEEE Standard 802.1X, September 2001.
Authors' Addresses		Authors' Addresses
Jari Arkko		Jari Arkko
Ericsson		Ericsson
Jorvas 02420		Jorvas 02420
Finland		Finland
End of changes.
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/