Internet DRAFT - draft-laganier-send-ll-hba
draft-laganier-send-ll-hba
Network Working Group J. Laganier
Internet-Draft DoCoMo Euro-Labs
Expires: March 18, 2006 G. Montenegro
Microsoft
September 14, 2005
Link Layer Hashed Based Addresses (LL-HBA) for Secure Neighbor Discovery
(SEND)
draft-laganier-send-ll-hba-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The current mechanisms used by Secure Neighbor Discovery (SEND) to
secure the Neighbor Discovery Protocol (NDP) relies almost solely on
public key cryptography (i.e. Certificates and/or Cryptographically
Laganier & Montenegro Expires March 18, 2006 [Page 1]
Internet-Draft LL-HBA for SEND September 2005
Generated Addresses). While these approaches provide very strong
guarantees on the authenticity of an IP address to link layer address
mapping, they are computationally expensive, which might be a problem
on resource-constrained devices.
It is also recognized in the SEND specification that it does not
compensate for an insecure link layer; more specifically, no
protections are offered against spoofing, link disruption, or bombing
DoS attacks launched at the link layer. Accordingly, this note
suggests an alternative to the current specification of SEND which
leverage on the deemed required link layer security to secure NDP.
This technique is based on the use of a specific kind of IPv6
addresses, the so-called Link Layer Hashed Based Addresses (LL-HBA),
and of link layer address reachability tests.
When the link layer security prevents attacker to redirect frames at
the link layer layer, this technique allows to provide some level of
security to NDP while relying solely on symmetric (i.e.,
computationally inexpensive) cryptography.
Laganier & Montenegro Expires March 18, 2006 [Page 2]
Internet-Draft LL-HBA for SEND September 2005
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 4
2. Link Layer Address Reachability Test . . . . . . . . . . . . . 5
3. Link Layer Hashed Based Addresses (LL-HBA) . . . . . . . . . . 8
3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Processing Rules for Senders . . . . . . . . . . . . . . . 11
3.3 Processing Rules for Receivers . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4.1 Third Party Flooding DoS Attack . . . . . . . . . . . . . 13
4.2 Neighbor Solicitation/Advertisement Spoofing . . . . . . . 14
4.3 Neighbor Unreachability Detection Failure . . . . . . . . 14
4.4 Duplicate Address Detection DoS Attacks . . . . . . . . . 14
4.5 Router Solicitation/Advertisement Attacks . . . . . . . . 14
4.6 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 15
4.7 Neighbor Discovery DoS Attacks . . . . . . . . . . . . . . 15
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1 Normative References . . . . . . . . . . . . . . . . . . . 15
7.2 Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Laganier & Montenegro Expires March 18, 2006 [Page 3]
Internet-Draft LL-HBA for SEND September 2005
1. Introduction and Problem Statement
Several security issues with the IPv6 signaling protocol Neighbor
Discovery [I-D.ietf-ipv6-2461bis] as well as stateless address
autoconfiguration [I-D.ietf-ipv6-rfc2462bis][I-D.ietf-ipv6-privacy-
addrs-v2] were identified in [RFC3756]. Other issues are identified
within the specifications themselves. The Secure Neighbor Discovery
Working Group has produced documents addressing these issues: The
Secure Neighbor Discovery (SEND) Protocol [RFC3971] and
Cryptographically Generated Addresses (CGA) [RFC3972].
At the heart of these issues is the difficulty in obtaining a
security association such that any node can verify another node's
authorization when issuing a given IPv6 signaling packet. Such
difficulty precludes a straightforward application of IPsec between
any two previously unknown nodes (either of which may be a router).
The impossibility of always having the choice of obtaining such a
security association by leveraging a centralized infrastructure (PKI,
KDC, TTC, etc) has led to cryptographic techniques commonly known as
CGA or SUCV to be applied under similar constraints to problems of
securing Mobile IPv6 [SUCV][updateauth], group management for
multicast and anycast [SGM], Secure Neighbor Discovery [RFC3972],
etc.
However, the CGA method relies heavily on public key cryptography for
message generation and verification. This is potentially cumbersome
for resource-constrained devices, hence the desire to have a SEND
method which relies only on symmetric cryptography (e.g. hashes,
HMAC).
In the past, similar considerations led to the proposal of "hash-
based addresses" (HBAs) [I-D.arkko-mipv6-select-hash]. An HBA is an
IPv6 addresses produced by applying a hash to a particular byte
string, as opposed to a CGA, in which a hash is applied to a public
key. HBAs were subsequently applied to the problem of readdressing
for IPv6 multihoming (multi6) [I-D.ietf-multi6-hba]. In the multi6
case, the IPv6 address is derived from a byte string based on the set
of network prefixes available to the end node. This binding of a set
of HBAs to a set of valid network prefixes allows the node to
securely change its source address from one network prefix to
another.
The SEND and multi6 problems are very similar, namely, they seek to
provide a secure mapping between a given address and another set of
addresses: SEND needs a secure mapping from an IP address (configured
on a set of network interfaces) to a set of link layer addresses
(configured on the set of network interfaces using this IP address),
while multi6 needs a secure mapping from an IP address (the first
Laganier & Montenegro Expires March 18, 2006 [Page 4]
Internet-Draft LL-HBA for SEND September 2005
address used to send/receive packets) to another set of IP addresses
(the set of addresses configured on the host with distinct network
prefixes, on which the stack might need to fail-over). In this
document, we apply to SEND HBA and their generalization, Link Layer
Hashed Based Addresses.
Threats to Neighbor Discovery are particularly serious for multi-
access link layers which use addresses to deliver frames or packets
[RFC3756]. The local delivery depends on correctly mapping the link
layer (also known as MAC) addresses with the corresponding IP
addresses. These link layer addresses are usually outside the
purview of the IETF. The observation is that this lack of
coordination between the IP layer and the underlying link layer is
precisely the weakness that makes them so easy to attack.
The main idea came from the fact that SEND does not protect from an
insecure link layer, in which an attacker is able to redirect or
spoof frames at the link layer. Hence, we make the assumption that
the link layer security prevents attacker to redirect frames at the
link layer. Example of such security mechanisms might be a
combination of port-based access control with physical security,
802.1x, 802.11i (shared secret between the access point and the
mobile station), or 802.16 security (link layer addresses certified
by vendors).
Our proposal aims at establishing a (possibly cryptographic)
coordination between these two layers, thus closing this gaping hole
in ND security. This is a straightforward way to provide lightweight
security. The advantage of this mechanism, as opposed to that
suggested in [RFC3971] is its simplicity, but above all, the fact
that the additional security does not incur a huge additional work
load when generating and verifying messages, because it does not use
public key cryptography. This point is essential for resource
constrained devices, which will become arguably the majority of the
node population.
Accordingly, this note provides a high level overview of how the
suggested techniques (link layer address reachability tests and Link
Layer Hashed Based Addresses) can be applied to secure Neighbor
Discovery without recourse to public key cryptographic primitives.
The initial version of this document aims at generating discussion
about the proposed mechanisms. Further details are deferred to
further revisions of this document.
2. Link Layer Address Reachability Test
To build more trust onto the weak security of Link Layer Hashed Based
Address, this section defines a mandatory link layer address
Laganier & Montenegro Expires March 18, 2006 [Page 5]
Internet-Draft LL-HBA for SEND September 2005
reachability test, which is triggered upon reception of a Neighbor
Advertisement requiring a change in the state of the Neighbor
Discovery Protocol (e.g. link layer address change in a Neighbor
Cache Entry, Neighbor Unreachability Detection, Duplicate Address
Detection failure, etc.).
This reachability test is implemented by an exchange of unicast NS
and NA including a fresh Nonce. The NS must be sent to the target IP
address and link layer address. The NA would then echo back the
Nonce, completing the reachability test, and establishing the IP
address to link layer address mapping. The distinction between a NA
part of the initial ND exchange and a NA part of the subsequent
reachability test is possible because the the later was sent in
response to an unicast NS.
When receiving an solicited or unsolicited NA modifying the state of
the neighbor cache, a node MUST test the reachability of the Target
link layer address by resoliciting a NA with a fresh Nonce option.
It does so by sending to the source link layer address of the
solicited NA a unicast Neighbor Solicitation including the Nonce
option and the Target link layer address, thus including the
statement made in the solicited NA (e.g. Target IP Address X is at
Target link layer Address Y). The receiver of this packet MUST then
reply with a Neighbor Advertisement for this IP Address X with the
same Nonce and Target link layer address.
Laganier & Montenegro Expires March 18, 2006 [Page 6]
Internet-Draft LL-HBA for SEND September 2005
A B
----Multicast--->
NS[ Target IP ]
[ Source LL ]
[ Nonce 1 ]
<---Unicast------
NA[ Target IP ]
[ Target LL ]
[ Nonce 1 ]
----Unicast----->
NS[ Target IP ]
[ Source LL ]
[ Target LL ]
[ Nonce 2 ]
<---Unicast-------
NA[ Target IP ]
[ Target LL ]
[ Nonce 2 ]
Figure 1: Example of reachability test for solicited NA
A R
<---Multicast----
NA[ Target IP ]
[ Target LL ]
[ Nonce 1 ]
----Unicast----->
NS[ Target IP ]
[ Source LL ]
[ Target LL ]
[ Nonce 2 ]
<---Unicast------
NA[ Target IP ]
[ Target LL ]
[ Nonce 2 ]
Figure 2: Example of reachability test for unsolicited NA
An optimization of this reachability test is, for a node which
reachability is being tested by lot of nodes sending NS, to wait for
Laganier & Montenegro Expires March 18, 2006 [Page 7]
Internet-Draft LL-HBA for SEND September 2005
a certain interval before replying with a NA, while recording all the
Nonces it receives in the NS. Then the node can multicast to all
nodes a NA including all these Nonces.
A,B,C R
<---Multicast----
NA[ Target IP ]
[ Target LL ]
[ Nonce 1 ]
----Unicast----->
NS[ Target IP ]
[ Source LL ]
[ Target LL ]
[ Nonce 2 ]
----Unicast----->
NS[ Target IP ]
[ Source LL ]
[ Target LL ]
[ Nonce 3 ]
----Unicast----->
NS[ Target IP ]
[ Source LL ]
[ Target LL ]
[ Nonce 4 ]
<---Multicast----
NA[ Target IP ]
[ Target LL ]
[ Nonce 2 ]
[ Nonce 3 ]
[ Nonce 4 ]
Figure 3: Example of an optimized reachability test for unsolicited
NA
3. Link Layer Hashed Based Addresses (LL-HBA)
In this section we describe the concept of Link Layer Hashed Based
Addresses (LL-HBA).
The family of Link Layer Hashed Based Address consists of all the
routable IPv6 address whose Interface Identifier (IID) securely embed
an information about a mapping established from the IPv6 address to a
Laganier & Montenegro Expires March 18, 2006 [Page 8]
Internet-Draft LL-HBA for SEND September 2005
set of link layer addresses.
3.1 Definition
A Link Layer Hashed Based Addresses (LL-HBA) is an IPv6 address whose
IID embeds a secure mapping from the LL-HBA to a set of link layer
addresses.
Each node that wants its ND messages to be verifiable (and heeded) by
other nodes determines the set of link layer addresses (LL@[1], ...,
LL@[n]) at which it will be reachable with a common IP address. This
link layer address set SHOULD contain the link layer addresses of all
the interfaces of the node and its ND proxies at which it is usually
reachable.
Once the link layer address set is determined, the node then
generates an appropriate LL-HBA by conforming to the following
formulas, while the hash values are computed as described later in
this section:
Mask1 (64 bits) = 0x1cffffffffffffff
Mask2 (112 bits) = 0x0000000000000000000000000000 if Sec=0,
0xffff000000000000000000000000 if Sec=1,
0xffffffff00000000000000000000 if Sec=2,
0xffffffffffff0000000000000000 if Sec=3,
0xffffffffffffffff000000000000 if Sec=4,
0xffffffffffffffffffff00000000 if Sec=5,
0xffffffffffffffffffffffff0000 if Sec=6, and
0xffffffffffffffffffffffffffff if Sec=7
A link layer hash-based address is an IPv6 address for which the
following two equations hold:
Hash1 & Mask1 == interface identifier & Mask1
Hash2 & Mask2 == 0x0000000000000000000000000000
Notice that this does not mandate that all nodes generate and use LL-
HBA. This is only required for those nodes that wish the packets
they send to be verifiable as per the procedures defined in this
document.
Using an LL-HBA allows a node to prove that:
(1) The IPv6 address LL-HBA is derived from the set of Link Layer
Addresses LL@[1] ... LL@[n]
Laganier & Montenegro Expires March 18, 2006 [Page 9]
Internet-Draft LL-HBA for SEND September 2005
And consequently that:
(2) The owner of LL@[1] ... LL@[n] owns the IPv6 address LL-HBA
Which is indeed authorizing to establish the mapping:
(3) IPv6 address LL-HBA is at one of the link layer addresses in
the set LL@[1] ... LL@[n]
Thus, an attacker will need to find a collision on the mapping to
redirect packets to another link layer address (i.e. one which is not
in the set).
In order for LL-HBA to accommodate the simultaneous usage of SEND-CGA
[RFC3972] and MULTI6-HBA [I-D.ietf-multi6-hba], we define, a link
layer Hash-Based Address (LL-HBA) Extension to the CGA Parameters
data structure allowing to generate IPV6 addresses which are, at the
same time, CGAs, HBAs (for multi6 purposes), and LL-HBAs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext Type | Ext Len |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LL Type[1] | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LL Type[2] | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address[2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. ... .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LL Type[n] | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Layer Address[n] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext Type: 8-bit identifier of the LL-HBA Extension (TBD IANA)
Ext Len: 8-bit unsigned integer. Length of the Extension in 8-octet
units, not including the first 4 octets.
Laganier & Montenegro Expires March 18, 2006 [Page 10]
Internet-Draft LL-HBA for SEND September 2005
P flag: Set if a public key is included in the Public Key field of
the CGA Parameters Data Structure. Reset if an additional Modifier
bits are included in the CGA Parameters Data Structure.
LL Type[i]: The Type (e.g. 802.11) of the i^th link layer address.
The length of this link layer address is inferred from this type; for
example the length of an IEEE EUI-48 Identifier, which is used as
address by IEEE 802.11 is 6 octets.
Link Layer Address[i]: The i^th link layer Addresses, of size LL Addr
Len octets.
The two hash (Hash1 and Hash2) values MUST be computed as follows.
The SHA-1 hash algorithm [FIPS.180-1.1995] is applied to the CGA
Parameters. When computing Hash1, the input to the SHA-1 algorithm
is the CGA Parameters data structure. The 64-bit Hash1 is obtained
by taking the leftmost 64 bits of the 160-bit SHA-1 hash value. When
computing Hash2, the input is the same CGA Parameters data structure
except that the subnet prefix and collision count are set to zero.
The 112-bit Hash2 is obtained by taking the leftmost 112 bits of the
160-bit SHA-1 hash value. Note that the hash values are computed
over the entire CGA Parameters data structure, including the link
layer address extension as well as any unrecognized extension fields.
3.2 Processing Rules for Senders
The senders of a Neighbor Solicitation MUST include a fresh Nonce,
and store it so it can be matched against the Nonce included in an
answered Neighbor Advertisement.
The senders of a Neighbor Advertisement sent in reply to a Neighbor
Solicitation (i.e. solicited NA) MUST include a Nonce copied from
this NS. If a router decide to multicast the NA to all nodes on the
link, it MUST include the Nonce in a similar manner.
The senders of an unsolicited Neighbor Advertisement MAY have the
ability, when it receives the multiple reachability test NS sent by
on-link nodes, instead of replying with multiple unicast NA, to wait
for a period of time while storing the Nonces received in NS, and
then multicast a NA including all the Nonces.
3.3 Processing Rules for Receivers
All received Neighbor Solicitation or Advertisement not using CGA and
which do not include all of the following options MUST be treated as
insecure:
Laganier & Montenegro Expires March 18, 2006 [Page 11]
Internet-Draft LL-HBA for SEND September 2005
Nonce
CGA Parameter including a LL-HBA extension, validating the source
link layer address of the frame
If the node is using both CGA and LL-HBA, then the entries created as
the result of LL-HBA protected NDP MUST be labeled as such, and MUST
NOT overwrite an entry created by the CGA technique.
The receiver MUST have the ability to correctly parse multiple Nonce
options in any order.
The receiver of a solicited NA MUST verify that it has recently sent
a matching NS, and that the NA include the same Nonce as the one sent
in the NS. If the destination link layer address of the matching NS
was a multicast address, then the NA MUST be discarded, and the
target IP address MUST be resolicited by sending to the source link
layer address of the NA frame a unicast NS including a fresh Nonce,
as specified in Section 3.2. This round trip exchange implements the
link layer address reachability test described in Section 2.
The receiver of an unsolicited NA MUST discard it and resolicit the
target IP address by sending to the source link layer address of the
frame a unicast NS including a fresh Nonce, as specified in
Section 3.2. This round trip exchange implements the link layer
address reachability test described in Section 2.
4. Security Considerations
This document discusses security issues specifically involved with
the use of LL-HBA within the SEND protocol.
Some of the mechanisms already adopted as part of the SEND solution
impose a heavy load on processing nodes due to the use of public key
cryptography. The SEND solutions relies on the use of CGA, and
public key cryptography to provide proof-of-ownership of an
identifier (the CGA) for which a binding needs to be established.
The LL-HBA solution hereby proposed lowers the overall security level
of SEND with CGA because it provides only a proof-of-binding between
an identifier (the IPv6 LL-HBA) and the set of identifiers it is
bound to (the set of link layer addresses used as carriers for this
LL-HBA), instead of the CGA proof-of-ownership. This is similar in
essence to an authorization to act as a link layer address, issued by
the LL-HBA to one or multiple link layer addresses.
In spite of this, we believe than for certain scenarios, Neighbor
Discovery security might be provided by weaker and cheaper
Laganier & Montenegro Expires March 18, 2006 [Page 12]
Internet-Draft LL-HBA for SEND September 2005
cryptographic primitives without diminishing notably its security
level. The idea exposed in this document stems from the observation
that SEND does not protect from an attacker able to disrupt the link
layer service (by, e.g., causing an address collision at the link
layer, succeeds in preventing frames sent to a given link layer
Address to be delivered to their legitimate recipient).
On the other hand, if one make the assumption that a combination of
physical and link layer security prevents the attacks above, thus
making it hard for an attacker to:
1. Collide with another node link layer Address
2. Get packets sent to a link layer Address to be dropped
3. Get packets sent to a link layer Address redirected to another LL
Address
Then combining LL-HBA and link layer reachability tests gives a
solution almost as secure and robust than SEND.
To avoid redirections towards a link layer address which is not
reachable on the link, a node SHOULD use a given link layer address
as input to the LL-HBA generation if and only if it can ensure is
always reachable at this link layer address on the same prefix as the
LL-HBA. These multiple LL addresses might be those of multiple
Network Interfaces, and possibly those of a Neighbor Discovery Proxy
or a Mobile IPv6 Home Agent handling ND messages on a remote link on
behalf of the node.
The following sub-sections analyse the security-related differences
between our LL-HBA proposal and the original SEND [RFC3971], in light
of the threats outlined in [RFC3756].
4.1 Third Party Flooding DoS Attack
This threat is defined in section 9.1 of [RFC3971] and is not
countered by SEND. The threat is that because the link layer address
address is not cryptographically bound to the IP address, nothing
prevents an on-link attacker to spoof its victim link layer address
and send valid neighbor advertisement with a fabricated CGA, a valid
signature, while the target link layer address is the victim's one.
Such attacker would then cause a traffic stream to flood the victim
in a DoS attack, preventing it to receive valid data. LL-HBA does
not counter this threat. The reachability test requires a successful
attacker to be able to send frames spoofing its victim link layer
address.
Laganier & Montenegro Expires March 18, 2006 [Page 13]
Internet-Draft LL-HBA for SEND September 2005
4.2 Neighbor Solicitation/Advertisement Spoofing
This threat is defined in section 4.1.1 of [RFC3756], and SEND
counters it as described in section 9.2.1 of [RFC3971]. The threat
is that a spoofed message may cause a false entry in the Neighbor
Cache of a node. LL-HBA counters this threat by requiring the Target
link layer address to be reachable and in the link layer address set
of entry to be updated. Hence, nobody can prevent packets to be
delivered to the correct host because the binding will be established
towards a valid link layer address.
4.3 Neighbor Unreachability Detection Failure
This threat is defined in section 4.1.2 of [RFC3756], and SEND
counters it as described in section 9.2.2 of [RFC3971]. The threat
is that spoofed or replayed messages may prevent a node from
detecting unreachability of one of its neighbor. LL-HBA does not
counter this threat. The reachability test requires a successful
attacker to be able to snoop frames sent to its victim link layer
address, and to send frames spoofing its victim link layer address.
4.4 Duplicate Address Detection DoS Attacks
This threat is defined in section 4.1.3 of [RFC3756], and SEND
counters it as described in section 9.2.3 of [RFC3971]. The threat
is that an attacker sending fabricated NA/NS messages to a node
performing DAD may prevent it from acquiring any stateless
autoconfigured address [I-D.ietf-ipv6-rfc2462bis] [I-D.ietf-ipv6-
privacy-addrs-v2]. This is a DoS attack. LL-HBA and reachability
tests counter this threat by requiring a valid LL-HBA to be bound to
a given set of reachable link layer addresses. We made the
assumption that an attacker cannot create a collision with, or
redirect frames sent to its victim link layer address. Hence, an
attacker which claims that a collision occurs at the IP layer with
its LL-HBA, is using the same link layer address set and the same set
of parameters. This will cause the reachability test triggered onto
these link layer addresses to fail if the attacker is unaware of the
Nonce sent in the reachability test NS. On the other hand the
reachability test provides no protection against an attacker able to
snoop frames sent to its victim link layer address and to send frames
spoofing its victim link layer address.
4.5 Router Solicitation/Advertisement Attacks
These threats are defined in sections 4.2.1, 4.2.4, 4.2.5, 4.2.6 and
4.2.7 of [RFC3756], and SEND counters them as described in section
9.2.4 of [RFC3971]. The threat is that an attacker sending
fabricated RA/RS messages may siphon off all the traffic sent to a
Laganier & Montenegro Expires March 18, 2006 [Page 14]
Internet-Draft LL-HBA for SEND September 2005
set of network prefixes. LL-HBA does not protect against this. Note
that SEND's protection against these attacks is not based on CGAs but
rather on authorization certificates issued by a trust anchor for
routing delivery. Therefore, it implies that nodes on a LAN have
been provisioned with the anchor public key.
4.6 Replay Attacks
This threat is defined in section 4.3.1 of [RFC3756], and SEND
counters it as described in section 9.2.5 of [RFC3971]. As explained
before, LL-HBA does not protect protect against replay attacks, and
the reachability test requires from the attacker the ability to snoop
frames sent to its victim link layer address and to send frames
spoofing its victim link layer address. Under such conditions, any
node might replay the packets, misleading Neighbor Unreachability
Detection to incorrectly assume liveness for the original sender of
the packets.
4.7 Neighbor Discovery DoS Attacks
This threat is defined in section 4.3.2 of [RFC3756], and SEND does
not address it, as explained in section 9.2.6 of [RFC3971]. LL-HBA
is consistent with respect to this.
5. Conclusion
This note presents a high level overview of how a combination of the
LL-HBA technique with reachability tests can be used to secure
Neighbor Discovery. The proposal works in the absence of any
previously established direct or indirect (via a broker, AAA roaming
operator or trusted third party) security relationship, and does not
impose heavy computation on networked nodes. Because of this, these
methods are very practical and deployable.
6. Acknowledgements
Thanks to Erik Nordmark and Marcelo Bagnulo for their useful comments
and discussion.
7. References
7.1 Normative References
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-04 (work in progress), July 2005.
[I-D.ietf-ipv6-rfc2462bis]
Laganier & Montenegro Expires March 18, 2006 [Page 15]
Internet-Draft LL-HBA for SEND September 2005
Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", draft-ietf-ipv6-rfc2462bis-06 (work in
progress), October 2004.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
7.2 Informative References
[I-D.arkko-mipv6-select-hash]
Arkko, J., Nikander, P., and G. Montenegro, "Selection of
MIPv6 Security Level Using a Hashed Address",
draft-arkko-mipv6-select-hash-00 (work in progress),
June 2002.
[I-D.ietf-ipv6-privacy-addrs-v2]
Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6",
draft-ietf-ipv6-privacy-addrs-v2 (work in progress),
October 2004.
[I-D.ietf-multi6-hba]
Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-multi6-hba-00 (work in progress),
December 2004.
[I-D.thaler-ipv6-ndproxy]
Thaler, D. and M. Talwar, "Bridge-like Neighbor Discovery
Proxies (ND Proxy)", draft-thaler-ipv6-ndproxy-03 (work in
progress), October 2004.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Laganier & Montenegro Expires March 18, 2006 [Page 16]
Internet-Draft LL-HBA for SEND September 2005
[SGM] Castelluccia, C. and G. Montenegro, "Securing Group
Management in IPv6 with Cryptographically Generated
Addresses", 8th IEEE Symposium on Computers and
Communications (ISCC 2003), , July 2003.
[SUCV] Montenegro, G. and C. Castelluccia, "Crypto-based IDs
(CBIDs): Concepts and Applications", ACM Transactions on
Information and System Security (TISSEC) Volume 7, Number
1, February 2004.
[updateauth]
Roe, M., Aura, T., O'Shea, G., and J. Arkko,
"Authentication of Mobile IPv6 Binding Updates and
Acknowledgments", draft-roe-mobileip-updateauth (work in
progress), February 2002.
Authors' Addresses
Julien Laganier
DoCoMo Communications Laboratories Europe GmbH
Landsberger Strasse 312
Munich 80687
Germany
Phone: +49 89 56824 231
Email: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/
Gabriel Montenegro
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
USA
Email: gabriel_montenegro_2000@yahoo.com
Laganier & Montenegro Expires March 18, 2006 [Page 17]
Internet-Draft LL-HBA for SEND September 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Laganier & Montenegro Expires March 18, 2006 [Page 18]
