< draft-ietf-6lo-ap-nd-12.txt   draft-ietf-6lo-ap-nd-13.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Updates: 8505 (if approved) B. Sarikaya Updates: 8505 (if approved) B.S. Sarikaya
Intended status: Standards Track Intended status: Standards Track
Expires: October 12, 2019 M. Sethi Expires: 9 July 2020 M.S. Sethi
Ericsson Ericsson
R. Struik R.S. Struik
Struik Security Consultancy Struik Security Consultancy
April 10, 2019 6 January 2020
Address Protected Neighbor Discovery for Low-power and Lossy Networks Address Protected Neighbor Discovery for Low-power and Lossy Networks
draft-ietf-6lo-ap-nd-12 draft-ietf-6lo-ap-nd-13
Abstract Abstract
This document specifies an extension to 6LoWPAN Neighbor Discovery This document updates the 6LoWPAN Neighbor Discovery (ND) protocol
(ND) protocol defined in RFC6775 and updated in RFC8505. The new defined in RFC 6775 and RFC 8505. The new extension is called
extension is called Address Protected Neighbor Discovery (AP-ND) and Address Protected Neighbor Discovery (AP-ND) and it protects the
it protects the owner of an address against address theft and owner of an address against address theft and impersonation attacks
impersonation attacks in a low-power and lossy network (LLN). Nodes in a low-power and lossy network (LLN). Nodes supporting this
supporting this extension compute a cryptographic identifier (Crypto- extension compute a cryptographic identifier (Crypto-ID) and use it
ID) and use it with one or more of their Registered Addresses. The with one or more of their Registered Addresses. The Crypto-ID
Crypto-ID identifies the owner of the Registered Address and can be identifies the owner of the Registered Address and can be used to
used to provide proof of ownership of the Registered Addresses. Once provide proof of ownership of the Registered Addresses. Once an
an address is registered with the Crypto-ID and a proof-of-ownership address is registered with the Crypto-ID and a proof-of-ownership is
is provided, only the owner of that address can modify the provided, only the owner of that address can modify the registration
registration information, thereby enforcing Source Address information, thereby enforcing Source Address Validation.
Validation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 12, 2019. This Internet-Draft will expire on 9 July 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 6 3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5
4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 5
4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 8 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7
4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9 4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 8
5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 9
6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 12 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 11
6.2. NDPSO generation and verification . . . . . . . . . . . . 14 6.2. NDPSO generation and verification . . . . . . . . . . . . 13
6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 16 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 17 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 15
7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 16
7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 18 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 17
7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 19 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 17
7.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 19 7.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 17
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 19 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 17
8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 19 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 18
8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 20 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Normative References . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 11. Informative references . . . . . . . . . . . . . . . . . . . 20
10.2. Informative references . . . . . . . . . . . . . . . . . 22 Appendix A. Requirements Addressed in this Document . . . . . . 22
Appendix A. Requirements Addressed in this Document . . . . . . 24 Appendix B. Representation Conventions . . . . . . . . . . . . . 23
Appendix B. Representation Conventions . . . . . . . . . . . . . 24 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 23
B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 24 B.2. Integer Representation for ECDSA signatures . . . . . . . 24
B.2. Integer Representation for ECDSA signatures . . . . . . . 25 B.3. Alternative Representations of Curve25519 . . . . . . . . 24
B.3. Alternative Representations of Curve25519 . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775] Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775]
(6LoWPAN ND) adapts the original IPv6 neighbor discovery (NDv6) (6LoWPAN ND) adapts the original IPv6 Neighbor Discovery (IPv6 ND)
protocols defined in [RFC4861] and [RFC4862] for constrained low- protocols defined in [RFC4861] and [RFC4862] for constrained low-
power and lossy network (LLN). In particular, 6LoWPAN ND introduces power and lossy network (LLN). In particular, 6LoWPAN ND introduces
a unicast host address registration mechanism that reduces the use of a unicast host Address Registration mechanism that reduces the use of
multicast. 6LoWPAN ND defines a new Address Registration Option (ARO) multicast compared to the Duplicate Address Detection (DAD) mechanism
that is carried in the unicast Neighbor Solicitation (NS) and defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration
Neighbor Advertisement (NA) messages exchanged between a 6LoWPAN Node Option (ARO) that is carried in the unicast Neighbor Solicitation
(6LN) and a 6LoWPAN Router (6LR). It also defines the Duplicate (NS) and Neighbor Advertisement (NA) messages exchanged between a
Address Request (DAR) and Duplicate Address Confirmation (DAC) 6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). It also defines the
messages between the 6LR and the 6LoWPAN Border Router (6LBR). In Duplicate Address Request (DAR) and Duplicate Address Confirmation
LLN networks, the 6LBR is the central repository of all the (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. registered addresses in its domain.
The registration mechanism in 6LoWPAN ND [RFC6775] prevents the use The registration mechanism in 6LoWPAN ND [RFC6775] prevents the use
of an address if that address is already registered in the subnet of an address if that address is already registered in the subnet
(first come first serve). In order to validate address ownership, (first come first serve). In order to validate address ownership,
the registration mechanism enables the 6LR and 6LBR to validate the the registration mechanism enables the 6LR and 6LBR to validate the
association between the registered address of a node, and its association between the registered address of a node, and its
Registration Ownership Verifier (ROVR). ROVR is defined in [RFC8505] Registration Ownership Verifier (ROVR). ROVR is defined in [RFC8505]
and it can be derived from the MAC address of the device (using the and it can be derived from the MAC address of the device (using the
64-bit Extended Unique Identifier EUI-64 address format specified by 64-bit Extended Unique Identifier EUI-64 address format specified by
skipping to change at page 4, line 31 skipping to change at page 4, line 30
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. References 2.2. References
Terms and concepts from the following documents are used in this Terms and concepts from the following documents are used in this
specification: specification:
o "Terms Used in Routing for Low-Power and Lossy Networks (LLNs)" * "Terms Used in Routing for Low-Power and Lossy Networks (LLNs)"
[RFC7102], [RFC7102],
* "SEcure Neighbor Discovery (SEND)" [RFC3971],
o "SEcure Neighbor Discovery (SEND)" [RFC3971], * "Cryptographically Generated Addresses (CGA)" [RFC3972],
* "Neighbor Discovery for IP version 6" [RFC4861] ,
o "Cryptographically Generated Addresses (CGA)" [RFC3972], * "IPv6 Stateless Address Autoconfiguration" [RFC4862],
* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
o "Neighbor Discovery for IP version 6" [RFC4861] ,
o "IPv6 Stateless Address Autoconfiguration" [RFC4862],
o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals " [RFC4919], Overview, Assumptions, Problem Statement, and Goals " [RFC4919],
* "Neighbor Discovery Optimization for Low-power and Lossy Networks"
o "Neighbor Discovery Optimization for Low-power and Lossy Networks"
[RFC6775], and [RFC6775], and
* "Registration Extensions for 6LoWPAN Neighbor Discovery"
o "Registration Extensions for 6LoWPAN Neighbor Discovery"
[RFC8505]. [RFC8505].
2.3. Abbreviations 2.3. Abbreviations
This document uses the following abbreviations: This document uses the following abbreviations:
6BBR: 6LoWPAN Backbone Router 6BBR: 6LoWPAN Backbone Router
6LBR: 6LoWPAN Border Router
6LBR: 6LoWPAN Border Router
6LN: 6LoWPAN Node 6LN: 6LoWPAN Node
6LR: 6LoWPAN Router 6LR: 6LoWPAN Router
6CIO: Capability Indication Option
6CIO: Capability Indication Option
ARO: Address Registration Option ARO: Address Registration Option
CIPO: Crypto-ID Parameters Option
CIPO: Crypto-ID Parameters Option
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
NA: Neighbor Advertisement
NA: Neighbor Advertisement
NCE: Neighbor Cache Entry NCE: Neighbor Cache Entry
ND: Neighbor Discovery
ND: Neighbor Discovery
NDP: Neighbor Discovery Protocol NDP: Neighbor Discovery Protocol
NDPSO: NDP Signature Option NDPSO: NDP Signature Option
NS: Neighbor Solicitation
NS: Neighbor Solicitation ROVR: Registration Ownership Verifier
ROVR: Registration Ownership Verifier
RPL: IPv6 Routing Protocol for LLNs RPL: IPv6 Routing Protocol for LLNs
RA: Router Advertisement
RA: Router Advertisement RS: Router Solicitation
RSAO: RSA Signature Option
RS: Router Solicitation
RSAO: RSA Signature Option
TID: Transaction ID TID: Transaction ID
3. Updating RFC 8505 3. Updating RFC 8505
This specification introduces a new token called a cryptographic This specification introduces a new token called a cryptographic
identifier (Crypto-ID) that is used to prove indirectly the ownership identifier (Crypto-ID) that is used to prove indirectly the ownership
of an address that is being registered by means of [RFC8505]. The of an address that is being registered by means of [RFC8505]. The
Crypto-ID is derived from a cryptographic public key and additional Crypto-ID is derived from a cryptographic public key and additional
parameters. The proof requires the support of Elliptic Curve parameters. The proof requires the support of Elliptic Curve
Cryptography (ECC) and that of a hash function as detailed in Cryptography (ECC) and that of a hash function as detailed in
skipping to change at page 6, line 50 skipping to change at page 6, line 23
use Crypto-ID by default as ROVR in its registrations. Whether a use Crypto-ID by default as ROVR in its registrations. Whether a
ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO) ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO)
message. message.
The Crypto-ID is derived from the public key and a modifier as The Crypto-ID is derived from the public key and a modifier as
follows: follows:
1. The hash function indicated by the Crypto-Type is applied to the 1. The hash function indicated by the Crypto-Type is applied to the
CIPO. Note that all the reserved and padding bits MUST be set to CIPO. Note that all the reserved and padding bits MUST be set to
zero. zero.
2. The leftmost bits of the resulting hash, up to the size of the 2. The leftmost bits of the resulting hash, up to the size of the
ROVR field, are used as the Crypto-ID. ROVR field, are used as the Crypto-ID.
4.2. Updated EARO 4.2. Updated EARO
This specification updates the EARO option as follows: This specification updates the EARO option as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Opaque | | Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsvd |C| I |R|T| TID | Registration Lifetime | |Rsvd |C| I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier (ROVR) ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Enhanced Address Registration Option Figure 1: Enhanced Address Registration Option
Type: 33
Length: 8-bit unsigned integer. The length of the option
(including the type and length fields) in units of 8
bytes.
Status: 8-bit unsigned integer. Indicates the status of a
registration in the NA response. MUST be set to 0 in
NS messages.
Opaque: Defined in [RFC8505]. Type: 33
Length: 8-bit unsigned integer. The length of the option (including
the type and length fields) in units of 8 bytes.
Status: 8-bit unsigned integer. Indicates the status of a
registration in the NA response. MUST be set to 0 in NS messages.
Opaque: Defined in [RFC8505].
Rsvd (Reserved): This field is unused. It MUST be initialized to Rsvd (Reserved): This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the zero by the sender and MUST be ignored by the receiver.
receiver. C: This "C" flag is set to indicate that the ROVR field contains a
Crypto-ID and that the 6LN MAY be challenged for ownership as
C: This "C" flag is set to indicate that the ROVR field specified in this document.
contains a Crypto-ID and that the 6LN MAY be
challenged for ownership as specified in this
document.
I, R, T, and TID: Defined in [RFC8505]. I, R, T, and TID: Defined in [RFC8505].
Registration Ownership Verifier (ROVR): When the "C" flag is set, Registration Ownership Verifier (ROVR): When the "C" flag is set,
this field contains a Crypto-ID. this field contains a Crypto-ID.
This specification uses Status values "Validation Requested" and This specification uses Status values "Validation Requested" and
"Validation Failed", which are defined in [RFC8505]. No other new "Validation Failed", which are defined in [RFC8505]. No other new
Status values are defined. Status values are defined.
4.3. Crypto-ID Parameters Option 4.3. Crypto-ID Parameters Option
This specification defines the Crypto-ID Parameters Option (CIPO). This specification defines the Crypto-ID Parameters Option (CIPO).
It carries the parameters used to form a Crypto-ID. In order to It carries the parameters used to form a Crypto-ID. In order to
provide cryptographic agility [RFC7696], this specification supports provide cryptographic agility [RFC7696], this specification supports
skipping to change at page 8, line 39 skipping to change at page 8, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Crypto-ID Parameters Option Figure 2: Crypto-ID Parameters Option
Type: to be assigned by IANA, see Table 1. Type: to be assigned by IANA, see Table 1.
Length: 8-bit unsigned integer. The length of the option in units
Length: 8-bit unsigned integer. The length of the option in of 8 octets.
units of 8 octets. Pad Length: 8-bit unsigned integer. The length of the Padding
field.
Pad Length: 8-bit unsigned integer. The length of the Padding Reserved: This field is unused. It MUST be initialized to zero by
field. the sender and MUST be ignored by the receiver.
Crypto-Type: The type of cryptographic algorithm used in calculation
Reserved: This field is unused. It MUST be initialized to zero Crypto-ID (see Table 2 in Section 8.3). Although the different
by the sender and MUST be ignored by the receiver. signature schemes target similar cryptographic strength, they rely
on different curves, hash functions, signature algorithms, and/or
Crypto-Type: The type of cryptographic algorithm used in representation conventions.
calculation Crypto-ID (see Table 2 in Section 8.3). Modifier: 8-bit unsigned integer. Set to an arbitrary value by the
Although the different signature schemes target creator of the Crypto-ID. The role of the modifier is to enable
similar cryptographic strength, they rely on the formation of multiple Crypto-IDs from a same key pair, which
different curves, hash functions, signature reduces the traceability and thus improves the privacy of a
algorithms, and/or representation conventions. constrained node that could not maintain many key-pairs.
Public Key: JWK-Encoded Public Key [RFC7517].
Modifier: 8-bit unsigned integer. Set to an arbitrary value by Padding: A variable-length field making the option length a multiple
the creator of the Crypto-ID. The role of the of 8, containing as many octets as specified in the Pad Length
modifier is to enable the formation of multiple field.
Crypto-IDs from a same key pair, which reduces the
traceability and thus improves the privacy of a
constrained node that could not maintain many key-
pairs.
Public Key: JWK-Encoded Public Key [RFC7517].
Padding: A variable-length field making the option length a
multiple of 8, containing as many octets as specified
in the Pad Length field.
The implementation of multiple hash functions in a constrained The implementation of multiple hash functions in a constrained
devices may consume excessive amounts of program memory. devices may consume excessive amounts of program memory.
[I-D.ietf-lwig-curve-representations] provides information on how to [I-D.ietf-lwig-curve-representations] provides information on how to
represent Montgomery curves and (twisted) Edwards curves as curves in represent Montgomery curves and (twisted) Edwards curves as curves in
short-Weierstrass form and illustrates how this can be used to short-Weierstrass form and illustrates how this can be used to
implement elliptic curve computations using existing implementations implement elliptic curve computations using existing implementations
that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4] that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4]
prime curves. prime curves.
skipping to change at page 10, line 27 skipping to change at page 9, line 27
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NDP signature Option Figure 3: NDP signature Option
Type: to be assigned by IANA, see Table 1.
Length: 8-bit unsigned integer. The length of the option in
units of 8 octets.
Pad Length: 8-bit unsigned integer. The length of the Padding
field.
Type: to be assigned by IANA, see Table 1.
Length: 8-bit unsigned integer. The length of the option in units
of 8 octets.
Pad Length: 8-bit unsigned integer. The length of the Padding
field.
Digital Signature: A variable-length field containing a digital Digital Signature: A variable-length field containing a digital
signature. The computation of the digital signature signature. The computation of the digital signature depends on
depends on the Crypto-Type which is found in the the Crypto-Type which is found in the associated CIPO. For the
associated CIPO. For the values of the Crypto-Type values of the Crypto-Type that are defined in ths specification,
that are defined in ths specification, the signature the signature is computed as detailed in Section 6.2.
is computed as detailed in Section 6.2. Padding: A variable-length field making the option length a multiple
of 8, containing as many octets as specified in the Pad Length
Padding: A variable-length field making the option length a field. Typically there is no need of a padding and the field is
multiple of 8, containing as many octets as specified NULL.
in the Pad Length field. Typically there is no need
of a padding and the field is NULL.
5. Protocol Scope 5. Protocol Scope
The scope of the protocol specified here is a 6LoWPAN Low Power Lossy The scope of the protocol specified here is a 6LoWPAN LLN, typically
Network (LLN), typically a stub network connected to a larger IP a stub network connected to a larger IP network via a Border Router
network via a Border Router called a 6LBR per [RFC6775]. A 6LBR has called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to
sufficient capability to satisfy the needs of duplicate address satisfy the needs of duplicate address detection.
detection.
The 6LBR maintains registration state for all devices in its attached The 6LBR maintains registration state for all devices in its attached
LLN. Together with the first-hop router (the 6LR), the 6LBR assures LLN. Together with the first-hop router (the 6LR), the 6LBR assures
uniqueness and grants ownership of an IPv6 address before it can be 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 used in the LLN. This is in contrast to a traditional network that
relies on IPv6 address auto-configuration [RFC4862], where there is relies on IPv6 address auto-configuration [RFC4862], where there is
no guarantee of ownership from the network, and each IPv6 Neighbor no guarantee of ownership from the network, and each IPv6 Neighbor
Discovery packet must be individually secured [RFC3971]. Discovery packet must be individually secured [RFC3971].
---+-------- ............ ---+-------- ............
skipping to change at page 13, line 30 skipping to change at page 12, line 30
| | | |
|<------------------- NA with EARO ---------------------| |<------------------- NA with EARO ---------------------|
| | | |
... ...
| | | |
|--------------- NS with EARO (Crypto-ID) ------------->| |--------------- NS with EARO (Crypto-ID) ------------->|
| | | |
|<------------------- NA with EARO ---------------------| |<------------------- NA with EARO ---------------------|
| | | |
Figure 5: On-link Protocol Operation Figure 5: On-link Protocol Operation
The steps for the registration to the 6LR are as follows: The steps for the registration to the 6LR are as follows:
o Upon the first exchange with a 6LR, a 6LN will be challenged to * Upon the first exchange with a 6LR, a 6LN will be challenged to
prove ownership of the Crypto-ID and the Target Address being prove ownership of the Crypto-ID and the Target Address being
registered in the Neighbor Solicitation message. When a 6LR registered in the Neighbor Solicitation message. When a 6LR
receives a NS(EARO) registration with a new Crypto-ID as a ROVR, 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 and unless the registration is rejected for another reason, it
MUST challenge by responding with a NA(EARO) with a status of
"Validation Requested". "Validation Requested".
* The challenge is triggered when the registration for a Source
o The challenge is triggered when the registration for a Source
Link-Layer Address is not verifiable either at the 6LR or the Link-Layer Address is not verifiable either at the 6LR or the
6LBR. In the latter case, the 6LBR returns a status of 6LBR. In the latter case, the 6LBR returns a status of
"Validation Requested" in the DAR/DAC exchange, which is echoed by "Validation Requested" in the DAR/DAC exchange, which is echoed by
the 6LR in the NA (EARO) back to the registering node. The the 6LR in the NA (EARO) back to the registering node. The
challenge MUST NOT alter a valid registration in the 6LR or the challenge MUST NOT alter a valid registration in the 6LR or the
6LBR. 6LBR.
* Upon receiving a first NA(EARO) with a status of "Validation
o Upon receiving a first NA(EARO) with a status of "Validation
Requested" from a 6LR, the registering node SHOULD retry its Requested" from a 6LR, the registering node SHOULD retry its
registration with a Crypto-ID Parameters Option (CIPO) registration with a Crypto-ID Parameters Option (CIPO)
(Section 4.3) that contains all the necessary material for (Section 4.3) that contains all the necessary material for
building the Crypto-ID, the NonceLN that it generated, and the NDP building the Crypto-ID, the NonceLN that it generated, and the NDP
signature (Section 4.4) option that proves its ownership of the signature (Section 4.4) option that proves its ownership of the
Crypto-ID and intent of registering the Target Address. In Crypto-ID and intent of registering the Target Address. In
subsequent revalidation with the same 6LR, the 6LN MAY try to omit subsequent revalidation with the same 6LR, the 6LN MAY try to omit
the CIPO to save bandwidth, with the expectation that the 6LR the CIPO to save bandwidth, with the expectation that the 6LR
saved it. If the validation fails and it gets challenged again, saved it. If the validation fails and it gets challenged again,
then it SHOULD add the CIPO again. then it SHOULD add the CIPO again.
* In order to validate the ownership, the 6LR performs the same
o In order to validate the ownership, the 6LR performs the same
steps as the 6LN and rebuilds the Crypto-ID based on the steps as the 6LN and rebuilds the Crypto-ID based on the
parameters in the CIPO. If the rebuilt Crypto-ID matches the parameters in the CIPO. If the rebuilt Crypto-ID matches the
ROVR, the 6LN also verifies the signature contained in the NDPSO ROVR, the 6LN also verifies the signature contained in the NDPSO
option. If at that point the signature in the NDPSO option can be option. If at that point the signature in the NDPSO option can be
verified, then the validation succeeds. Otherwise the validation verified, then the validation succeeds. Otherwise the validation
fails. fails.
* If the 6LR fails to validate the signed NS(EARO), it responds with
o 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". After receiving a NA(EARO) with
a status of "Validation Failed", the registering node SHOULD try a status of "Validation Failed", the registering node SHOULD try
to register an alternate target address in the NS message. to register an alternate target address in the NS message.
6.2. NDPSO generation and verification 6.2. NDPSO generation and verification
The signature generated by the 6LN to provide proof-of-ownership of The signature generated by the 6LN to provide proof-of-ownership of
the private-key is carried in the NDP Signature Option (NDPSO). It the private-key is carried in the NDP Signature Option (NDPSO). It
is generated by the 6LN in a fashion that depends on the Crypto-Type is generated by the 6LN in a fashion that depends on the Crypto-Type
(see Table 2 in Section 8.3) chosen by the 6LN as follows: (see Table 2 in Section 8.3) chosen by the 6LN as follows:
o Concatenate the following in the order listed: Concatenate the following in the order listed:
1. The 128-bit Message Type tag [RFC3972] (in network byte
order). For this specification the tag is 0x8701 55c8 0cca
dd32 6ab7 e415 f148 84d0. (The tag value has been generated
by the editor of this specification on random.org).
2. JWK-encoded public key
3. the 16-byte Target Address (in network byte order) sent in the
Neighbor Solicitation (NS) message. It is the address which
the 6LN is registering with the 6LR and 6LBR.
4. NonceLR received from the 6LR (in network byte order) in the
Neighbor Advertisement (NA) message. The random nonce is at
least 6 bytes long as defined in [RFC3971].
5. NonceLN sent from the 6LN (in network byte order). The random
nonce is at least 6 bytes long as defined in [RFC3971].
6. The length of the ROVR field in the NS message containing the
Crypto-ID that was sent.
7. 1-byte (in network byte order) Crypto-Type value sent in the 1. The 128-bit Message Type tag [RFC3972] (in network byte order).
CIPO option. For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415
f148 84d0. (The tag value has been generated by the editor of
this specification on random.org).
2. JWK-encoded public key
3. the 16-byte Target Address (in network byte order) sent in the
Neighbor Solicitation (NS) message. It is the address which the
6LN is registering with the 6LR and 6LBR.
4. NonceLR received from the 6LR (in network byte order) in the
Neighbor Advertisement (NA) message. The random nonce is at
least 6 bytes long as defined in [RFC3971].
5. NonceLN sent from the 6LN (in network byte order). The random
nonce is at least 6 bytes long as defined in [RFC3971].
6. The length of the ROVR field in the NS message containing the
Crypto-ID that was sent.
7. 1-byte (in network byte order) Crypto-Type value sent in the CIPO
option.
o Depending on the Crypto-Type, apply the hash function on this Depending on the Crypto-Type, apply the hash function on this
concatenation. concatenation.
o Depending on the Crypto-Type, sign the hash output with ECDSA (if Depending on the Crypto-Type, sign the hash output with ECDSA (if
curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519 curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519
(PureEdDSA)). (PureEdDSA)).
The 6LR on receiving the NDPSO and CIPO options first Regenerates the The 6LR on receiving the NDPSO and CIPO options first regenerates the
Crypto-ID based on the CIPO option to make sure that the leftmost Crypto-ID based on the CIPO option to make sure that the leftmost
bits up to the size of the ROVR match. Only if the check is bits up to the size of the ROVR match. If and only if the check is
successful, it tries to verify the signature in the NDPSO option successful, it tries to verify the signature in the NDPSO option
using the following. using the following.
o Concatenate the following in the order listed: Concatenate the following in the order listed:
1. 128-bit type tag (in network byte order)
2. JWK-encoded public key received in the CIPO option
3. the 16-byte Target Address (in network byte order) received in
the Neighbor Solicitation (NS) message. It is the address
which the 6LN is registering with the 6LR and 6LBR.
4. NonceLR sent in the Neighbor Advertisement (NA) message. The
random nonce is at least 6 bytes long as defined in [RFC3971].
5. NonceLN received from the 6LN (in network byte order) in the
NS message. The random nonce is at least 6 bytes long as
defined in [RFC3971].
6. The length of the ROVR field in the NS message containing the
Crypto-ID that was received.
7. 1-byte (in network byte order) Crypto-Type value received in 1. 128-bit type tag (in network byte order)
the CIPO option. 2. JWK-encoded public key received in the CIPO option
3. the 16-byte Target Address (in network byte order) received in
the Neighbor Solicitation (NS) message. It is the address which
the 6LN is registering with the 6LR and 6LBR.
4. NonceLR sent in the Neighbor Advertisement (NA) message. The
random nonce is at least 6 bytes long as defined in [RFC3971].
5. NonceLN received from the 6LN (in network byte order) in the NS
message. The random nonce is at least 6 bytes long as defined in
[RFC3971].
6. The length of the ROVR field in the NS message containing the
Crypto-ID that was received.
7. 1-byte (in network byte order) Crypto-Type value received in the
CIPO option.
o Depending on the Crypto-Type indicated by the (6LN) in the CIPO, Depending on the Crypto-Type indicated by the (6LN) in the CIPO,
apply the hash function on this concatenation. apply the hash function on this concatenation.
o Verify the signature with the public-key received and the locally Verify the signature with the public-key received and the locally
computed values. If the verification succeeds, the 6LR and 6LBR computed values. If the verification succeeds, the 6LR and 6LBR add
add the state information about the Crypto-ID, public-key and the state information about the Crypto-ID, public-key and Target
Target Address being registered to their database. Address being registered to their database.
6.3. Multihop Operation 6.3. Multihop Operation
In a multihop 6LoWPAN, the registration with Crypto-ID is propagated In a multihop 6LoWPAN, the registration with Crypto-ID is propagated
to 6LBR as described in this section. If the 6LR and the 6LBR to 6LBR as described in this section. If the 6LR and the 6LBR
maintain a security association, then there is no need to propagate maintain a security association, then there is no need to propagate
the proof of ownership to the 6LBR. the proof of ownership to the 6LBR.
A new device that joins the network auto-configures an address and A new device that joins the network auto-configures an address and
performs an initial registration to a neighboring 6LR with an NS performs an initial registration to a neighboring 6LR with an NS
message that carries an Address Registration Option (EARO) [RFC8505]. message that carries an Address Registration Option (EARO) [RFC8505].
The 6LR validates the address with an 6LBR using a DAR/DAC exchange, 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 and the 6LR confirms (or denies) the address ownership with an NA
message that also carries an Address Registration Option. message that also carries an Address Registration Option.
Figure 6 illustrates a registration flow all the way to a 6LowPAN Figure 6 illustrates a registration flow all the way to a 6LowPAN
Backbone Router (6BBR) [I-D.ietf-6lo-backbone-router]. Backbone Router (6BBR) [6BBR].
6LN 6LR 6LBR 6BBR 6LN 6LR 6LBR 6BBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | | |--------------->| | |
| | Extended DAR | | | | Extended DAR | |
| |-------------->| | | |-------------->| |
| | | | | | | |
| | | proxy NS(EARO) | | | | proxy NS(EARO) |
| | |--------------->| | | |--------------->|
skipping to change at page 16, line 46 skipping to change at page 15, line 30
| | | | <wait> | | | | <wait>
| | | | | | | |
| | | proxy NA(EARO) | | | | proxy NA(EARO) |
| | |<---------------| | | |<---------------|
| | Extended DAC | | | | Extended DAC | |
| |<--------------| | | |<--------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 6: (Re-)Registration Flow Figure 6: (Re-)Registration Flow
In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and
the 6LR receives and relays them to the nodes. 6LR and 6LBR the 6LR receives and relays them to the nodes. 6LR and 6LBR
communicate using ICMPv6 Duplicate Address Request (DAR) and communicate using ICMPv6 Duplicate Address Request (DAR) and
Duplicate Address Confirmation (DAC) messages. The DAR and DAC use Duplicate Address Confirmation (DAC) messages. The DAR and DAC use
the same message format as NS and NA, but have different ICMPv6 type the same message format as NS and NA, but have different ICMPv6 type
values. values.
In AP-ND we extend DAR/DAC messages to carry cryptographically In AP-ND we extend DAR/DAC messages to carry cryptographically
generated ROVR. In a multihop 6LoWPAN, the node exchanges the generated ROVR. In a multihop 6LoWPAN, the node exchanges the
skipping to change at page 17, line 22 skipping to change at page 16, line 5
address (EUI-64) to defend it, if there is an attacker on another address (EUI-64) to defend it, if there is an attacker on another
6LR. 6LR.
7. Security Considerations 7. Security Considerations
7.1. Inheriting from RFC 3971 7.1. Inheriting from RFC 3971
Observations regarding the following threats to the local network in Observations regarding the following threats to the local network in
[RFC3971] also apply to this specification. [RFC3971] also apply to this specification.
Neighbor Solicitation/Advertisement Spoofing Neighbor Solicitation/Advertisement Spoofing Threats in section
9.2.1 of RFC3971 apply. AP-ND counters the threats on NS(EARO)
Threats in section 9.2.1 of RFC3971 apply. AP-ND counters the messages by requiring that the NDP Signature and CIPO options be
threats on NS(EARO) messages by requiring that the NDP Signature present in these solicitations.
and CIPO options be present in these solicitations. Duplicate Address Detection DoS Attack Inside the LLN, Duplicate
Addresses are sorted out using the ROVR, which differentiates it
Duplicate Address Detection DoS Attack from a movement. DAD coming from the backbone are not forwarded
over the LLN, which provides some protection against DoS attacks
Inside the LLN, Duplicate Addresses are sorted out using the ROVR, inside the resource-constrained part of the network. Over the
which differentiates it from a movement. DAD coming from the backbone, the EARO option is present in NS/NA messages. This
backbone are not forwarded over the LLN, which provides some protects against misinterpreting a movement for a duplication, and
protection against DoS attacks inside the resource-constrained enables the backbone routers to determine which one has the
part of the network. Over the backbone, the EARO option is freshest registration and is thus the best candidate to validate
present in NS/NA messages. This protects against misinterpreting the registration for the device attached to it. But this
a movement for a duplication, and enables the backbone routers to specification does not guarantee that the backbone router claiming
determine which one has the freshest registration and is thus the an address over the backbone is not an attacker.
best candidate to validate the registration for the device Router Solicitation and Advertisement Attacks This specification
attached to it. But this specification does not guarantee that does not change the protection of RS and RA which can still be
the backbone router claiming an address over the backbone is not protected by SEND.
an attacker. Replay Attacks Nonces (NonceLR and NonceLN) generated by the 6LR and
6LN guarantees against replay attacks of the NS(EARO).
Router Solicitation and Advertisement Attacks Neighbor Discovery DoS Attack A rogue node that managed to access
the L2 network may form many addresses and register them using AP-
This specification does not change the protection of RS and RA ND. The perimeter of the attack is all the 6LRs in range of the
which can still be protected by SEND. attacker. The 6LR MUST protect itself against overflows and
reject excessive registration with a status 2 "Neighbor Cache
Replay Attacks Full". This effectively blocks another (honest) 6LN from
registering to the same 6LR, but the 6LN may register to other
Nonces (NonceLR and NonceLN) generated by the 6LR and 6LN 6LRs that are in its range but not in that of the rogue.
guarantees against replay attacks of the NS(EARO).
Neighbor Discovery DoS 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.
7.2. Related to 6LoWPAN ND 7.2. Related to 6LoWPAN ND
The threats discussed in 6LoWPAN ND [RFC6775][RFC8505] also apply The threats discussed in 6LoWPAN ND [RFC6775][RFC8505] also apply
here. Compared with SeND, this specification saves about 1Kbyte in here. Compared with SeND, this specification saves about 1Kbyte in
every NS/NA message. Also, this specification separates the every NS/NA message. Also, this specification separates the
cryptographic identifier from the registered IPv6 address so that a cryptographic identifier from the registered IPv6 address so that a
node can have more than one IPv6 address protected by the same node can have more than one IPv6 address protected by the same
cryptographic identifier. SeND forces the IPv6 address to be cryptographic identifier. SeND forces the IPv6 address to be
cryptographic since it integrates the CGA as the IID in the IPv6 cryptographic since it integrates the CGA as the IID in the IPv6
skipping to change at page 20, line 5 skipping to change at page 18, line 10
8.1. CGA Message Type 8.1. CGA Message Type
This document defines a new 128-bit value under the CGA Message Type This document defines a new 128-bit value under the CGA Message Type
[RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0. [RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0.
8.2. IPv6 ND option types 8.2. IPv6 ND option types
This document registers two new ND option types under the subregistry This document registers two new ND option types under the subregistry
"IPv6 Neighbor Discovery Option Formats": "IPv6 Neighbor Discovery Option Formats":
+------------------------------+----------------+-------------------+ +------------------------------+-----------------+---------------+
| Option Name | Suggested | Defined in | | Option Name | Suggested Value | Reference |
| | value | | +==============================+=================+===============+
+------------------------------+----------------+-------------------+ | NDP Signature Option (NDPSO) | 38 | This document |
| Crypto-ID Parameters Option | 39 | This_RFC Section | +------------------------------+-----------------+---------------+
| (CIPO) | | 4.3 | | Crypto-ID Parameters Option | 39 | This document |
| NDP Signature Option (NDPSO) | 38 | This_RFC Section | | (CIPO) | | |
| | | 4.4 | +------------------------------+-----------------+---------------+
+------------------------------+----------------+-------------------+
Table 1: New ND options Table 1: New ND options
8.3. Crypto-Type Subregistry 8.3. Crypto-Type Subregistry
IANA is requested to create a new subregistry "Crypto-Type IANA is requested to create a new subregistry "Crypto-Type
Subregistry" in the "Internet Control Message Protocol version 6 Subregistry" in the "Internet Control Message Protocol version 6
(ICMPv6) Parameters". The registry is indexed by an integer in the (ICMPv6) Parameters". The registry is indexed by an integer in the
interval 0..255 and contains an Elliptic Curve, a Hash Function, a interval 0..255 and contains an Elliptic Curve, a Hash Function, a
Signature Algorithm, and Representation Conventions, as shown in Signature Algorithm, and Representation Conventions, as shown in
Table 2, which together specify a signature scheme. The following Table 2, which together specify a signature scheme. The following
Crypto-Type values are defined in this document: Crypto-Type values are defined in this document:
+----------------+-----------------+-------------+------------------+ +----------------+-----------------+-------------+-----------------+
| Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) | | Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) |
| value | | | | | value | | | |
+----------------+-----------------+-------------+------------------+ +================+=================+=============+=================+
| Elliptic curve | NIST P-256 | Curve25519 | Curve25519 | | Elliptic curve | NIST P-256 | Curve25519 | Curve25519 |
| | [FIPS186-4] | [RFC7748] | [RFC7748] | | | [FIPS186-4] | [RFC7748] | [RFC7748] |
| | | | | +----------------+-----------------+-------------+-----------------+
| Hash function | SHA-256 | SHA-512 | SHA-256 | | Hash function | SHA-256 | SHA-512 | SHA-256 |
| | [RFC6234] | [RFC6234] | [RFC6234] | | | [RFC6234] | [RFC6234] | [RFC6234] |
| | | | | +----------------+-----------------+-------------+-----------------+
| Signature | ECDSA | Ed25519 | ECDSA | | Signature | ECDSA | Ed25519 | ECDSA |
| algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] | | algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] |
| | | | | +----------------+-----------------+-------------+-----------------+
| Representation | Weierstrass, | Edwards, | Weierstrass, | | Representation | Weierstrass, | Edwards, | Weierstrass, |
| conventions | (un)compressed, | compressed, | (un)compressed, | | conventions | (un)compressed, | compressed, | (un)compressed, |
| | MSB/msb first | LSB/lsb | MSB/msb first | | | MSB/msb first | LSB/lsb | MSB/msb first |
| | | first | | | | | first | |
| | | | | +----------------+-----------------+-------------+-----------------+
| Defining | RFC THIS | RFC THIS | RFC THIS | | Defining | This document | This | This document |
| specification | | | | | specification | | document | |
+----------------+-----------------+-------------+------------------+ +----------------+-----------------+-------------+-----------------+
Table 2: Crypto-Types Table 2: Crypto-Types
New Crypto-Type values providing similar or better security (with New Crypto-Type values providing similar or better security (with
less code) may be defined in the future. less code) may be defined in the future.
Assignment of new values for new Crypto-Type MUST be done through Assignment of new values for new Crypto-Type MUST be done through
IANA with "Specification Required" and "IESG Approval" as defined in IANA with "Specification Required" and "IESG Approval" as defined in
[RFC8126]. [RFC8126].
9. Acknowledgments 9. Acknowledgments
Many thanks to Charlie Perkins for his in-depth review and Many thanks to Charlie Perkins for his in-depth review and
constructive suggestions. We are also especially grateful to Robert constructive suggestions. The authors are also especially grateful
Moskowitz for his comments that led to many improvements. to Robert Moskowitz for his comments that led to many improvements.
The authors wish to thank Vijay Gurbani, Al Morton and Adam Montville
10. References for their reviews during the IESG process.
10.1. Normative References
[FIPS186-4] 10. Normative References
FIPS 186-4, "Digital Signature Standard (DSS), Federal
Information Processing Standards Publication 186-4", US
Department of Commerce/National Institute of Standards and
Technology , July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
skipping to change at page 22, line 25 skipping to change at page 20, line 41
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[FIPS186-4]
FIPS 186-4, "Digital Signature Standard (DSS), Federal
Information Processing Standards Publication 186-4", US
Department of Commerce/National Institute of Standards and
Technology , July 2013.
[SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0",
Standards for Efficient Cryptography , June 2009. Standards for Efficient Cryptography , June 2009.
10.2. Informative references 11. Informative references
[breaking-ed25519] [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. for Security", RFC 7748, DOI 10.17487/RFC7748, January
Susella, "Breaking Ed25519 in WolfSSL", Cryptographers' 2016, <https://www.rfc-editor.org/info/rfc7748>.
Track at the RSA Conference , 2018,
<https://link.springer.com/
chapter/10.1007/978-3-319-76953-0_1>.
[I-D.ietf-6lo-backbone-router] [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Signature Algorithm (EdDSA)", RFC 8032,
Backbone Router", draft-ietf-6lo-backbone-router-11 (work DOI 10.17487/RFC8032, January 2017,
in progress), February 2019. <https://www.rfc-editor.org/info/rfc8032>.
[I-D.ietf-lwig-curve-representations] [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
Struik, R., "Alternative Elliptic Curve Representations", "Transmission of IPv6 Packets over IEEE 802.15.4
draft-ietf-lwig-curve-representations-03 (work in Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
progress), March 2019. <https://www.rfc-editor.org/info/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>. <https://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
"Transmission of IPv6 Packets over IEEE 802.15.4 Writing an IANA Considerations Section in RFCs", BCP 26,
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
DOI 10.17487/RFC6282, September 2011, 2014, <https://www.rfc-editor.org/info/rfc7102>.
<https://www.rfc-editor.org/info/rfc6282>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework", "Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013, RFC 7039, DOI 10.17487/RFC7039, October 2013,
<https://www.rfc-editor.org/info/rfc7039>. <https://www.rfc-editor.org/info/rfc7039>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [6BBR] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
for Security", RFC 7748, DOI 10.17487/RFC7748, January Backbone Router", Work in Progress, Internet-Draft, draft-
2016, <https://www.rfc-editor.org/info/rfc7748>. ietf-6lo-backbone-router-13, 26 September 2019,
<https://tools.ietf.org/html/draft-ietf-6lo-backbone-
router-13>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [I-D.ietf-lwig-curve-representations]
Signature Algorithm (EdDSA)", RFC 8032, Struik, R., "Alternative Elliptic Curve Representations",
DOI 10.17487/RFC8032, January 2017, Work in Progress, Internet-Draft, draft-ietf-lwig-curve-
<https://www.rfc-editor.org/info/rfc8032>. representations-08, 24 July 2019,
<https://tools.ietf.org/html/draft-ietf-lwig-curve-
representations-08>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [breaking-ed25519]
Writing an IANA Considerations Section in RFCs", BCP 26, Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R.
RFC 8126, DOI 10.17487/RFC8126, June 2017, Susella, "Breaking Ed25519 in WolfSSL", Cryptographers'
<https://www.rfc-editor.org/info/rfc8126>. Track at the RSA Conference , 2018,
<https://link.springer.com/
chapter/10.1007/978-3-319-76953-0_1>.
Appendix A. Requirements Addressed in this Document Appendix A. Requirements Addressed in this Document
In this section we state requirements of a secure neighbor discovery In this section we state requirements of a secure neighbor discovery
protocol for low-power and lossy networks. protocol for low-power and lossy networks.
o The protocol MUST be based on the Neighbor Discovery Optimization * The protocol MUST be based on the Neighbor Discovery Optimization
for Low-power and Lossy Networks protocol defined in [RFC6775]. for Low-power and Lossy Networks protocol defined in [RFC6775].
RFC6775 utilizes optimizations such as host-initiated interactions RFC6775 utilizes optimizations such as host-initiated interactions
for sleeping resource-constrained hosts and elimination of for sleeping resource-constrained hosts and elimination of
multicast address resolution. multicast address resolution.
* New options to be added to Neighbor Solicitation messages MUST
o New options to be added to Neighbor Solicitation messages MUST
lead to small packet sizes, especially compared with existing lead to small packet sizes, especially compared with existing
protocols such as SEcure Neighbor Discovery (SEND). Smaller protocols such as SEcure Neighbor Discovery (SEND). Smaller
packet sizes facilitate low-power transmission by resource- packet sizes facilitate low-power transmission by resource-
constrained nodes on lossy links. constrained nodes on lossy links.
* The support for this registration mechanism SHOULD be extensible
o The support for this registration mechanism SHOULD be extensible
to more LLN links than IEEE 802.15.4 only. Support for at least 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 the LLN links for which a 6lo "IPv6 over foo" specification
exists, as well as Low-Power Wi-Fi SHOULD be possible. exists, as well as Low-Power Wi-Fi SHOULD be possible.
o As part of this extension, a mechanism to compute a unique * As part of this extension, a mechanism to compute a unique
Identifier should be provided with the capability to form a Link Identifier should be provided with the capability to form a Link
Local Address that SHOULD be unique at least within the LLN Local Address that SHOULD be unique at least within the LLN
connected to a 6LBR. connected to a 6LBR.
* The Address Registration Option used in the ND registration SHOULD
o The Address Registration Option used in the ND registration SHOULD
be extended to carry the relevant forms of Unique Interface be extended to carry the relevant forms of Unique Interface
Identifier. Identifier.
* The Neighbor Discovery should specify the formation of a site-
o The Neighbor Discovery should specify the formation of a site-
local address that follows the security recommendations from local address that follows the security recommendations from
[RFC7217]. [RFC7217].
Appendix B. Representation Conventions Appendix B. Representation Conventions
B.1. Signature Schemes B.1. Signature Schemes
The signature scheme ECDSA256 corresponding to Crypto-Type 0 is The signature scheme ECDSA256 corresponding to Crypto-Type 0 is
ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime ECDSA, as specified in [FIPS186-4], instantiated with the NIST prime
curve P-256, as specified in Appendix B of [FIPS186-4], and the hash curve P-256, as specified in Appendix B of [FIPS186-4], and the hash
skipping to change at page 26, line 15 skipping to change at page 24, line 40
twisted Edwards curve and short-Weierstrass form are as indicated twisted Edwards curve and short-Weierstrass form are as indicated
below. Here, the domain parameters of the Montgomery curve below. Here, the domain parameters of the Montgomery curve
Curve25519 and of the twisted Edwards curve Edwards25519 are as Curve25519 and of the twisted Edwards curve Edwards25519 are as
specified in [RFC7748]; the domain parameters of the elliptic curve specified in [RFC7748]; the domain parameters of the elliptic curve
Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of
[FIPS186-4]. For details of the coordinate transformation referenced [FIPS186-4]. For details of the coordinate transformation referenced
above, see [RFC7748] and [I-D.ietf-lwig-curve-representations]. above, see [RFC7748] and [I-D.ietf-lwig-curve-representations].
General parameters (for all curve models): General parameters (for all curve models):
p 2^{255}-19 p 2^{255}-19
(=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
(=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffed)
ffffffff ffffffed) h 8
n
h 8 723700557733226221397318656304299424085711635937990760600195093828
5454250989
n 72370055773322622139731865630429942408571163593799076060019509382 (=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed)
85454250989
(=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed)
Montgomery curve-specific parameters (for Curve25519): Montgomery curve-specific parameters (for Curve25519):
A 486662 A 486662
B 1
B 1
Gu 9 (=0x9) Gu 9 (=0x9)
Gv
Gv 14781619447589544791020593568409986887264606134616475288964881837 147816194475895447910205935684099868872646061346164752889648818377
755586237401 55586237401
(=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2
(=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 7eced3d9)
29e9c5a2 7eced3d9)
Twisted Edwards curve-specific parameters (for Edwards25519): Twisted Edwards curve-specific parameters (for Edwards25519):
a -1 (-0x01) a -1 (-0x01)
d -121665/121666
d -121665/121666 (=3709570593466943934313808350875456518954211387984321901638878553
3085940283555)
(=370957059346694393431380835087545651895421138798432190163887855 (=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 75eb4dca
33085940283555) 135978a3)
Gx
(=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 151122213495354007725011514095885315114540126930418572060461132839
75eb4dca 135978a3) 49847762202
(=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2 c9562d60
Gx 15112221349535400772501151409588531511454012693041857206046113283 8f25d51a)
949847762202
(=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2
c9562d60 8f25d51a)
Gy 4/5 Gy 4/5
(=4631683569492647816942839400347516314130799386625622561578303360
(=463168356949264781694283940034751631413079938662562256157830336 3165251855960)
03165251855960) (=0x66666666 66666666 66666666 66666666 66666666 66666666 66666666
66666658)
(=0x66666666 66666666 66666666 66666666 66666666 66666666
66666666 66666658)
Weierstrass curve-specific parameters (for Wei25519): Weierstrass curve-specific parameters (for Wei25519):
a 19298681539552699237261830834781317975544997444273427339909597334 a
573241639236 192986815395526992372618308347813179755449974442734273399095973345
73241639236
(=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaa98
aaaaaa98 4914a144) 4914a144)
b
b 55751746669818908907645289078257140818241103727901012315294400837 557517466698189089076452890782571408182411037279010123152944008379
956729358436 56729358436
(=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 260b5e9c
(=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 7710c864)
260b5e9c 7710c864) GX
192986815395526992372618308347813179755449974442734273399095973346
GX 19298681539552699237261830834781317975544997444273427339909597334 52188435546
652188435546 (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa
aaad245a)
(=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa
aaaaaaaa aaad245a)
GY 14781619447589544791020593568409986887264606134616475288964881837
755586237401
(=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 GY
29e9c5a2 7eced3d9) 147816194475895447910205935684099868872646061346164752889648818377
55586237401
(=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2
7eced3d9)
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 06254 MOUGINS - Sophia Antipolis
FRANCE France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Behcet Sarikaya Behcet Sarikaya
Email: sarikaya@ieee.org Email: sarikaya@ieee.org
Mohit Sethi Mohit Sethi
Ericsson Ericsson
Jorvas 02420 FI-02420 Jorvas
Finland Finland
Email: mohit@piuha.net Email: mohit@piuha.net
Rene Struik Rene Struik
Struik Security Consultancy Struik Security Consultancy
Email: rstruik.ext@gmail.com Email: rstruik.ext@gmail.com
 End of changes. 90 change blocks. 
462 lines changed or deleted 364 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/