Address Protected Neighbor Discovery for Low-power and Lossy Networks
Cisco Systems, IncBuilding D45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis06254FRANCE+33 497 23 26 34pthubert@cisco.comPlanoTXUSAsarikaya@ieee.orgEricssonHirsalantieJorvas02420mohit@piuha.net6lo
This document defines an extension to
6LoWPAN Neighbor Discovery (ND)
called Address Protected ND (AP-ND); AP-ND protects the owner of an
address against address theft and impersonation inside a low-power
and lossy network (LLN). Nodes supporting this extension compute a
cryptographic Owner Unique Interface ID and associate it with one or
more of their Registered Addresses. The Cryptographic ID
identifies the owner of the Registered Address and can be used for
proof-of-ownership. It is used in 6LoWPAN ND in place of the
EUI-64-based unique ID that is associated with the registration.
Once an address is registered with a Cryptographic ID, only the
owner of that ID can modify the registration information of the
Registered Address, and Source Address Validation can be enforced.
"Neighbor Discovery Optimizations for 6LoWPAN networks"
(6LoWPAN ND) adapts the IPv6 ND (NDv6) protocol
(IPv6 ND) for
operations over a constrained low-power and lossy network (LLN).
In particular, 6LoWPAN ND introduces a unicast host address
registration mechanism that reduces the use of
multicast messages that are present in the NDv6 protocol.
6LoWPAN ND defines a new Address Registration Option (ARO) that is
carried in the unicast Neighbor Solicitation (NS) and Neighbor
Advertisement (NA) messages exchanged between a 6LoWPAN Node (6LN)
and a 6LoWPAN Router (6LR). It also defines the Duplicate
Address Request (DAR) and Duplicate Address Confirmation (DAC)
messages between the 6LR and the 6LoWPAN Border Router (6LBR).
In LLN networks, the 6LBR is the central repository of all the
registered addresses in its domain.
The registration mechanism in 6LoWPAN ND
prevents the use of an address if that address is already registered in
the subnet (first come first serve). In order to validate address
ownership, the registration mechanism enables the 6LR and 6LBR to
validate the association between a registered address and a
Registration Ownership Verifier (ROVR). 6LoWPAN ND specifies that the
ROVR is derived from the MAC address of the device (using the 64-bit
Extended Unique Identifier EUI-64 address format specified by IEEE),
which can be spoofed. Therefore, any node connected to the subnet
and aware of a registered-address-to-ROVR mapping could effectively
fake the ROVR, steal the address and redirect traffic for that address
towards a different 6LN.
The
"Registration Extensions for 6LoWPAN Neighbor Discovery"
defines an Extended ARO (EARO)
option that allows to transport alternate forms of ROVRs, and is a
prerequisite for this specification.
According to this specification, a 6LN generates a cryptographic ID
(Crypto-ID) and places it in the ROVR field in the registration of
one (or more) of its addresses with the 6LR(s) that the 6LN uses as
default router(s). Proof of ownership of the cryptographic ID
(Crypto-ID) is passed with the first registration exchange to a
new 6LR, and enforced at the 6LR. The 6LR validates ownership of
the cryptographic ID before it can create a registration,
or a change the information, that is the Link-Layer Address
and associated parameters, in an existing registration state.
The protected address registration protocol proposed in this document
enables Source Address Validation (SAVI)
, which ensures that only the
owner uses a registered address in the source address field in
IPv6 packets. Consequently, a 6LN that sources a packet has to
use a 6LR to which the source address of the packet is registered
to forward the packet. The 6LR maintains state information for the
registered addressed, including the MAC address, and a link-layer
cryptographic key associated with the 6LN. In SAVI-enforcement mode,
the 6LR allows only packets from a connected Host if the connected
Host owns the registration of the source address of the packet.
The 6lo adaptation layer framework (,
) specifies that a device forms its IPv6
addresses based on Layer-2 address, so as to enable a better
compression. This is incompatible with
"Secure Neighbor Discovery (SeND)" and
"Cryptographically Generated Addresses (CGAs)", which derive
the Interface ID (IID) in the IPv6 addresses from key
material. "Privacy Considerations for IPv6
Address Generation Mechanisms" places additional
recommendations on the way addresses should be formed and renewed.
This document specifies that a device may form and register addresses
at will, without a constraint on the way the address is formed or
the number of addresses that are registered in parallel,
Multiple addresses with a single ROVR, which only needs to be sent
once to a given 6LR for multiple addresses and registration updates.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 when,
and only when, they appear in all capitals, as shown here.
In this document, readers will encounter terms and concepts
that are discussed in the following documents:
"SEcure Neighbor Discovery (SEND)" ,
"Cryptographically Generated Addresses (CGA)"
, "Neighbor Discovery for IP version 6"
, "IPv6 Stateless Address Autoconfiguration"
, "Problem Statement and Requirements for
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
Routing" , "IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions,
Problem Statement, and Goals","Neighbor Discovery Optimization
for Low-power and Lossy Networks",
"Terms Used in Routing for Low-Power and Lossy Networks (LLNs)"
,
"Terminology for Constrained-Node Networks", and
"Registration Extensions for 6LoWPAN Neighbor Discovery" This document often uses the following acronyms:
6LoWPAN Backbone Router (proxy for the registration)
6LoWPAN Border Router 6LoWPAN Node
6LoWPAN Router (relay to the registration process) Crypto-ID Parameters Option (Extended) Address Registration Option Duplicate Address Detection
Low-Power and Lossy Network (a typical IoT network) Neighbor Advertisement Neighbor Discovery Neighbor Discovery Protocol NDP Signature Option Neighbor Solicitation
Registration Ownership Verifier (pronounced rover) Router Advertisement Router Solicitation RSA Signature Option Transaction ID (a sequence counter in the EARO)
This document defines a new Crypto-ID as an identifier of variable size
which is 64 to 256 bits long. It is generated using
cryptographic means explained later in this document
.
"Elliptic Curves for Security" and
"Edwards-Curve Digital Signature Algorithm (EdDSA)"
provides information on
Elliptic Curve Cryptography (ECC) and a (twisted) Edwards curve,
Ed25519, which can be used with this specification.
"Alternative Elliptic Curve Representations"
provides
additional information on how to represent Montgomery curves and
(twisted) Edwards curves as curves in short-Weierstrass form and
illustrates how this can be used to implement elliptic curve
computations using existing implementations that already implement,
e.g., ECDSA and ECDH using NIST
prime curves.
This specification defines a cryptographic identifier (Crypto-ID) that
can be used as a replacement to the MAC address in the ROVR field of
the EARO option; the computation of the Crypto-ID is detailed in
. A node in possession of the necessary
cryptographic material SHOULD use Crypto-ID by default as ROVR in
its registration. Whether a ROVR is a Crypto-ID is indicated by a
new "C" flag in the NS(EARO) message.
In order to prove its ownership of a Crypto-ID, the registering node
needs to supply certain parameters
including a nonce and a signature that will prove that the node has
the private
key corresponding to the public key used to build the
Crypto-ID. This specification adds the capability to carry new
options in the NS(EARO) and the NA(EARO). The NS(EARO) carries a
variation of the CGA Option (), a Nonce
option and a variation of the RSA Signature option
() in the NS(EARO). The NA(EARO) carries a
Nonce option.
In order to avoid the need for new ND option types, this specification
reuses / extends options defined in SEND
and 6LoWPAN ND . This applies in
particular to the CGA option and the RSA Signature Option. This
specification provides aliases for the specific variations of those
options as used in AP-ND. The presence of the EARO option in the
NS/NA messages indicates that the crypto options are to be processed
as specified in this document, not as a SEND message.
A 6LN provides its public key in an NS message. The public key
could be in uncompressed form
or in compressed form where the first octet of the OCTET STRING is
0x04 and 0x02 or 0x03, respectively. Point compression can further
reduce the key size by about 32 octets.
Each 6LN using a Crypto-ID for registration MUST have a public/private
key pair.
The Crypto-ID is computed as follows:
An 8-bit modifier is selected, enabling a device to form multiple
Crypto-IDs with a single key pair. This is useful for privacy
reasons in order to avoid the correlation of addresses based
on their Crypto-ID;
the modifier value
and the DER-encoded public key () are
concatenated from left to right;
The digital signature is constructed by using the 6LN's private
key over its EUI-64 (MAC) address. The signature value is computed
using the ECDSA signature algorithm and the hash function used
is SHA-256 .
the leftmost bits of the resulting hash are used as the Crypto-ID,
up to the size of the ROVR field.
This specification updates the EARO option as follows:
33
8-bit unsigned integer. The length of the option (including the
type and length fields) in units of 8 bytes.
8-bit unsigned integer. Indicates the status of a registration in
the NA response. MUST be set to 0 in NS messages.
Defined in .
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
This "C" flag is set to indicate that the Owner Unique ID field
contains a Crypto-ID and that the 6LN MAY be challenged for
ownership as specified in this document.
Defined in .
Defined in .
Defined in .
When the "C" flag is set, this field contains a Crypto-ID.
This specification uses Status values "Validation Requested" and
"Validation Failed", which are defined in
6LoWPAN ND.
No other new Status values is defined.
This specification defines the Crypto-ID Parameters Option (CIPO),
as a variation of the CGA Option that carries the parameters used
to form a Crypto-ID.
In order to provide cryptographic agility ,
AP-ND supports two possible signature algorithms, indicated by a
Crypto-Type field.
Elliptic Curve Cryptography (ECC) is used to calculate the Crypto-ID.
NIST P-256 MUST be supported by
all implementations.
The Edwards-Curve Digital Signature Algorithm
(EdDSA) curve Ed25519ph (pre-hashing)
MAY be supported as an alternate.
11. This is the same value as the CGA Option, CIPO is a
particular case of the CGA option
8-bit unsigned integer.
The length of the option in units of 8 octets.
8-bit unsigned integer.
8-bit unsigned integer. The length of the Padding field.
The type of cryptographic algorithm used in calculation Crypto-ID.
A value of 0 indicates NIST P-256, with SHA-256 as the hash
algorithm. A value of 1 is assigned for Ed25519ph, with SHA-256
as the hash algorithm.
DER-Encoded Public Key.
A variable-length field making the option length a multiple of 8,
containing as many octets as specified in the Pad Length field.
This document reuses the Nonce Option defined in section 5.3.2.
of SEND without a change.
This document reuses the RSA Signature Option (RSAO) defined
in section 5.2. of SEND.
Admittedly, the name is ill-chosen since the option is extended
for non-RSA Signatures and this specification defines an
alias to avoid the confusion.
The description of the operation on the option detailed in section 5.2.
of SEND apply, but for the following
changes:
The 128-bit CGA Message Type tag for
AP-ND is 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. (The tag
value has been generated by the editor of this specification on
random.org).
The signature is computed using the hash algorithm and the
digital signature indicated in the Crypto-Type field of the
CIPO option using the private key associated with the public
key in the CIPO.
The alias NDP Signature Option (NDPSO) can be used to refer
to the RSAO when used as described in this specification.
The scope of the present work is a 6LoWPAN Low Power Lossy Network
(LLN), typically a stub network connected to a larger IP network via
a Border Router called a 6LBR per .
A 6LBR has sufficient capability to satisfy the needs of DAD.
The 6LBR maintains registration state for all devices in its
attached LLN. Together with the first-hop router (the 6LR), the 6LBR
assures uniqueness and grants ownership of an
IPv6 address before it can be used in the LLN. This is in contrast
to a traditional network that relies on IPv6 address
auto-configuration , where there is no
guarantee of ownership from the network, and each IPv6 Neighbor
Discovery packet must be individually secured .
In a mesh network, the 6LR is directly connected to the host device.
This specification mandates that the peer-wise layer-2 security is
deployed so that all the packets from a particular host are securely
identifiable by the 6LR. The 6LR may be multiple hops away from the
6LBR. Packets are routed between the 6LR and the 6LBR via other 6LRs.
This specification mandates that a chain of trust is established so
that a packet that was validated by the first 6LR can be safely routed
by the next 6LRs to the 6LBR.
The 6LR/6LBR ensures first-come/first-serve by storing the EARO
information including the Crypto-ID associated to the node being
registered. The node can claim any address as long
as it is the first to make such a claim. After a successful
registration, the node becomes the owner of the registered
address and the address is bound to the Crypto-ID in the
6LR/6LBR registry.
This specification enables the 6LR to verify the ownership of the
binding at any time assuming that the "C" flag is set.
The verification prevents other nodes from
stealing the address and trying to attract traffic for that address
or use it as their source address.
A node may use multiple IPv6 addresses at the same time. The node
may use a same Crypto-ID, or multiple crypto-IDs derived from a
same key pair, to protect multiple IPv6 addresses. The separation
of the address and the cryptographic material avoids the constrained
device to compute multiple keys for multiple addresses. The
registration process allows the node to use the same Crypto-ID
for all of its addresses.
A 6LN registers to a 6LR that is one hop away from it with the
"C" flag set in the EARO, indicating that the ROVR
field contains a Crypto-ID. The on-link (local) protocol
interactions are shown in
If the 6LR does not have a state with the 6LN that is consistent
with the NS(EARO), then it replies with a challenge NA (EARO,
status=Validation Requested) that contains a Nonce Option.
The Nonce option MUST contain a Nonce value that was never
used with this device.
The 6LN replies to the challenge with an NS(EARO) that includes
the echoed Nonce option, the CIPO ,
and the NDPSO with the signature. The
information associated to a crypto-ID stored
by the 6LR on the first NS exchange where it appears. The 6LR
SHOULD store the CIPO parameters associated with the crypto-ID
so it can be used for more than one address.
The steps for the registration to the 6LR are as follows:
Upon the first exchange with a 6LR, a 6LN may be challenged
to prove ownership of the Crypto-ID.
The proof is not needed again in
later registrations for that address, or when
registering other addresses with the same ROVR. When a 6LR
receives a NS(EARO) registration with a new Crypto-ID as a ROVR,
it SHOULD challenge by responding with a NA(EARO) with a status
of "Validation Requested". This process of validation MAY be
skipped in networks where there is no mobility.
The challenge is triggered when the registration for a
Source Link-Layer Address is not verifiable either at the 6LR
or the 6LBR. In the latter case, the 6LBR returns a status of
"Validation Requested" in the DAR/DAC exchange, which is echoed
by the 6LR in the NA (EARO) back to the registering node.
The challenge MUST NOT alter a valid registration
in the 6LR or the 6LBR.
Upon receiving a NA(EARO) with a status of "Validation Requested",
the registering node SHOULD retry its registration with a
Crypto-ID Parameters Option (CIPO) ()
that contains all the necessary material for building the
Crypto-ID, the Nonce and the NDP signature ()
options that prove its ownership of the Crypto-ID.
In order to validate the ownership, the 6LR performs the same
steps as the 6LN and rebuilds the Crypto-ID based on the
parameters in the CIPO. If the result is different then the
validation fails. Else, the 6LR checks the signature in the
NDPSO using the public key in the CIPO. If it is correct then
the validation passes, else it fails.
If the 6LR fails to validate the signed NS(EARO), it responds
with a status of "Validation Failed". After receiving a NA(EARO)
with a status of "Validation Failed", the registering node SHOULD
try an alternate Crypto-ID. The registering node MUST NOT use the
same Crypto-ID for subsequent registration attempts.
In a multihop 6LoWPAN, the registration with Crypto-ID is
propagated to 6LBR as described in this section.
If the 6LR and the 6LBR maintain a security association,
then there is no need to propagate the proof of ownership to
the 6LBR.
A new device that joins the network auto-configures an address
and performs an initial registration to a neighboring 6LR with an
NS message that carries an Address Registration Option (EARO)
. The 6LR validates the address with
an 6LBR using a DAR/DAC exchange, and the 6LR confirms
(or denies) the address ownership with an NA message that also
carries an Address Registration Option.
illustrates a registration flow all
the way to a 6LowPAN Backbone Router (6BBR).
In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream
and the 6LR receives and relays them to the nodes. 6LR and 6LBR
communicate using ICMPv6 Duplicate Address Request (DAR) and
Duplicate Address Confirmation (DAC) messages. The DAR and DAC
use the same message format as NS and NA, but have different
ICMPv6 type values.
In AP-ND we extend DAR/DAC messages to carry cryptographically
generated ROVR. In a multihop 6LoWPAN, the node exchanges the
messages shown in . The 6LBR must identify
who owns an address (EUI-64) to defend it, if there is an attacker
on another 6LR.
Observations regarding the following threats to the local network
in also apply to this specification.
Threats in section 9.2.1 of RFC3971 apply. AP-ND counters the
threats on NS(EARO) messages by requiring that the NDP
Signature and CIPO options be present in these solicitations.
With RFC6775, a NUD can still be used by the endpoint to
assess the liveness of a device. The NUD request may be
protected by SEND in which case the provision in section
9.2 of RFC 3972 applies. The response to the NUD may be
proxied by a backbone router only if it has a fresh
registration state for it. For a registration being protected
by this specification, the proxied NUD response provides
truthful information on the original owner of the address
but it cannot be proven using SEND.
If the NUD response is
not proxied, the 6LR will pass the lookup to the end device
which will respond with a traditional NA. If the 6LR does not
have a registration associated for the device, it can issue
a NA with EARO (status=Validation Requested) upon the NA from
the device, which will trigger a NS that will recreate and
revalidate the ND registration.
Inside the LLN, Duplicate Addresses are sorted out using
the ROVR, which differentiates it from a movement. DAD
coming from the backbone are not forwarded over the LLN,
which provides some protection against DoS attacks
inside the resource-constrained part of the network.
Over the
backbone, the EARO option is present in NS/NA messages.
This protects against misinterpreting a movement for a
duplication, and enables the backbone routers to determine
which one has the freshest registration and is thus the
best candidate to validate the registration for the
device attached to it.
But this specification does not
guarantee that the backbone router claiming an address
over the backbone is not an attacker.
This specification does not change the protection of RS and
RA which can still be protected by SEND.
A Nonce given by the 6LR in the NA with EARO
(status=Validation Requested) and echoed in the signed
NS guarantees against replay attacks of the NS(EARO).
The NA(EARO) is not protected and can be forged by a
rogue node that is not the 6LR in order to force the
6LN to rebuild a NS(EARO) with the proof of ownership,
but that rogue node must have access to the L2 radio network
next to the 6LN to perform the attack.
A rogue node that managed to access the L2 network may form
many addresses and register them using AP-ND. The perimeter
of the attack is all the 6LRs in range of the attacker.
The 6LR must protect itself against overflows and reject
excessive registration with a status 2 "Neighbor Cache Full".
This effectively blocks another (honest) 6LN from registering
to the same 6LR, but the 6LN may register to other 6LRs that
are in its range but not in that of the rogue.
The threats discussed in 6LoWPAN ND and its
update also apply here.
Compared with SeND, this specification saves about 1Kbyte in every
NS/NA message. Also, this specification separates the cryptographic
identifier from the registered IPv6 address so that a node can have
more than one IPv6 address protected by the same cryptographic
identifier. SeND forces the IPv6 address to be cryptographic since
it integrates the CGA as the IID in the IPv6 address. This
specification frees the device to form its addresses in any fashion,
thereby enabling not only 6LoWPAN compression which derives IPv6
addresses from Layer-2 addresses but also privacy addresses.
A collision of Registration Ownership Verifiers (ROVR) (i.e., the
Crypto-ID in this specification) is possible, but it is a rare event.
The formula for calculating the probability of a collision is
1 - e^{-k^2/(2n)} where n is the maximum population size (2^64 here,
1.84E19) and K is the actual population (number of nodes). If the
Crypto-ID is 64-bits, the chance of a collision is 0.01% when
the network contains 66 million nodes. Moreover, the collision is
only relevant when this happens within one stub network (6LBR).
In the case of such a collision, an attacker may be able
to claim the registered address of an another legitimate node.
However for this to happen, the attacker would also need to know
the address which was registered by the legitimate node. This
registered address is never broadcasted on the network and
therefore providing an additional 64-bits that an
attacker must correctly guess. To prevent address disclosure, it is
RECOMMENDED that nodes derive the address being registered
independently of the ROVR.
This document defines a new 128-bit value under the CGA Message Type
namespace,
0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0.
IANA is requested to create a new subregistry "Crypto-Type Subregistry"
in the "Internet Control Message Protocol version 6 (ICMPv6)
Parameters". The registry is indexed by an integer 0..255 and
contains a Signature Algorithm and a Hash Function as shown in
. The following Crypto-Type values
are defined in this document:
Crypto-Type valueSignature AlgorithmHash FunctionDefining Specification0 NIST P-256 SHA-256 RFC THIS1 Ed25519ph SHA-256 RFC THIS
Assignment of new values for new Crypto-Type MUST be done through
IANA with "Specification Required" and "IESG Approval" as defined
in .
Many thanks to Charlie Perkins for his in-depth review and
constructive suggestions. We are also especially grateful to
Rene Struik and Robert Moskowitz for their comments that lead to
many improvements to this document, in particular WRT ECC computation
and references.
Digital Signature Standard (DSS), Federal Information
Processing Standards Publication 186-4
FIPS 186-4
FIPS Publication 186-4: Digital Signature Standard
In this section we state requirements of a secure neighbor discovery
protocol for low-power and lossy networks.
The protocol MUST be based on the Neighbor Discovery Optimization
for Low-power and Lossy Networks protocol defined in
. RFC6775 utilizes optimizations such as
host-initiated interactions for sleeping resource-constrained
hosts and elimination of multicast address resolution.
New options to be added to Neighbor Solicitation messages MUST
lead to small packet sizes, especially compared with existing
protocols such as SEcure Neighbor Discovery (SEND). Smaller
packet sizes facilitate low-power transmission by
resource-constrained nodes on lossy links.
The support for this registration mechanism SHOULD be extensible
to more LLN links than IEEE 802.15.4 only. Support for at least
the LLN links for which a 6lo "IPv6 over foo" specification
exists, as well as Low-Power Wi-Fi SHOULD be possible.
As part of this extension, a mechanism to compute a unique
Identifier should be provided with the capability to form a
Link Local Address that SHOULD be unique at least within the
LLN connected to a 6LBR.
The Address Registration Option used in the ND registration
SHOULD be extended to carry the relevant forms of Unique
Interface IDentifier.
The Neighbour Discovery should specify the formation of a
site-local address that follows the security recommendations from
.