< draft-ietf-6lo-ap-nd-03.txt   draft-ietf-6lo-ap-nd-04.txt >
6lo B. Sarikaya 6lo B. Sarikaya
Internet-Draft Internet-Draft
Updates: 6775 (if approved) P. Thubert Updates: 6775 (if approved) P. Thubert
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: March 25, 2018 M. Sethi Expires: May 18, 2018 M. Sethi
Ericsson Ericsson
September 21, 2017 November 14, 2017
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-03 draft-ietf-6lo-ap-nd-04
Abstract Abstract
This document defines an extension to 6LoWPAN Neighbor Discovery RFC This document defines an extension to 6LoWPAN Neighbor Discovery RFC
6775. Nodes supporting this extension compute a cryptographic Owner 6775. Nodes supporting this extension compute a cryptographic Owner
Unique Interface ID and associate it with one or more of their Unique Interface ID and associate it with one or more of their
Registered Addresses. Once an address is registered with a Registered Addresses. Once an address is registered with a
Cryptographic ID, only the owner of that ID can modify the anchor Cryptographic ID, only the owner of that ID can modify the anchor
state information of the Registered Address, and Source Address state information of the Registered Address, and Source Address
Validation can be enforced. Validation can be enforced.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 March 25, 2018. This Internet-Draft will expire on May 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4 3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4
4. New Fields and Options . . . . . . . . . . . . . . . . . . . 5 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 5
4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 5 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6
4.3. New Crypto-ID Parameters Option . . . . . . . . . . . . . 7 4.3. New Crypto-ID Parameters Option . . . . . . . . . . . . . 7
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Protocol Scope . . . . . . . . . . . . . . . . . . . . . 8 5.1. Protocol Scope . . . . . . . . . . . . . . . . . . . . . 9
5.2. Protocol Flows . . . . . . . . . . . . . . . . . . . . . 9 5.2. Protocol Flows . . . . . . . . . . . . . . . . . . . . . 10
5.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 11 5.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Crypto Type Registry . . . . . . . . . . . . . . . . . . 13 7.1. Crypto Type Registry . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative references . . . . . . . . . . . . . . . . . 14
10.2. Informative references . . . . . . . . . . . . . . . . . 14
Appendix A. Requirements Addressed in this Document . . . . . . 16 Appendix A. Requirements Addressed in this Document . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
"Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775]
(6LoWPAN ND) adapts the classical IPv6 ND protocol [RFC4861][RFC4862] (6LoWPAN ND) adapts the classical IPv6 ND protocol [RFC4861][RFC4862]
(IPv6 ND) for operations over a constrained low-power and lossy (IPv6 ND) for operations over a constrained low-power and lossy
network (LLN). In particular, 6LoWPAN ND introduces a unicast host network (LLN). In particular, 6LoWPAN ND introduces a unicast host
address registration mechanism that contributes to reduce the use of address registration mechanism that contributes to reduce the use of
skipping to change at page 4, line 26 skipping to change at page 4, line 22
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Readers are expected to be familiar with all the terms and concepts Readers are expected to be familiar with all the terms and concepts
that are discussed in [RFC3971], [RFC3972], [RFC4861], [RFC4919], that are discussed in [RFC3971], [RFC3972], [RFC4861], [RFC4919],
[RFC6775], and [I-D.ietf-6lo-backbone-router] which proposes an [RFC6775], and [I-D.ietf-6lo-backbone-router] which proposes an
evolution of [RFC6775] for wider applicability. evolution of [RFC6775] for wider applicability.
This document defines Crypto-ID as an identifier of variable size This document defines Crypto-ID as an identifier of variable size
which in most cases is 64 bits long. It is generated using which in most cases is 64 bits long. It is generated using
cryptographic means explained later in this document Section 4.1. cryptographic means explained later in this document Section 4.1.
"Elliptic Curves for Security" [RFC7748] and "Edwards-Curve Digital
Signature Algorithm (EdDSA)" [RFC8032] provides information on
Elliptic Curve Cryptography (ECC) and a (twisted) Edwards curve,
Ed25519, which can be used with this specification. "Alternative
Elliptic Curve Representations"
[I-D.struik-lwip-curve-representations] provides additional
information on how to represent Montgomery curves and (twisted)
Edwards curves as curves in short-Weierstrass form and illustrates
how this can be used to implement elliptic curve computations using
existing implementations that already implement, e.g., ECDSA and ECDH
using NIST [FIPS186-4] prime curves.
The document also conforms to the terms and models described in The document also conforms to the terms and models described in
[RFC5889] and uses the vocabulary and the concepts defined in [RFC5889] and uses the vocabulary and the concepts defined in
[RFC4291] for the IPv6 Architecture. Finally, common terminology [RFC4291] for the IPv6 Architecture. Finally, common terminology
related to Low power And Lossy Networks (LLN) defined in [RFC7102] is related to Low power And Lossy Networks (LLN) defined in [RFC7102] is
also used. also used.
3. Updating RFC 6775 3. Updating RFC 6775
This specification defines a cryptographic identifier (Crypto-ID) This specification defines a cryptographic identifier (Crypto-ID)
skipping to change at page 5, line 38 skipping to change at page 5, line 46
private key pair. The digital signature is constructed by using the private key pair. The digital signature is constructed by using the
6LN's private key over its EUI-64 (MAC) address. The signature value 6LN's private key over its EUI-64 (MAC) address. The signature value
is computed using the ECDSA signature algorithm and the hash function is computed using the ECDSA signature algorithm and the hash function
used is SHA-256 [RFC6234]. Public Key is the most important used is SHA-256 [RFC6234]. Public Key is the most important
parameter in CGA Parameters (sent by 6LN in an NS message). ECC parameter in CGA Parameters (sent by 6LN in an NS message). ECC
Public Key could be in uncompressed form or in compressed form where Public Key could be in uncompressed form or in compressed form where
the first octet of the OCTET STRING is 0x04 and 0x02 or 0x03, the first octet of the OCTET STRING is 0x04 and 0x02 or 0x03,
respectively. Point compression can further reduce the key size by respectively. Point compression can further reduce the key size by
about 32 octets. about 32 octets.
To support cryptographic algorithm agility [RFC7696], Edwards-Curve
Digital Signature Algorithm (EdDSA) curve Ed25519ph (pre-hashing)
[RFC8032] can also be used as an alternate to the default NIST P-256
[FIPS186-4]. This is indicated by 6LN using the Crypto Type field in
the CIPO option. The document currently only defines two possible
values for the Crypto Type field. A value of 0 indicates that NIST
P-256 is used for the signature operation and SHA-256 as the hash
algorithm. A value of 1 indicates that Ed25519ph is used for the
signature operation and SHA-256 as the hash algorithm. New values
for the Crypto Type maybe defined in the future for new curves.
The Crypto-ID is computed as follows: The Crypto-ID is computed as follows:
1. the modifier is set to a random or pseudo-random 128-bit value 1. the modifier is set to a random or pseudo-random 128-bit value
2. the modifier, 9 zero octets and the ECC public key are 2. the modifier, 9 zero octets and the ECC public key are
concatenated from left to right. concatenated from left to right.
3. the SHA-256 algorithm is applied on the concatenation 3. the SHA-256 algorithm is applied on the concatenation
4. the 112 leftmost bits of the hash value are retained 4. the 112 leftmost bits of the hash value are retained
5. the modifier value, the subnet prefix and the encoded public key 5. the modifier value, the EUI-64 transformation of the device Link
are concatenated from left to right Layer Address and the encoded public key are concatenated from
left to right
6. NIST P-256 is executed on the concatenation 6. Digital signature (NIST P-256 or EdDSA) is executed on the
7. the leftmost bits of the result are used as the Crypto-ID. concatenation
With this specification, the last 64 bits are retained, but it could 7. the leftmost bits of the resulting signature are used as the
be expanded to more bits in the future by increasing the size of the Crypto-ID.
OUID field.
To support cryptographic algorithm agility [RFC7696], Curve25519 With this specification, only 64 bits are retained, but it could be
[RFC7748] can also be used instead of NIST P-256. This is indicated expanded to more bits in the future by increasing the size of the
by 6LN using the Crypto Type field in the CIPO option. The document OUID field.
currently only defines two possible values for the Crypto Type field.
A value of 0 indicates that NIST P-256 is used for the signature
operation and SHA-256 as the hash algorithm. A value of 1 indicates
that Curve25519 is used for the signature operation and SHA-256 as
the hash algorithm. New values for the Crypto Type maybe defined in
the future for new curves.
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 | Reserved | | Type | Length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 14 skipping to change at page 8, line 46
Type: CIPO, to be assigned by IANA. Type: CIPO, to be assigned by IANA.
Length: The length of the option in units of 8 octets. Length: The length of the option in units of 8 octets.
Pad Length: The length of the Padding field. Pad Length: The length of the Padding field.
Crypto Type: The type of cryptographic algorithm used in Crypto Type: The type of cryptographic algorithm used in
calculation Crypto-ID. Default value of all zeros calculation Crypto-ID. Default value of all zeros
indicate NIST P-256. A value of 1 is assigned for indicate NIST P-256. A value of 1 is assigned for
Curve25519. New values may be defined later. Ed25519ph. New values may be defined later.
Modifier: 128 bit random value. Modifier: 128 bit random value.
Subnet Prefix: 64 bit subnet prefix. Subnet Prefix: 64 bit subnet prefix.
Public Key: ECC public key of 6LN. Public Key: ECC public key of 6LN.
Padding: A variable-length field making the option length a Padding: A variable-length field making the option length a
multiple of 8, containing as many octets as specified multiple of 8, containing as many octets as specified
in the Pad Length field. in the Pad Length field.
skipping to change at page 13, line 14 skipping to change at page 13, line 35
7. IANA considerations 7. IANA considerations
IANA is requested to assign two new option type values for the CIPO IANA is requested to assign two new option type values for the CIPO
under the subregistry "IPv6 Neighbor Discovery Option Formats". under the subregistry "IPv6 Neighbor Discovery Option Formats".
7.1. Crypto Type Registry 7.1. Crypto Type Registry
The following Crypto Type values are defined in this document: The following Crypto Type values are defined in this document:
+-------------------+-----------------------------------------+ +-------------------+--------------------------------------------+
| Crypto Type value | Algorithms | | Crypto Type value | Algorithms |
+-------------------+-----------------------------------------+ +-------------------+--------------------------------------------+
| 0 | NIST P-256, SHA-256 [RFC6234] | | 0 | NIST P-256 [FIPS186-4] , SHA-256 [RFC6234] |
| 1 | Curve25519 [RFC7748], SHA-256 [RFC6234] | | 1 | Ed25519ph [RFC8032], SHA-256 [RFC6234] |
+-------------------+-----------------------------------------+ +-------------------+--------------------------------------------+
Table 1: Crypto Types Table 1: Crypto Types
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].
8. Acknowledgements 8. Acknowledgements
Special 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 grateful to Rene Struik and constructive suggestions. We are also especially grateful to Rene
Robert Moskowitz for their comments that lead to many improvements to Struik and Robert Moskowitz for their comments that lead to many
this document. improvements to this document, in particular WRT ECC computation and
references.
9. Change Log
o submitted version -00 as a working group draft after adoption, and
corrected the order of authors
o submitted version -01 with no changes
o submitted version -02 with these changes: Moved Requirements to
Appendix A, Section 4.2 moved to Section 3, New section 4 on New
Fields and Options, Section 4 changed to Protocol Overview as
Section 5 with Protocol Scope and Flows subsections.
o submitted version -03 addressing Charlie Perkins' comments 9. References
10. References 9.1. Normative References
10.1. Normative References
[I-D.ietf-6lo-rfc6775-update] [I-D.ietf-6lo-rfc6775-update]
Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update Thubert, P., Nordmark, E., Chakrabarti, S., and C.
to 6LoWPAN ND", draft-ietf-6lo-rfc6775-update-09 (work in Perkins, "An Update to 6LoWPAN ND", draft-ietf-6lo-
progress), September 2017. rfc6775-update-10 (work in progress), October 2017.
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
skipping to change at page 14, line 36 skipping to change at page 14, line 47
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[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
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
10.2. Informative references 9.2. Informative references
[FIPS186-4]
"FIPS Publication 186-4: Digital Signature Standard", July
2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-04 (work in progress), July 2017. backbone-router-04 (work in progress), July 2017.
[I-D.struik-lwip-curve-representations]
Struik, R., "Alternative Elliptic Curve Representations",
draft-struik-lwip-curve-representations-00 (work in
progress), October 2017.
[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>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
skipping to change at page 16, line 14 skipping to change at page 16, line 29
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
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.
 End of changes. 21 change blocks. 
59 lines changed or deleted 77 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/