attempting to generate an address for that interface.
When performing Duplicate Address Detection for the first
tentative address, the node accepts both secured and unsecured
Neighbor Advertisements and Solicitations received in response to
the Neighbor Solicitations. When performing Duplicate Address
Detection for the second or third tentative address, it ignores
unsecured Neighbor Advertisements and Solicitations. (The
security implications of this are discussed in Section 9.2.3 and
in [11].)
o The node MAY have a configuration option whereby it ignores
unsecured advertisements, even when performing Duplicate Address
Detection for the first tentative address. This configuration
option SHOULD be disabled by default. This is a recovery
mechanism for cases in which attacks against the first address
become common.
o The Neighbor Cache, Prefix List, and Default Router list entries
MUST have a secured/unsecured flag that indicates whether the
message that caused the creation or last update of the entry was
secured or unsecured. Received unsecured messages MUST NOT cause
changes to existing secured entries in the Neighbor Cache, Prefix
List, or Default Router List. Received secured messages MUST
cause an update of the matching entries, which MUST be flagged as
secured.
o Neighbor Solicitations for the purpose of Neighbor Unreachability
Detection (NUD) MUST be sent to that neighbor’s solicited-nodes
multicast address if the entry is not secured with SEND.
Upper layer confirmations on unsecured neighbor cache entries
SHOULD NOT update neighbor cache state from STALE to REACHABLE on
a SEND node if the neighbor cache entry has never previously been
REACHABLE. This ensures that if an entry spoofing a valid SEND
host is created by a non-SEND attacker without being solicited,
NUD will be done with the entry for data transmission within five
seconds of use.
As a result, in mixed mode, attackers can take over a Neighbor
Cache entry of a SEND node for a longer time only if (a) the SEND
node was not communicating with the victim node, so that there is
no secure entry for it, and (b) the SEND node is not currently on
the link (or is unable to respond).
o The conceptual sending algorithm is modified so that an unsecured
router is selected only if there is no reachable SEND router for
the prefix. That is, the algorithm for selecting a default router
favors reachable SEND routers over reachable non-SEND ones.
o A node MAY adopt a router sending unsecured messages, or a router
for which secured messages have been received but for which full
security checks have not yet been completed, while security
checking is underway. Security checks in this case include
certification path solicitation, certificate verification, CRL
checks, and RA signature checks. A node MAY also adopt a router
sending unsecured messages if a router known to be secured becomes
unreachable, but because the unreachability may be the result of
an attack it SHOULD attempt to find a router known to be secured
as soon as possible. Note that although this can speed up
attachment to a new network, accepting a router that is sending
unsecured messages or for which security checks are not complete
opens the node to possible attacks. Nodes that choose to accept
such routers do so at their own risk. The node SHOULD, in any
case, prefer a router known to be secure as soon as one is made
available with completed security checks.
9. Security Considerations
9.1. Threats to the Local Link Not Covered by SEND
SEND does not provide confidentiality for NDP communications.
SEND does not compensate for an unsecured link layer. For instance,
there is no assurance that payload packets actually come from the
same peer against which the NDP was run.
There may not be cryptographic binding in SEND between the link layer
frame address and the IPv6 address. An unsecured link layer could
allow nodes to spoof the link layer address of other nodes. An
attacker could disrupt IP service by sending out a Neighbor
Advertisement on an unsecured link layer, with the link layer source
address on the frame set as the source address of a victim, a valid
CGA address and a valid signature corresponding to itself, and a
Target Link-layer Address extension corresponding to the victim. The
attacker could then make a traffic stream bombard the victim in a DoS
attack. This cannot be prevented just by securing the link layer.
Even on a secured link layer, SEND does not require that the
addresses on the link layer and Neighbor Advertisements correspond.
However, performing these checks is RECOMMENDED if the link layer
technology permits.
Prior to participating in Neighbor Discovery and Duplicate Address
Detection, nodes must subscribe to the link-scoped All-Nodes
Multicast Group and the Solicited-Node Multicast Group for the
address that they are claiming as their addresses; RFC 2461 [4].
Subscribing to a multicast group requires that the nodes use MLD
[16]. MLD contains no provision for security. An attacker could
send an MLD Done message to unsubscribe a victim from the Solicited-
Node Multicast address. However, the victim should be able to detect
this attack because the router sends a Multicast-Address-Specific
Query to determine whether any listeners 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 router on the link has not
been compromised. Other attacks using MLD are possible, but they
primarily lead to extraneous (but not necessarily overwhelming)
traffic.
9.2. How SEND Counters Threats to NDP
The SEND protocol is designed to counter the threats to NDP, as
outlined in [22]. The following subsections contain a regression of
the SEND protocol against the threats, to illustrate which aspects of
the protocol counter each threat.
9.2.1. Neighbor Solicitation/Advertisement Spoofing
This threat is defined in Section 4.1.1 of [22]. The threat is that
a spoofed message may cause a false entry in a node’s Neighbor Cache.
There are two cases:
1. Entries made as a side effect of a Neighbor Solicitation or Router
Solicitation. A router receiving a Router Solicitation with a
Target Link-Layer Address extension and the IPv6 source address
unequal to the unspecified address inserts an entry for the IPv6
address into its Neighbor Cache. Also, a node performing
Duplicate Address Detection (DAD) that receives a Neighbor
Solicitation for the same address regards the situation as a
collision and ceases to solicit for the address.
In either case, SEND counters these threats by requiring that the
RSA Signature and CGA options be present in these solicitations.
SEND nodes can send Router Solicitation messages with a CGA source
address and a CGA option, which the router can verify, so that the
Neighbor Cache binding is correct. If a SEND node must send a
Router Solicitation with the unspecified address, the router will
not update its Neighbor Cache, as per base NDP.
2. Entries made as a result of a Neighbor Advertisement message.
SEND counters this threat by requiring that the RSA Signature and
CGA options be present in these advertisements.
Also see Section 9.2.5, below, for discussion about replay protection
and timestamps.
9.2.2. Neighbor Unreachability Detection Failure
This attack is described in Section 4.1.2 of [22]. SEND counters it
by requiring that a node responding to Neighbor Solicitations sent as
NUD probes include an RSA Signature option and proof of authorization
to use the interface identifier in the address being probed. If
these prerequisites are not met, the node performing NUD discards the
responses.
9.2.3. Duplicate Address Detection DoS Attack
This attack is described in Section 4.1.3 of [22]. SEND counters
this attack by requiring that the Neighbor Advertisements sent as
responses to DAD include an RSA Signature option and proof of
authorization to use the interface identifier in the address being
tested. If these prerequisites are not met, the node performing DAD
discards the responses.
When a SEND node performs DAD, it may listen for address collisions
from non-SEND nodes for the first address it generates, but not for
new attempts. This protects the SEND node from DAD DoS attacks by
non-SEND nodes or attackers simulating non-SEND nodes, at the cost of
a potential address collision between a SEND node and a non-SEND
node. The probability and effects of such an address collision are
discussed in [11].
9.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,
and 4.2.7 of [22]. SEND counters them by requiring that Router
Advertisements contain an RSA Signature option, and that the
signature is calculated by using the public key of a node that can
prove its authorization to route the subnet prefixes contained in any
Prefix Information Options. The router proves its authorization by
showing a certificate containing the specific prefix or an indication
that the router is allowed to route any prefix. A Router
Advertisement without these protections is discarded.
SEND does not protect against brute force attacks on the router, such
as DoS attacks, or against compromise of the router, as described in
Sections 4.4.2 and 4.4.3 of [22].
9.2.5. Replay Attacks
This attack is described in Section 4.3.1 of [22]. SEND protects
against attacks in Router Solicitation/Router Advertisement and
Neighbor Solicitation/Neighbor Advertisement transactions by
including a Nonce option in the solicitation and requiring that the
advertisement include a matching option. Together with the
signatures, this forms a challenge-response protocol.
SEND protects against attacks from unsolicited messages such as
Neighbor Advertisements, Router Advertisements, and Redirects by
including a Timestamp option. The following security issues are
relevant only for unsolicited messages:
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. Although 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.
Because most SEND nodes are likely to use fairly coarse-grained
timestamps, as explained in Section 5.3.1, this may affect some
nodes.
o Attacks against time synchronization protocols such as NTP [23]
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 these 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
This attack is described in Section 4.3.2 of [22]. In it, the
attacker bombards the router with packets for fictitious addresses on
the link, causing the router to busy itself by performing Neighbor
Solicitations for addresses that do not exist. SEND does not address
this threat because it can be addressed by techniques such as rate
limiting Neighbor Solicitations, restricting the amount of state
reserved for unresolved solicitations, and clever cache management.
These are all techniques involved in implementing Neighbor Discovery
on the router.
9.3. Attacks against SEND Itself
The CGAs have a 59-bit hash value. The security of the CGA mechanism
has been discussed in [11].
Some Denial-of-Service attacks remain against NDP and SEND itself.
For instance, an attacker may try to produce a very high number of
packets that a victim host or router has to verify by using
asymmetric methods. Although safeguards are required to prevent an
excessive use of resources, this can still render SEND non-
operational.
When CGA protection is used, SEND deals with the DoS attacks by using
the verification process described in Section 5.2.2. In this
process, a simple hash verification of the CGA property of the
address is performed before the more expensive signature
verification. However, even if the CGA verification succeeds, no
claims about the validity of the message can be made until the
signature has been checked.
When trust anchors and certificates are used for address validation
in SEND, the defenses are not quite as effective. Implementations
SHOULD track the resources devoted to the processing of packets
received with the RSA Signature option and start selectively
discarding packets if too many resources are spent. Implementations
MAY also first discard packets that are not protected with CGA.
The Authorization Delegation Discovery process may also be vulnerable
to Denial-of-Service attacks. An attack may target a router by
requesting that a large number of certification paths be discovered
for different trust anchors. Routers SHOULD defend against such
attacks by caching discovered information (including negative
responses) and by limiting the number of different discovery
processes in which they engage.
Attackers may also target hosts by sending a large number of
unnecessary certification paths, forcing hosts to spend useless
memory and verification resources on them. Hosts can defend against
such attacks by limiting the amount of resources devoted to the
certification paths and their verification. Hosts SHOULD also
prioritize advertisements sent as a response to solicitations the
hosts have sent about unsolicited advertisements.
10. Protocol Values
10.1. Constants
Host constants:
CPS_RETRY 1 second
CPS_RETRY_FRAGMENTS 2 seconds
CPS_RETRY_MAX 15 seconds
Router constants:
MAX_CPA_RATE 10 times per second
10.2. Variables
TIMESTAMP_DELTA 300 seconds (5 minutes)
TIMESTAMP_FUZZ 1 second
TIMESTAMP_DRIFT 1 % (0.01)
11. IANA Considerations
This document defines two new ICMP message types, used in
Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the informational message range:
o The Certification Path Solicitation message (148), described in
Section 6.4.1.
o The Certification Path Advertisement message (149), described in
Section 6.4.2.
This document defines six new Neighbor Discovery Protocol [4]
options, which must be assigned Option Type values within the option
numbering space for Neighbor Discovery Protocol messages:
o The CGA option (11), described in Section 5.1.
o The RSA Signature option (12), described in Section 5.2.
o The Timestamp option (13), described in Section 5.3.1.
o The Nonce option (14), described in Section 5.3.2.
o The Trust Anchor option (15), described in Section 6.4.3.
o The Certificate option (16), described in Section 6.4.4.
This document defines a new 128-bit value under the CGA Message Type
[11] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
This document defines a new name space for the Name Type field in the
Trust Anchor option. Future values of this field can be allocated by
using Standards Action [3]. The current values for this field are
1 DER Encoded X.501 Name
2 FQDN
Another new name space is allocated for the Cert Type field in the
Certificate option. Future values of this field can be allocated by
using Standards Action [3]. The current values for this field are
1 X.509v3 Certificate
12. References
12.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[6] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[7] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[8] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.
[9] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[10] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004.
[11] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
3972, March 2005.
[12] International Telecommunications Union, "Information Technology
- ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
[13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
1, November 2002.
[14] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
12.2. Informative References
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[17] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[18] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[19] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", Work
in Progress, March 2003.
[20] Arkko, J., "Manual SA Configuration for IPv6 Link Local
Messages", Work in Progress, June 2002.
[21] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API
for Address Selection", Work in Progress, October 2003.
[22] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[23] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth
Annual Computer Security Conference Proceedings, December 1990.
Appendix A. Contributors and Acknowledgments
Tuomas Aura contributed the transition mechanism specification in
Section 8. Jonathan Trostle contributed the certification path
example in Section 6.3.1. Bill Sommerfeld was involved with much of
the early design work.
The authors would also like to thank Tuomas Aura, Bill Sommerfeld,
Erik Nordmark, Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood,
Julien Laganier, Francis Dupont, Pekka Savola, Wenxiao He, Valtteri
Niemi, Mike Roe, Russ Housley, Thomas Narten, and Steven Bellovin for
interesting discussions in this problem space and for feedback
regarding the SEND protocol.
Appendix B. Cache Management
In this section, we outline a cache management algorithm that allows
a node to remain partially functional even under a cache-filling DoS
attack. This appendix is informational, and real implementations
SHOULD use different algorithms in order to avoid the dangers of a
mono-cultural code.
There are at least two distinct cache-related attack scenarios:
1. There are a number of nodes on a link, and someone launches a
cache filling attack. The goal here is to make sure that the
nodes can continue to communicate even if the attack is going on.
2. There is already a cache-filling attack going on, and a new node
arrives to the link. The goal here is to make it possible for the
new node to become attached to the network, in spite of the
attack.
As the intent is to limit the damage to existing, valid cache
entries, it is clearly better to be very selective in throwing out
entries. Reducing the timestamp Delta value is very discriminatory
against nodes with a large clock difference, as an attacker can
reduce its clock difference arbitrarily. Throwing out old entries
just because their clock difference is large therefore seems like a
bad approach.
It is reasonable to have separate cache spaces for new and old
entries, where when under attack, the newly cached entries would be
more readily dropped. One could track traffic and only allow
reasonable new entries that receive genuine traffic to be converted
into old cache entries. Although such a scheme can make attacks
harder, it will not fully prevent them. For example, an attacker
could send a little traffic (i.e., a ping or TCP syn) after each NS
to trick the victim into promoting its cache entry to the old cache.
To counter this, the node can be more intelligent in keeping its
cache entries than it would be just by having a black/white old/new
boundary.
Distinction of the Sec parameter from the CGA Parameters when forcing
cache entries out -- by keeping entries with larger Sec parameters
preferentially -- also appears to be a possible approach, as CGAs
with higher Sec parameters are harder to spoof.
Appendix C. Message Size When Carrying Certificates
In one example scenario using SEND, an Authorization Delegation
Discovery test run was made with a certification path length of 4.
Three certificates are sent by using Certification Path Advertisement
messages, as the trust anchor’s certificate is already known by both
parties. With a key length of 1024 bits, the certificate lengths in
the test run ranged from 864 to 888 bytes; the variation is due to
the differences in the certificate issuer names and address prefix
extensions. The different certificates had between 1 and 4 address
prefix extensions.
The three Certification Path Advertisement messages ranged from 1050
to 1,066 bytes on an Ethernet link layer. The certificate itself
accounts for the bulk of the packet. The rest is the trust anchor