base.txt		issue33.txt
Skipping to change at page 3, line 15:
8.2.1 Sending Secure Router Advertisements . . . . .40		8.2.1 Sending Secure Router Advertisements . . . . .40
8.2.2 Receiving Secure Router Advertisements . . . .40		8.2.2 Receiving Secure Router Advertisements . . . .40
8.3 Redirect Messages . . . . . . . . . . . . . . . . . 40		8.3 Redirect Messages . . . . . . . . . . . . . . . . . 40
8.3.1 Sending Redirects . . . . . . . . . . . . . .41		8.3.1 Sending Redirects . . . . . . . . . . . . . .41
8.3.2 Receiving Redirects . . . . . . . . . . . . .41		8.3.2 Receiving Redirects . . . . . . . . . . . . .41
8.4 Other Requirements . . . . . . . . . . . . . . . . . 41		8.4 Other Requirements . . . . . . . . . . . . . . . . . 41
9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 43		9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 43
10. Performance Considerations . . . . . . . . . . . . . . . . 45		10. Performance Considerations . . . . . . . . . . . . . . . . 45
11. Security Considerations . . . . . . . . . . . . . . . . . 46		11. Security Considerations . . . . . . . . . . . . . . . . . 46
11.1 Threats to the Local Link Not Covered by SEND . . . 46		11.1 Threats to the Local Link Not Covered by SEND . . . 46
11.2 How SEND Counters Threats to Neighbor Discovery . . 47		11.2 How SEND Counters Threats to Neighbor Discovery . . 46
11.2.1 Neighbor Solicitation/Advertisement Spoofing .47		11.2.1 Neighbor Solicitation/Advertisement Spoofing .47
11.2.2 Neighbor Unreachability Detection Failure . .48		11.2.2 Neighbor Unreachability Detection Failure . .48
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 48
11.2.5 Replay Attacks . . . . . . . . . . . . . . . .49		11.2.5 Replay Attacks . . . . . . . . . . . . . . . .48
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 . . . . . . . . . . . . 49
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 . . . . . . . . . . . . . . . . . . . . . . . 57		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 57
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 58		B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 58
C. Cache Management . . . . . . . . . . . . . . . . . . . . . 59		C. Cache Management . . . . . . . . . . . . . . . . . . . . . 59
D. Comparison to AH-Based Approach . . . . . . . . . . . . . 60		D. Comparison to AH-Based Approach . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . 63		Intellectual Property and Copyright Statements . . . . . . 63
Skipping to change at page 46, line 9:
Signatures can be precomputed for unsolicited (multicast) Neighbor		Signatures can be precomputed for unsolicited (multicast) Neighbor
and Router Advertisements. Typically, solicited advertisements are		and Router Advertisements. Typically, solicited advertisements are
sent to the unicast address from which the solicitation was sent.		sent to the unicast address from which the solicitation was sent.
Given that the IPv6 header is covered by the signature, it is not		Given that the IPv6 header is covered by the signature, it is not
possible to precompute solicited-for advertisements.		possible to precompute solicited-for advertisements.
11. Security Considerations		11. Security Considerations
11.1 Threats to the Local Link Not Covered by SEND		11.1 Threats to the Local Link Not Covered by SEND
SEND does not compensate for an insecure link layer. In particular,		SEND does not compensate for an insecure link layer. For instance,
there is no cryptographic binding in SEND between the link layer		there is no assurance that payload packets actually come from the
		same peer that the Neighbor Discovery protocol was run against.
		SEND does not provide confidentiality for Neighbor Discovery
		communications.
		There may be no cryptographic binding in SEND between the link layer
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 SHOULD be used.
for 802 type networks is port-based access control defined in the
802.1X standard [29].
Specifically, the 802.1X standard provides a mechanism by which 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
a node does not correspond to the MAC of the node originally
authenticated to this port, then the point of attachment drops the
frames. Authorization to use the port is determined by the MAC
address of the node that originally authenticated to the port. The
way 802.1X protects against this attack is that, if a node
authenticated to a particular port attempts to spoof the MAC address
of another node, the port will drop the frames. Naturally, this
requires that all ports by which nodes can attach to the LAN use
802.1X authentication, and that all node physically attach through a
port, as is the case with 802.3 switched LAN. For shared media, such
as multiple nodes authenticated through the same 802.11 AP (which
acts as a single port for all nodes), other measures are necessary,
since an attacker on the wireless link can spoof the MAC address of a
victim on the same wireless link.
802.1X does not provide protection for the layer 2 frame - layer 3		Even on a secure link layer, SEND does not require that the addresses
packet address binding in traffic (that is, real time filtering to		on the link layer and Neighbor Advertisements correspond to each
check this binding), and neither does SEND. 802.1X provides		other. However, it is RECOMMENDED that such checks be performed
authentication and filtering of MAC address to port; SEND provides		where this is possible on the given link layer technology.
protection for the layer 2 - layer 3 binding information in the
Neighbor Discovery packet, via the CGA address (authorization to use
the address via the public key) and the signature on the packet
(authentication of contents as from authorized IP address possessor).
Prior to participating in Neighbor Discovery and Duplicate Address		Prior to participating in Neighbor Discovery and Duplicate Address
Detection, nodes must subscribe to the link-scoped All-Nodes		Detection, nodes must subscribe to the link-scoped All-Nodes
Multicast Group and the Solicited-Node Multicast Group for the		Multicast Group and the Solicited-Node Multicast Group for the
address that they are claiming for their addresses; RFC 2461 [7].		address that they are claiming for their addresses; RFC 2461 [7].
Subscribing to a multicast group requires that the nodes use MLD		Subscribing to a multicast group requires that the nodes use MLD
[18]. MLD contains no provision for security. An attacker could		[18]. MLD contains no provision for security. An attacker could
send an MLD Done message to unsubscribe a victim from the		send an MLD Done message to unsubscribe a victim from the
Solicited-Node Multicast address. However, the victim should be able		Solicited-Node Multicast address. However, the victim should be able
to detect such an attack because the router sends a		to detect such an attack because the router sends a
End of changes.
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/