< draft-ietf-6lo-ap-nd-14.txt   draft-ietf-6lo-ap-nd-15.txt >
skipping to change at page 1, line 14 skipping to change at page 1, line 14
Internet-Draft Cisco Internet-Draft Cisco
Updates: 8505 (if approved) B.S. Sarikaya Updates: 8505 (if approved) B.S. Sarikaya
Intended status: Standards Track Intended status: Standards Track
Expires: 3 August 2020 M.S. Sethi Expires: 3 August 2020 M.S. Sethi
Ericsson Ericsson
R.S. Struik R.S. Struik
Struik Security Consultancy Struik Security Consultancy
31 January 2020 31 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-14 draft-ietf-6lo-ap-nd-15
Abstract Abstract
This document updates the 6LoWPAN Neighbor Discovery (ND) protocol This document updates the 6LoWPAN Neighbor Discovery (ND) protocol
defined in RFC 6775 and RFC 8505. The new extension is called defined in RFC 6775 and RFC 8505. The new extension is called
Address Protected Neighbor Discovery (AP-ND) and it protects the Address Protected Neighbor Discovery (AP-ND) and it protects the
owner of an address against address theft and impersonation attacks owner of an address against address theft and impersonation attacks
in a low-power and lossy network (LLN). Nodes supporting this in a low-power and lossy network (LLN). Nodes supporting this
extension compute a cryptographic identifier (Crypto-ID) and use it extension compute a cryptographic identifier (Crypto-ID) and use it
with one or more of their Registered Addresses. The Crypto-ID with one or more of their Registered Addresses. The Crypto-ID
skipping to change at page 2, line 24 skipping to change at page 2, line 24
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as 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. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Additional References . . . . . . . . . . . . . . . . . . 5
3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5 3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5
4. New Fields and Options . . . . . . . . . . . . . . . . . . . 5 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6
4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 5 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7
4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9 4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9
5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 10 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 11 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 12
6.2. NDPSO generation and verification . . . . . . . . . . . . 13 6.2. NDPSO generation and verification . . . . . . . . . . . . 14
6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 15 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 16 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 17
7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 17 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18
7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 17 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 18
7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 17 7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 18
7.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 18 7.5. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 19
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19
8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 18 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 18 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 19
8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 18 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 20
10. Normative References . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. Informative references . . . . . . . . . . . . . . . . . . . 20 10. Normative References . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Requirements Addressed in this Document . . . . . . 22 11. Informative references . . . . . . . . . . . . . . . . . . . 22
Appendix B. Representation Conventions . . . . . . . . . . . . . 23 Appendix A. Requirements Addressed in this Document . . . . . . 24
B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Representation Conventions . . . . . . . . . . . . . 24
B.2. Integer Representation for ECDSA signatures . . . . . . . 24 B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 24
B.3. Alternative Representations of Curve25519 . . . . . . . . 24 B.2. Integer Representation for ECDSA signatures . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 B.3. Alternative Representations of Curve25519 . . . . . . . . 25
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 (IPv6 ND) (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 compared to the Duplicate Address Detection (DAD) mechanism multicast compared to the Duplicate Address Detection (DAD) mechanism
defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration
skipping to change at page 4, line 29 skipping to change at page 4, line 29
2. Terminology 2. Terminology
2.1. BCP 14 2.1. BCP 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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. Abbreviations
The reader may get additional context for this specification from the
following references:
* "SEcure Neighbor Discovery (SEND)" [RFC3971],
* "Cryptographically Generated Addresses (CGA)" [RFC3972],
* "Neighbor Discovery for IP version 6" [RFC4861] ,
* "IPv6 Stateless Address Autoconfiguration" [RFC4862], and
* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals " [RFC4919].
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
ARO: Address Registration Option ARO: Address Registration Option
EARO: Extended Address Registration Option EARO: Extended 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
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: Routing Protocol for LLNs
RA: Router Advertisement RA: Router Advertisement
RS: Router Solicitation RS: Router Solicitation
RSAO: RSA Signature Option RSAO: RSA Signature Option
TID: Transaction ID TID: Transaction ID
2.3. Additional References
The reader may get additional context for this specification from the
following references:
* "SEcure Neighbor Discovery (SEND)" [RFC3971],
* "Cryptographically Generated Addresses (CGA)" [RFC3972],
* "Neighbor Discovery for IP version 6" [RFC4861] ,
* "IPv6 Stateless Address Autoconfiguration" [RFC4862], and
* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals " [RFC4919].
3. Updating RFC 8505 3. Updating RFC 8505
Section 5.3 of [RFC8505] introduces the ROVR as a generic object that
is designed for backward compatibility with the capability to
introduce new computation methods in the future. Section 7.3
discusses collisions when heterogeneous methods to compute the ROVR
field coexist inside a same network.
[RFC8505] was designed in preparation for this specification, which
is the RECOMMENDED method for building a ROVR field.
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 transported in the ROVR field and used
of an address that is being registered by means of [RFC8505]. The to prove indirectly the ownership of an address that is being
Crypto-ID is derived from a cryptographic public key and additional registered by means of [RFC8505]. The Crypto-ID is derived from a
parameters. The proof requires the support of Elliptic Curve cryptographic public key and additional parameters.
Cryptography (ECC) and that of a hash function as detailed in
Section 6.2. To enable the verification of the proof, the The proof requires the support of Elliptic Curve Cryptography (ECC)
registering node needs to supply certain parameters including a Nonce and that of a hash function as detailed in Section 6.2. To enable
and a signature that will demonstrate that the node has the private- the verification of the proof, the registering node needs to supply
key corresponding to the public-key used to build the Crypto-ID. certain parameters including a Nonce and a signature that will
demonstrate that the node has the private-key corresponding to the
public-key used to build the Crypto-ID.
The elliptic curves and the hash functions that can be used with this The elliptic curves and the hash functions that can be used with this
specification are listed in Table 2 in Section 8.3. The signature specification are listed in Table 2 in Section 8.3. The signature
scheme that specifies which combination is used is signaled by a scheme that specifies which combination is used is signaled by a
Crypto-Type in the CIPO (see Section 4.3). Crypto-Type in a new IPv6 ND Crypto-ID Parameters Option (CIPO, see
Section 4.3) that contains the parameters that are necessary for the
The NS(EARO) is extended to transport a new Crypto-ID Parameters proof, a Nonce option ([RFC3971]) and a NDP Signature option
Option (CIPO, see Section 4.3) that contains the parameters that are (Section 4.4). The NA(EARO) is modified to enable a challenge and
necessary for the proof, a Nonce option ([RFC3971]) and a NDP transport a Nonce option as well.
Signature option (Section 4.4). The NA(EARO) is modified to enable a
challenge and transport a Nonce option as well.
4. New Fields and Options 4. New Fields and Options
4.1. New Crypto-ID 4.1. New Crypto-ID
The Crypto-ID is transported in the ROVR field of the EARO option and The Crypto-ID is transported in the ROVR field of the EARO option and
the EDAR message, and is associated with the Registered Address at the EDAR message, and is associated with the Registered Address at
the 6LR and the 6LBR. The ownership of a Crypto-ID can be the 6LR and the 6LBR. The ownership of a Crypto-ID can be
demonstrated by cryptographic mechanisms, and by association, the demonstrated by cryptographic mechanisms, and by association, the
ownership of the Registered Address can be acertained. ownership of the Registered Address can be acertained.
skipping to change at page 6, line 21 skipping to change at page 6, line 31
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 to enable the use of the
ROVR field to transport the Crypto-ID.
The resulting format is 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) ...
skipping to change at page 7, line 21 skipping to change at page 7, line 35
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 The CIPO carries the parameters used to form a Crypto-ID.
provide cryptographic agility [RFC7696], this specification supports
different elliptic curves, indicated by a Crypto-Type field. NIST In order to provide cryptographic agility [RFC7696], this
P-256 [FIPS186-4] MUST be supported by all implementations. The specification supports different elliptic curves, indicated by a
Edwards-Curve Digital Signature Algorithm (EdDSA) curve Ed25519 Crypto-Type field:
(PureEdDSA) [RFC8032] MAY be supported as an alternate.
* NIST P-256 [FIPS186-4] MUST be supported by all implementations.
* The Edwards-Curve Digital Signature Algorithm (EdDSA) curve
Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternate.
* the specification is open to future extensions for different
cryptographic algorithms and longer keys.
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 |Reserved1| Public Key Length | | Type | Length |Reserved1| Public Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Type | Modifier | Reserved2 | | Crypto-Type | Modifier | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
skipping to change at page 9, line 13 skipping to change at page 9, line 35
Appendix B. Appendix B.
4.4. NDP Signature Option 4.4. NDP Signature Option
The format of the NDP Signature Option (NDPSO) is illustrated in The format of the NDP Signature Option (NDPSO) is illustrated in
Figure 3. Figure 3.
As opposed to the RSA Signature Option (RSAO) defined in section 5.2. As opposed to the RSA Signature Option (RSAO) defined in section 5.2.
of SEND [RFC3971], the NDPSO does not have a key hash field. The of SEND [RFC3971], the NDPSO does not have a key hash field. The
hash that can be used as index is the 128 leftmost bits of the ROVR hash that can be used as index is the 128 leftmost bits of the ROVR
field in the EARO. The CIPO may be present in the same message as field in the EARO.
the NDPSO. If not, it an be found in an abstract table that was
created by a previous message and indexed by the hash. The CIPO may be present in the same message as the NDPSO. If not, it
can be found in an abstract table that was created by a previous
message and indexed by the hash.
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 | Pad Length | | | Type | Length | Pad Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
skipping to change at page 11, line 23 skipping to change at page 12, line 12
node becomes the owner of the registered address and the address is node becomes the owner of the registered address and the address is
bound to the Crypto-ID in the 6LR/6LBR registry. bound to the Crypto-ID in the 6LR/6LBR registry.
This specification enables the 6LR to verify the ownership of the This specification enables the 6LR to verify the ownership of the
binding at any time assuming that the "C" flag is set. The binding at any time assuming that the "C" flag is set. The
verification prevents other nodes from stealing the address and verification prevents other nodes from stealing the address and
trying to attract traffic for that address or use it as their source trying to attract traffic for that address or use it as their source
address. address.
A node may use multiple IPv6 addresses at the same time. The node A node may use multiple IPv6 addresses at the same time. The node
may use the same Crypto-ID, to prove the ownership of multiple IPv6 MAY use the same Crypto-ID, to prove the ownership of multiple IPv6
addresses. The separation of the address and the cryptographic addresses. The separation of the address and the cryptographic
material avoids the constrained device to compute multiple keys for material avoids the constrained device to compute multiple keys for
multiple addresses. The registration process allows the node to use multiple addresses. The registration process allows the node to use
the same Crypto-ID for all of its addresses. the same Crypto-ID for all of its addresses.
6.1. First Exchange with a 6LR 6.1. First Exchange with a 6LR
A 6LN registers to a 6LR that is one hop away from it with the "C" 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 flag set in the EARO, indicating that the ROVR field contains a
Crypto-ID. The Target Address in the NS message indicates the IPv6 Crypto-ID. The Target Address in the NS message indicates the IPv6
skipping to change at page 16, line 40 skipping to change at page 17, line 34
enables the backbone routers to determine which one has the enables the backbone routers to determine which one has the
freshest registration and is thus the best candidate to validate freshest registration and is thus the best candidate to validate
the registration for the device attached to it. But this the registration for the device attached to it. But this
specification does not guarantee that the backbone router claiming specification does not guarantee that the backbone router claiming
an address over the backbone is not an attacker. an address over the backbone is not an attacker.
Router Solicitation and Advertisement Attacks: This specification Router Solicitation and Advertisement Attacks: This specification
does not change the protection of RS and RA which can still be does not change the protection of RS and RA which can still be
protected by SEND. protected by SEND.
Replay Attacks Nonces (NonceLR and NonceLN) generated by the 6LR and Replay Attacks Using Nonces (NonceLR and NonceLN) generated by both
6LN guarantees against replay attacks of the NS(EARO). the 6LR and 6LN provides an efficient protection against replay
attacks of challenge response flow. The quality of the protection
still depends on the quality of the Nonce, in particular of a
random generator if they are computed that way.
Neighbor Discovery DoS Attack: A rogue node that managed to access Neighbor Discovery DoS Attack: A rogue node that managed to access
the L2 network may form many addresses and register them using AP- 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 ND. The perimeter of the attack is all the 6LRs in range of the
attacker. The 6LR MUST protect itself against overflows and attacker. The 6LR MUST protect itself against overflows and
reject excessive registration with a status 2 "Neighbor Cache reject excessive registration with a status 2 "Neighbor Cache
Full". This effectively blocks another (honest) 6LN from Full". This effectively blocks another (honest) 6LN from
registering to the same 6LR, but the 6LN may register to other 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. 6LRs that are in its range but not in that of the rogue.
skipping to change at page 18, line 12 skipping to change at page 19, line 12
should be particularly aware that a secure implementation of Ed25519 should be particularly aware that a secure implementation of Ed25519
requires a protected implementation of the hash function SHA-512, requires a protected implementation of the hash function SHA-512,
whereas this is not required with implementations of SHA-256 used whereas this is not required with implementations of SHA-256 used
with ECDSA. with ECDSA.
7.5. Cross-Protocol Attacks 7.5. Cross-Protocol Attacks
The same private key MUST NOT be reused with more than one signature The same private key MUST NOT be reused with more than one signature
scheme in this specification. scheme in this specification.
7.6. Compromised 6LR
This specification distributes the challenge and its validation at
the edge of the network, between the 6LN and its 6LR. The central
6LBR is offloaded, which avoids DOS attacks targeted at that central
entity. This also saves back and forth exchanges across a
potentially large and constrained network.
The downside is that the 6LBR needs to trust the 6LR for performing
the checking adequately, and the communication between the 6LR and
the 6LBR must be protected to avoid tempering with the result of the
test.
If a 6LR is compromised, it may pretend that it owns any address and
defeat the protection. It may also admit any rogue and let it take
ownership of any address in the network, provided that the 6LR knows
the ROVR field used by the real owner of the address.
8. IANA considerations 8. IANA considerations
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
skipping to change at page 19, line 41 skipping to change at page 21, line 10
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 either "Specification Required" or "IESG Approval" as IANA with either "Specification Required" or "IESG Approval" as
defined in [RFC8126]. defined in [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. The authors are also especially grateful constructive suggestions. The authors are also especially grateful
to Robert 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 Eric Vyncke, Vijay Gurbani, Al Morton and The authors wish to thank Mirja Kuhlewind, Eric Vyncke, Vijay
Adam Montville for their constructive reviews during the IESG Gurbani, Al Morton and Adam Montville for their constructive reviews
process. during the IESG process.
10. Normative References 10. Normative References
[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>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
 End of changes. 20 change blocks. 
74 lines changed or deleted 119 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/