rfc8928xml2.original.xml   rfc8928.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
nsus="true" docName="draft-ietf-6lo-ap-nd-23" indexInclude="true" ipr="trust2009
<?rfc toc="yes"?> 02" number="8928" prepTime="2020-11-18T12:58:54" scripts="Common,Latin" sortRefs
<?rfc tocompact="yes"?> ="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" upda
<?rfc tocdepth="3"?> tes="8505" xml:lang="en">
<?rfc tocindent="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd-23" rel="pre
<?rfc symrefs="yes"?> v"/>
<?rfc sortrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc8928" rel="alternate"/>
<?rfc comments="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc inline="yes"?> <front>
<?rfc compact="no"?> <title abbrev="Address Protection ND for LLN">Address-Protected Neighbor Dis
<?rfc subcompact="no"?> covery for Low-Power and Lossy Networks</title>
<?rfc authorship="yes"?> <seriesInfo name="RFC" value="8928" stream="IETF"/>
<?rfc tocappendix="yes"?> <author initials="P." surname="Thubert" fullname="Pascal Thubert" role="edit
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902 or">
' tocInclude="true" obsoletes="" updates="8505" consensus="true" submissionType <organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</o
="IETF" xml:lang="en" version="3" docName="draft-ietf-6lo-ap-nd-23" > rganization>
<address>
<front> <postal>
<street>Building D</street>
<title abbrev='Address Protection ND for LLN'> <street>45 Allee des Ormes - BP1200</street>
Address Protected Neighbor Discovery for Low-power and Lossy Networks <city>MOUGINS - Sophia Antipolis</city>
</title> <code>06254</code>
<country>France</country>
<author initials='P.' surname='Thubert' fullname='Pascal Thubert' role='edit </postal>
or'> <phone>+33 497 23 26 34</phone>
<organization abbrev='Cisco'>Cisco Systems, Inc</organization> <email>pthubert@cisco.com</email>
<address> </address>
<postal>
<street>Building D</street>
<street>45 Allee des Ormes - BP1200 </street>
<city>MOUGINS - Sophia Antipolis</city>
<code>06254</code>
<country>FRANCE</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author> </author>
<author initials='B.' surname='Sarikaya' fullname='Behcet Sarikaya'> <author initials="B." surname="Sarikaya" fullname="Behcet Sarikaya">
<organization/> <organization showOnFrontPage="true"/>
<address> <address>
<postal> <postal>
<street/> <street/>
<street/> <street/>
<city/> <region/> <code/> <city/>
<country/> <region/>
</postal> <code/>
<email>sarikaya@ieee.org</email> <country/>
</address> </postal>
<email>sarikaya@ieee.org</email>
</address>
</author> </author>
<author initials="M." surname="Sethi" fullname="Mohit Sethi">
<author initials='M.' surname='Sethi' fullname='Mohit Sethi'> <organization showOnFrontPage="true">Ericsson</organization>
<organization>Ericsson</organization> <address>
<address> <postal>
<postal> <street/>
<street/> <city>Jorvas</city>
<city>Jorvas</city> <region/> <code>02420</code> <region/>
<country>Finland</country> <code>02420</code>
</postal> <country>Finland</country>
<email>mohit@piuha.net</email> </postal>
</address> <email>mohit@piuha.net</email>
</address>
</author> </author>
<author initials="R." surname="Struik" fullname="Rene Struik">
<author initials='R.' surname='Struik' fullname='Rene Struik'> <organization showOnFrontPage="true">Struik Security Consultancy</organiza
<organization>Struik Security Consultancy</organization> tion>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <region/> <code/> <city/>
<country/> <region/>
</postal> <code/>
<email>rstruik.ext@gmail.com</email> <country/>
</address> </postal>
<email>rstruik.ext@gmail.com</email>
</address>
</author> </author>
<date month="11" year="2020"/>
<workgroup>6lo</workgroup>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">
This document updates the IPv6 over Low-Power Wireless
Personal Area Network (6LoWPAN) Neighbor Discovery (ND)
protocol defined in RFCs 6775 and 8505. The new extension
is called Address-Protected Neighbor Discovery (AP-ND), and
it protects the owner of an address against address theft
and impersonation attacks in a Low-Power and Lossy Network
(LLN). Nodes supporting this extension compute a
cryptographic identifier (Crypto-ID), and use it with one
or more of their Registered Addresses. The Crypto-ID
identifies the owner of the Registered Address and can be
used to provide proof of ownership of the Registered
Addresses. Once an address is registered with the Crypto-ID
and a proof of ownership is provided, only the owner of
that address can modify the registration information,
thereby enforcing Source Address Validation.
</t>
</abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8928" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-terminology">Terminology</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><
xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-re
quirements-language">Requirements Language</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><
xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.
2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ba
ckground">Background</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent=
"2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-abbreviations">Abbrevi
ations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-updating-rfc-8505">Updating RFC 85
05</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-new-fields-and-options">New Fields
and Options</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-new-crypto-id">New Cry
pto-ID</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-updated-earo">Updated
EARO</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-crypto-id-parameters-o
ption">Crypto-ID Parameters Option</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
"4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ndp-signature-option">
NDP Signature Option</xref></t>
</li>
<li pn="section-toc.1-1.4.2.5">
<t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent=
"4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-extensions-to-the-capa
bilit">Extensions to the Capability Indication Option</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-protocol-scope">Protocol Scope</xr
ef></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-protocol-flows">Protocol Flows</xr
ef></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-first-exchange-with-a-
6lr">First Exchange with a 6LR</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ndpso-generation-and-v
erifi">NDPSO Generation and Verification</xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-multi-hop-operation">M
ulti-Hop Operation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
"7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-brown-field">Brown Fie
ld</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent=
"7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-threats-identified-in-
rfc-3">Threats Identified in RFC 3971</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent=
"7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-related-to-6lowpan-nd"
>Related to 6LoWPAN ND</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4">
<t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent=
"7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-compromised-6lr">Compr
omised 6LR</xref></t>
</li>
<li pn="section-toc.1-1.7.2.5">
<t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent=
"7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rovr-collisions">ROVR
Collisions</xref></t>
</li>
<li pn="section-toc.1-1.7.2.6">
<t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent=
"7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-implementation-attacks
">Implementation Attacks</xref></t>
</li>
<li pn="section-toc.1-1.7.2.7">
<t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent=
"7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-cross-algorithm-and-cr
oss-p">Cross-Algorithm and Cross-Protocol Attacks</xref></t>
</li>
<li pn="section-toc.1-1.7.2.8">
<t indent="0" pn="section-toc.1-1.7.2.8.1"><xref derivedContent=
"7.8" format="counter" sectionFormat="of" target="section-7.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-public-key-validation"
>Public Key Validation</xref></t>
</li>
<li pn="section-toc.1-1.7.2.9">
<t indent="0" pn="section-toc.1-1.7.2.9.1"><xref derivedContent=
"7.9" format="counter" sectionFormat="of" target="section-7.9"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-correlating-registrati
ons">Correlating Registrations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-cga-message-type">CGA
Message Type</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-crypto-type-subregistr
y">Crypto-Type Subregistry</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-ipv6-nd-option-types">
IPv6 ND Option Types</xref></t>
</li>
<li pn="section-toc.1-1.8.2.4">
<t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent=
"8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-new-6lowpan-capability
-bit">New 6LoWPAN Capability Bit</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-requirements-ad
dressed-in-t">Requirements Addressed in This Document</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-representation-
conventions">Representation Conventions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent
="B.1" format="counter" sectionFormat="of" target="section-b.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-signature-schemes">Si
gnature Schemes</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent
="B.2" format="counter" sectionFormat="of" target="section-b.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-representation-of-ecd
sa-sig">Representation of ECDSA Signatures</xref></t>
</li>
<li pn="section-toc.1-1.11.2.3">
<t indent="0" pn="section-toc.1-1.11.2.3.1"><xref derivedContent
="B.3" format="counter" sectionFormat="of" target="section-b.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-representation-of-pub
lic-ke">Representation of Public Keys Used with ECDSA</xref></t>
</li>
<li pn="section-toc.1-1.11.2.4">
<t indent="0" pn="section-toc.1-1.11.2.4.1"><xref derivedContent
="B.4" format="counter" sectionFormat="of" target="section-b.4"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-alternative-represent
ations">Alternative Representations of Curve25519</xref></t>
</li>
<li pn="section-toc.1-1.11.2.5">
<t indent="0" pn="section-toc.1-1.11.2.5.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-b.5"/><xref derivedContent=
"" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgmen
ts</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section numbered="true" removeInRFC="false" toc="include" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">
Neighbor Discovery optimizations for 6LoWPAN networks (aka 6LoWPAN ND) <x
ref target="RFC6775" format="default" sectionFormat="of" derivedContent="RFC6775
"/> adapts the original IPv6 Neighbor Discovery protocols defined in <xref targe
t="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/> and <
xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC486
2"/> for constrained
Low-Power and Lossy Networks (LLNs). In particular, 6LoWPAN ND introduces
a unicast host Address Registration mechanism that reduces the use of multicast
compared to the Duplicate Address Detection (DAD) mechanism defined in IPv6 ND.
6LoWPAN ND defines a new Address Registration Option (ARO) that is carried in t
he unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages e
xchanged between a 6LoWPAN Node (6LN) and a 6LoWPAN Router (6LR). It also define
s the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC)
messages between the 6LR and the 6LoWPAN Border Router (6LBR). In LLNs, t
he 6LBR is the central repository of all the Registered Addresses in its domain.
</t>
<t indent="0" pn="section-1-2">
The registration mechanism in "Neighbor Discovery Optimization for IPv6 o
ver Low-Power Wireless Personal Area Networks (6LoWPANs)" <xref target="RFC6775"
format="default" sectionFormat="of" derivedContent="RFC6775"/> prevents the use
of an address if that address
is already registered in the subnet (first come, first served). In order
to validate address ownership, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" <xref target="RFC85
05" format="default" sectionFormat="of" derivedContent="RFC8505"/> defines a Reg
istration Ownership Verifier (ROVR) field. <xref target="RFC8505" format="defaul
t" sectionFormat="of" derivedContent="RFC8505"/> enables a 6LR and 6LBR to valid
ate the association between the Registered Address of a node and its ROVR. The R
OVR can be derived from the link-layer address of the device (using the 64-bit E
xtended Unique Identifier (EUI-64) address format specified by IEEE). However, t
he EUI-64 can be spoofed; therefore, any node connected to the subnet and aware
of a registered-address-to-ROVR mapping could effectively fake the ROVR. This wo
uld allow an attacker to steal the address and redirect traffic for that address
. <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC
8505"/> defines an Extended Address Registration Option (EARO) that transports a
lternate forms of ROVRs and is a prerequisite for this specification.
</t>
<t indent="0" pn="section-1-3">
In this specification, a 6LN generates a cryptographic identifi
er (Crypto-ID) and places it in the ROVR field during the registration of one (o
r more) of its addresses with the 6LR(s). Proof of ownership of the Crypto-ID is
passed with the first registration exchange to a new 6LR and enforced at the 6L
R. The 6LR validates ownership of the
Crypto-ID before it creates any new registration state or chang
es existing information.
</t>
<t indent="0" pn="section-1-4">
The protected address registration protocol proposed in this do
cument provides the same conceptual benefit as Source Address Validation Improve
ment (SAVI) <xref target="RFC7039" format="default" sectionFormat="of" derivedCo
ntent="RFC7039"/> in that only the owner of an IPv6 address may source packets w
ith that address. As opposed to <xref target="RFC7039" format="default" sectionF
ormat="of" derivedContent="RFC7039"/>, which relies on snooping protocols, the p
rotection provided by this document is based on a state that is installed and ma
intained in the network by the owner of the address. With this specification, a
6LN may use a 6LR for forwarding an IPv6 packet if and only if it has registered
the address used as the source of the packet with that 6LR.
<date/> </t>
<workgroup>6lo</workgroup> <t indent="0" pn="section-1-5">
<abstract>
<t>
This document updates the 6LoWPAN Neighbor Discovery (ND) protocol def
ined in RFC 6775 and RFC 8505.
The new extension is called Address Protected Neighbor Discovery (AP-N
D) and it protects the owner of an address against
address theft and impersonation attacks in a low-power and lossy netw
ork (LLN).
Nodes supporting this extension compute a cryptographic identifier (C
rypto-ID) and use it with one or more of their
Registered Addresses. The Crypto-ID identifies the owner of the Regis
tered Address and can be used to provide proof of
ownership of the Registered Addresses. Once an address is registered
with the Crypto-ID and a proof-of-ownership is
provided, only the owner of that address can modify the registration
information, thereby enforcing Source Address
Validation.
</t>
</abstract>
</front>
<middle>
<section><name>Introduction</name>
<t>
Neighbor Discovery Optimizations for 6LoWPAN networks <xref target='RFC67
75'/> (6LoWPAN ND) adapts the original IPv6
Neighbor Discovery (IPv6 ND) protocols defined in <xref target='RFC4861'/
> and <xref target='RFC4862'/> for constrained
low-power and lossy network (LLN). In particular, 6LoWPAN ND introduces a
unicast host Address Registration mechanism
that reduces the use of multicast compared to the Duplicate Address Detec
tion (DAD) mechanism defined in IPv6 ND.
6LoWPAN ND defines a new Address Registration Option (ARO) that is carri
ed in the
unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messag
es exchanged between a 6LoWPAN Node (6LN) and
a 6LoWPAN Router (6LR).
It also defines the Duplicate Address Request (DAR) and Duplicate Addres
s Confirmation (DAC)
messages between the 6LR and the 6LoWPAN Border Router (6LBR).
In LLN networks, the 6LBR is the central repository of all the registered
addresses in its domain.
</t>
<t>
The registration mechanism in <xref target='RFC6775'>"Neighbor Discovery
Optimization for Low-power and Lossy Networks"</xref> (aka 6LoWPAN ND) prevents
the use of an address if that address
is already registered in the subnet (first come first serve). In order to
validate address ownership, the registration
mechanism enables the 6LR and 6LBR to validate the association between th
e registered address of a node, and its
Registration Ownership Verifier (ROVR). The ROVR is defined in <xref targ
et='RFC8505'>"Registration Extensions for 6LoWPAN Neighbor
Discovery"</xref> and it can be derived from the
MAC address of the device (using the 64-bit Extended Unique Identifier EU
I-64 address format specified by IEEE).
However, the EUI-64 can be spoofed, and therefore, any node connected to
the subnet and aware of a
registered-address-to-ROVR mapping could effectively fake the ROVR. This
would allow an attacker to steal the
address and redirect traffic for that address. <xref target='RFC8505'/> d
efines an Extended Address Registration
Option (EARO) option that transports alternate forms of ROVRs, and is a p
re-requisite for this specification.
</t>
<t>
In this specification, a 6LN generates a cryptographic ID (Cryp
to-ID) and places it in the ROVR field during the
registration of one (or more) of its addresses with the 6LR(s).
Proof of ownership of the Crypto-ID is passed with
the first registration exchange to a new 6LR, and enforced at t
he 6LR.
The 6LR validates ownership of the
cryptographic ID before it creates any new registration state,
or changes existing information.
</t>
<t>
The protected address registration protocol proposed in this do
cument provides the same conceptual benefit as Source Address Validation (SAVI)
<xref target='RFC7039'/> that only the owner of an IPv6 address may source packe
ts with that address.
As opposed to <xref target='RFC7039'/>, which relies on snooping proto
cols, the protection is based on a state that is installed and maintained in the
network by the owner of the address. With this specification, a 6LN may use a 6
LR for forwarding an IPv6 packets if and only if it has registered the address u
sed as source of the packet with that 6LR.
<!--, and a first-hop 6LR that is configured to enforce this rule MUST
discard a packet that is not originated from the 6LN that registered the IPv6 s
ource address of the packet.
-->
</t>
<t>
With the 6lo adaptation layer in <xref target='RFC4944'/> and <
xref target='RFC6282'/>, a 6LN can obtain a better compression for an IPv6 addre
ss with an Interface ID (IID) that is derived from a Layer-2 address. As a side
note, this is incompatible with Secure Neighbor Discovery (SeND) <xref target='R
FC3971'/> and Cryptographically Generated Addresses (CGAs)
<xref target='RFC3972'/>, since they derive the IID from crypto
graphic keys, whereas this specification separates the IID and the key material.
</t>
</section>
<section><name>Terminology</name>
<section anchor='bcp'><name>BCP 14</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target='RFC2119'/> <xref target='RFC8174'/> when, and only when,
they appear in all capitals, as shown here.
</t>
</section> <!-- end section "BCP 14" -->
<section anchor='lo' ><name>Additional References</name>
<t> With the 6LoWPAN adaptation layer in <xref target="RFC4944" for
mat="default" sectionFormat="of" derivedContent="RFC4944"/> and <xref target="RF
C6282" format="default" sectionFormat="of" derivedContent="RFC6282"/>, a
6LN can obtain better compression for an IPv6
address with an Interface ID (IID) that is derived
from a Layer 2 (L2) address. Such compression is incompatible w
ith "SEcure Neighbor Discovery (SEND") <xref target="RFC3971" format="default" s
ectionFormat="of" derivedContent="RFC3971"/> and "Cryptographically Generated Ad
dresses (CGAs)" <xref target="RFC3972" format="default" sectionFormat="of" deriv
edContent="RFC3972"/>, since they derive the IID from cryptographic keys. This s
pecification, on the other hand, separates the IID generation from cryptographic
computations and can enable better compression.
</t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-2">
<name slugifiedName="name-terminology">Terminology</name>
<section anchor="bcp" numbered="true" removeInRFC="false" toc="include" pn
="section-2.1">
<name slugifiedName="name-requirements-language">Requirements Language</
name>
<t indent="0" pn="section-2.1-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="lo" numbered="true" removeInRFC="false" toc="include" pn=
"section-2.2">
<name slugifiedName="name-background">Background</name>
<t indent="0" pn="section-2.2-1">
The reader may get additional context for this specification from the fol lowing references: The reader may get additional context for this specification from the fol lowing references:
</t><ul spacing='compact'> </t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2
<li> <xref target='RFC3971'>"SEcure Neighbor Discovery (SEND)"</xref>,</l .2-2">
i> <li pn="section-2.2-2.1"> "SEcure Neighbor Discovery (SEND)" <xref tar
<li> <xref target='RFC3972'>"Cryptographically Generated Addresses (CGA)" get="RFC3971" format="default" sectionFormat="of" derivedContent="RFC3971"/>,</l
</xref>,</li> i>
<li><xref target='RFC4861'>"Neighbor Discovery for IP version 6"</xref> , <li pn="section-2.2-2.2"> "Cryptographically Generated Addresses (CGA)
</li> " <xref target="RFC3972" format="default" sectionFormat="of" derivedContent="RFC
<li><xref target='RFC4862'>"IPv6 Stateless Address Autoconfiguration"</xr 3972"/>,</li>
ef>, and </li> <li pn="section-2.2-2.3"> "Neighbor Discovery for IP version 6 (IPv6)"
<li><xref target='RFC4919'>"IPv6 over Low-Power Wireless Personal Area Ne <xref target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4
tworks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals "</xref>. 861"/> ,</li>
</li> <li pn="section-2.2-2.4"> "IPv6 Stateless Address Autoconfiguration" <
</ul> xref target="RFC4862" format="default" sectionFormat="of" derivedContent="RFC486
</section> <!-- Additional References --> 2"/>, and </li>
<li pn="section-2.2-2.5"> "IPv6 over Low-Power Wireless Personal Area
<section anchor='acronyms'><name>Abbreviations</name> Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" <xref
<t> This document uses the following abbreviations: target="RFC4919" format="default" sectionFormat="of" derivedContent="RFC4919"/>.
</t><dl spacing='compact'> </li>
<dt>6BBR:</dt><dd> 6LoWPAN Backbone Router </dd> </ul>
<dt>6LBR:</dt><dd> 6LoWPAN Border Router </dd> </section>
<dt>6LN:</dt><dd> 6LoWPAN Node </dd> <section anchor="acronyms" numbered="true" removeInRFC="false" toc="includ
<dt>6LR:</dt><dd>6LoWPAN Router </dd> e" pn="section-2.3">
<dt>CGA:</dt><dd>Cryptographically Generated Address</dd> <name slugifiedName="name-abbreviations">Abbreviations</name>
<dt>EARO:</dt><dd> Extended Address Registration Option</dd> <t indent="0" pn="section-2.3-1"> This document uses the following abbre
<dt>ECDH:</dt><dd> Elliptic curve Diffie–Hellman</dd> viations:
<dt>ECDSA:</dt><dd> Elliptic Curve Digital Signature Algorithm</dd>
<dt>CIPO:</dt><dd>Crypto-ID Parameters Option</dd>
<dt>LLN:</dt><dd> Low-Power and Lossy Network </dd>
<dt>JSON:</dt><dd> JavaScript Object Notation</dd>
<dt>JOSE:</dt><dd> JavaScript Object Signing and Encryption</dd>
<dt>JWK:</dt><dd> JSON Web Key</dd>
<dt>JWS:</dt><dd> JSON Web Signature</dd>
<dt>NA:</dt><dd> Neighbor Advertisement </dd>
<dt>ND:</dt><dd> Neighbor Discovery </dd>
<dt>NDP:</dt><dd> Neighbor Discovery Protocol </dd>
<dt>NDPSO:</dt><dd> Neighbor Discovery Protocol Signature Option</dd>
<dt>NS:</dt><dd> Neighbor Solicitation </dd>
<dt>ROVR:</dt><dd> Registration Ownership Verifier </dd>
<dt>RA:</dt><dd> Router Advertisement </dd>
<dt>RS:</dt><dd> Router Solicitation </dd>
<dt>RSAO:</dt><dd> RSA Signature Option</dd>
<dt>SHA:</dt><dd> Secure Hash Algorithm</dd>
<dt>SLAAC:</dt><dd> Stateless Address Autoconfiguration</dd>
<dt>TID:</dt><dd> Transaction ID </dd>
</dl><t>
</t>
</section> <!-- end section "Acronym Definitions" -->
</section> <!-- end section "Terminology" -->
<section><name>Updating RFC 8505</name> </t>
<t> <dl spacing="compact" indent="10" newline="false" pn="section-2.3-2">
Section 5.3 of <xref target='RFC8505'/> introduces the ROVR that is used <dt pn="section-2.3-2.1">6BBR:</dt>
to detect and reject duplicate registrations in the DAD process. <dd pn="section-2.3-2.2"> 6LoWPAN Backbone Router</dd>
The ROVR is a generic object that is designed for both backward compatib <dt pn="section-2.3-2.3">6LBR:</dt>
ility and the capability to introduce new computation methods in the future. Usi <dd pn="section-2.3-2.4"> 6LoWPAN Border Router</dd>
ng a Crypto-ID per this specification is the RECOMMENDED method. <xref target='s <dt pn="section-2.3-2.5">6LN:</dt>
ec-col'/> discusses collisions when heterogeneous methods to compute the ROVR fi <dd pn="section-2.3-2.6"> 6LoWPAN Node</dd>
eld coexist inside a same network. <dt pn="section-2.3-2.7">6LR:</dt>
</t> <dd pn="section-2.3-2.8"> 6LoWPAN Router</dd>
<t> <dt pn="section-2.3-2.9">AP-ND:</dt>
This specification introduces a new token called a cryptographic iden <dd pn="section-2.3-2.10"> Address-Protected Neighbor Discovery</dd>
tifier (Crypto-ID) that is transported in the ROVR field and used to prove indir <dt pn="section-2.3-2.11">CGA:</dt>
ectly the ownership of an address that is being registered by means of <xref tar <dd pn="section-2.3-2.12"> Cryptographically Generated Address</dd>
get='RFC8505'/>. The <dt pn="section-2.3-2.13">DAD:</dt>
<dd pn="section-2.3-2.14"> Duplicate Address Detection</dd>
<dt pn="section-2.3-2.15">EARO:</dt>
<dd pn="section-2.3-2.16"> Extended Address Registration Option</dd>
<dt pn="section-2.3-2.17">ECC:</dt>
<dd pn="section-2.3-2.18"> Elliptic Curve Cryptography</dd>
<dt pn="section-2.3-2.19">ECDH:</dt>
<dd pn="section-2.3-2.20"> Elliptic Curve Diffie-Hellman</dd>
<dt pn="section-2.3-2.21">ECDSA:</dt>
<dd pn="section-2.3-2.22"> Elliptic Curve Digital Signature Algorithm<
/dd>
<dt pn="section-2.3-2.23">EDAC:</dt>
<dd pn="section-2.3-2.24"> Extended Duplicate Address Confirmation</dd
>
<dt pn="section-2.3-2.25">EDAR:</dt>
<dd pn="section-2.3-2.26"> Extended Duplicate Address Request </dd>
<dt pn="section-2.3-2.27">CIPO:</dt>
<dd pn="section-2.3-2.28">Crypto-ID Parameters Option</dd>
<dt pn="section-2.3-2.29">LLN:</dt>
<dd pn="section-2.3-2.30"> Low-Power and Lossy Network</dd>
<dt pn="section-2.3-2.31">NA:</dt>
<dd pn="section-2.3-2.32"> Neighbor Advertisement </dd>
<dt pn="section-2.3-2.33">ND:</dt>
<dd pn="section-2.3-2.34"> Neighbor Discovery </dd>
<dt pn="section-2.3-2.35">NDP:</dt>
<dd pn="section-2.3-2.36"> Neighbor Discovery Protocol </dd>
<dt pn="section-2.3-2.37">NDPSO:</dt>
<dd pn="section-2.3-2.38"> Neighbor Discovery Protocol Signature Optio
n</dd>
<dt pn="section-2.3-2.39">NS:</dt>
<dd pn="section-2.3-2.40"> Neighbor Solicitation </dd>
<dt pn="section-2.3-2.41">ROVR:</dt>
<dd pn="section-2.3-2.42"> Registration Ownership Verifier </dd>
<dt pn="section-2.3-2.43">RA:</dt>
<dd pn="section-2.3-2.44"> Router Advertisement </dd>
<dt pn="section-2.3-2.45">RS:</dt>
<dd pn="section-2.3-2.46"> Router Solicitation </dd>
<dt pn="section-2.3-2.47">RSAO:</dt>
<dd pn="section-2.3-2.48"> RSA Signature Option</dd>
<dt pn="section-2.3-2.49">SHA:</dt>
<dd pn="section-2.3-2.50"> Secure Hash Algorithm</dd>
<dt pn="section-2.3-2.51">SLAAC:</dt>
<dd pn="section-2.3-2.52"> Stateless Address Autoconfiguration</dd>
<dt pn="section-2.3-2.53">TID:</dt>
<dd pn="section-2.3-2.54"> Transaction ID </dd>
</dl>
</section>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-3">
<name slugifiedName="name-updating-rfc-8505">Updating RFC 8505</name>
<t indent="0" pn="section-3-1">
<xref target="RFC8505" sectionFormat="of" section="5.3" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc8505#section-5.3" derivedContent="RFC
8505"/> introduces the ROVR that is used to detect and reject duplicate registra
tions in the DAD process. The ROVR is a generic object that is designed for both
backward compatibility and the capability to introduce new computation methods
in the future. Using a Crypto-ID per this specification is the <bcp14>RECOMMENDE
D</bcp14> method. <xref target="sec-col" format="default" sectionFormat="of" der
ivedContent="Section 7.5"/> discusses collisions when heterogeneous methods to c
ompute the ROVR field coexist inside a network.
</t>
<t indent="0" pn="section-3-2">
This specification introduces a new identifier called a Crypto-ID that i
s transported in the ROVR field and used to indirectly prove the ownership of an
address that is being registered by means of <xref target="RFC8505" format="def
ault" sectionFormat="of" derivedContent="RFC8505"/>. The
Crypto-ID is derived from a cryptographic public key and additional para meters. Crypto-ID is derived from a cryptographic public key and additional para meters.
</t> </t>
<t> <t indent="0" pn="section-3-3">
The overall mechanism requires the support of Elliptic Curve Cryptograph The overall mechanism requires the support of Elliptic Curve Cryptograph
y (ECC) and of a hash function as detailed in <xref target='ndpso-generation'/>. y (ECC) and a hash function as detailed in <xref target="ndpso-generation" forma
To enable the verification of the proof, the registering node needs to supply c t="default" sectionFormat="of" derivedContent="Section 6.2"/>. To enable the ver
ertain parameters including a nonce and a signature that will demonstrate that t ification of the proof, the Registering Node needs to supply certain parameters
he node possesses the private-key corresponding to the public-key used to build including a nonce and a signature that will demonstrate that the node possesses
the Crypto-ID. the private key corresponding to the public key used to build the Crypto-ID.
</t> </t>
<t> The elliptic curves and the hash functions listed in <xref target='crypt <t indent="0" pn="section-3-4"> The elliptic curves and the hash functions
otypetable'/> in <xref target='cryptotypereg'/> can be used with this specificat listed in <xref target="cryptotypetable" format="default" sectionFormat="of" de
ion; more may be added in the future to the IANA registry. rivedContent="Table 1"/> in <xref target="cryptotypereg" format="default" sectio
The signature scheme that specifies which combination is used (including nFormat="of" derivedContent="Section 8.2"/> can
the curve and the representation conventions) is signaled by a Crypto-Type in a be used with this specification; more may be added in the future
new IPv6 ND Crypto-ID Parameters Option (CIPO, see <xref target='cryptoidopt'/>) to the corresponding IANA registry. The cryptographic algorithms used (inclu
that contains the parameters that are necessary for the proof, a Nonce o ding the curve and the representation conventions) are signaled by the Crypto-Ty
ption (<xref target='RFC3971'/>) and a NDP Signature option (<xref target='ndpso pe field in a new IPv6 ND Crypto-ID Parameters Option (CIPO) (see <xref target="
'/>). The NA(EARO) is modified to enable a challenge and transport a Nonce opti cryptoidopt" format="default" sectionFormat="of" derivedContent="Section 4.3"/>)
on. that contains the parameters that are necessary for address validation.
</t> A new NDP Signature Option (<xref target="ndpso" format="default" sectionFor
<!--t> mat="of" derivedContent="Section 4.4"/>) is also specified in this document to c
In order to avoid the need for new ND option types, this specification reuse arry the resulting signature. A Nonce Option <xref target="RFC3971" format="defa
s and extends options defined in SEND <xref target="RFC3971"/> and 6LoWPAN ND <x ult" sectionFormat="of" derivedContent="RFC3971"/> is added in the NA(EARO) that
ref target="RFC6775"/> <xref target="RFC8505"/>. This applies to the CGA option is used to request the validation, and all three options are needed in the NS(E
and the RSA Signature Option. This specification provides aliases for the specif ARO) that provides the validation.
ic variations of those options as used in this document. The presence of the EAR </t>
O option in the NS/NA messages indicates that the options are to be processed as </section>
specified in this document, and not as defined in SEND <xref target="RFC3971"/> <section anchor="cryptoifldg" numbered="true" removeInRFC="false" toc="inclu
. de" pn="section-4">
</t--> <name slugifiedName="name-new-fields-and-options">New Fields and Options</
</section> name>
<section anchor="cryptoidalg" numbered="true" removeInRFC="false" toc="inc
<section anchor='cryptoifldg'><name>New Fields and Options</name> lude" pn="section-4.1">
<name slugifiedName="name-new-crypto-id">New Crypto-ID</name>
<section anchor='cryptoidalg'><name>New Crypto-ID</name> <t indent="0" pn="section-4.1-1">
<t> The Crypto-ID is transported in the ROVR field of the EARO and the Extend
The Crypto-ID is transported in the ROVR field of the EARO option and the ed Duplicate Address Request (EDAR) message and is associated with the Registere
EDAR message, and is associated with the Registered Address at the 6LR and the d Address at the 6LR and the 6LBR.
6LBR.
The ownership of a Crypto-ID can be demonstrated by cryptographic mechani sms, and by association, the ownership of the Registered Address can be ascertai ned. The ownership of a Crypto-ID can be demonstrated by cryptographic mechani sms, and by association, the ownership of the Registered Address can be ascertai ned.
</t><t> </t>
A node in possession of the necessary cryptographic primitives SHOULD use <t indent="0" pn="section-4.1-2">
Crypto-ID by default as ROVR in its registrations. Whether a ROVR is a Crypto-I A node in possession of the necessary cryptographic primitives <bcp14>SHO
D is indicated by a new "C" flag in the NS(EARO) message. ULD</bcp14> use Crypto-ID by default as ROVR in its registrations. Whether a ROV
</t> R is a Crypto-ID is indicated by a new "C" flag in the EARO of the NS(EARO) mess
<t> age.
</t>
<t indent="0" pn="section-4.1-3">
The Crypto-ID is derived from the public key and a modifier as follows: The Crypto-ID is derived from the public key and a modifier as follows:
</t><ol spacing='compact'> </t>
<li>The hash function used internally by the signature scheme indicated by th <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-4.
e Crypto-Type (see also <xref target='cryptotypetable'/> in <xref target='crypto 1-4">
typereg'/>) <li pn="section-4.1-4.1" derivedCounter="1.">The hash function used internall
is applied to the CIPO. Note that all the reserved and padding bits MUST be s y by the signature scheme and indicated by the Crypto-Type (see <xref target="cr
et to zero. yptotypetable" format="default" sectionFormat="of" derivedContent="Table 1"/> in
<xref target="cryptotypereg" format="default" sectionFormat="of" derivedContent
="Section 8.2"/>)
is applied to the CIPO. Note that all the reserved and padding bits <bcp14>MU
ST</bcp14> be set to zero.
</li> </li>
<li> The leftmost bits of the resulting hash, up to the desired size, are use d as the Crypto-ID. <li pn="section-4.1-4.2" derivedCounter="2."> The leftmost bits of the resulting hash, up to the desired size, are used as the Crypto-ID.
</li> </li>
</ol><t> </ol>
At the time of this writing, a minimal size for the Crypto-ID of 128 bits is <t indent="0" pn="section-4.1-5">
RECOMMENDED unless backward compatibility is needed <xref target='RFC8505'/>. Th At the time of this writing, a minimal size for the Crypto-ID of 128 bits is
is value is bound to augment in the future. <bcp14>RECOMMENDED</bcp14> unless backward compatibility is needed <xref target=
</t> "RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/> (in whi
</section> ch case it is at least 64 bits). The size of the Crypto-ID is likely to increase
in the future.
<section anchor='cryptoEARO'><name>Updated EARO</name> </t>
<t> </section>
This specification updates the EARO option to enable the use of the RO <section anchor="cryptoEARO" numbered="true" removeInRFC="false" toc="incl
VR field to transport the Crypto-ID. The resulting format is as follows: ude" pn="section-4.2">
</t> <name slugifiedName="name-updated-earo">Updated EARO</name>
<figure anchor='crypto-fig'><name>Enhanced Address Registration Option</n <t indent="0" pn="section-4.2-1">
ame> This specification updates the EARO to enable the use of the ROVR fiel
<artwork> d to transport the Crypto-ID. The resulting format is as follows:
</t>
<figure anchor="crypto-fig" align="left" suppress-title="false" pn="figu
re-1">
<name slugifiedName="name-enhanced-address-registrati">Enhanced Addres
s Registration Option</name>
<artwork align="left" pn="section-4.2-2.1">
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 line 271 skipping to change at line 452
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) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> </artwork>
</figure> </figure>
<dl spacing="normal" indent="3" newline="false" pn="section-4.2-3">
<t> <dt pn="section-4.2-3.1">Type:</dt>
</t><dl spacing='normal'> <dd pn="section-4.2-3.2">
<dt>Type:</dt><dd>
33 33
</dd> </dd>
<dt pn="section-4.2-3.3">Length:</dt>
<dt>Length:</dt><dd> <dd pn="section-4.2-3.4">
Defined in <xref target='RFC8505'/> and copied in associated CIPO. Defined in <xref target="RFC8505" format="default" sectionFormat="of" der
ivedContent="RFC8505"/> and copied in the "EARO Length"
field in the associated CIPO.
</dd> </dd>
<dt pn="section-4.2-3.5">Status:</dt>
<dt>Status:</dt><dd> <dd pn="section-4.2-3.6">
Defined in <xref target='RFC8505'/>. Defined in <xref target="RFC8505" format="default" sectionFormat="of" der
ivedContent="RFC8505"/>.
</dd> </dd>
<dt pn="section-4.2-3.7">Opaque:</dt>
<dt>Opaque:</dt><dd> <dd pn="section-4.2-3.8">
Defined in <xref target='RFC8505'/>. Defined in <xref target="RFC8505" format="default" sectionFormat="of" der
ivedContent="RFC8505"/>.
</dd> </dd>
<dt pn="section-4.2-3.9">Rsvd (Reserved):</dt>
<dt>Rsvd (Reserved):</dt><dd>3-bit unsigned integer. <dd pn="section-4.2-3.10">3-bit unsigned integer.
It MUST be set to zero by the sender and MUST be ignored by the receiver It <bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</bcp
. 14> be ignored by the receiver.
</dd> </dd>
<dt pn="section-4.2-3.11">C:</dt>
<dt>C:</dt><dd> <dd pn="section-4.2-3.12">
This "C" flag is set to indicate that the ROVR field contains a Crypto-ID 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 specified in this document. and that the 6LN <bcp14>MAY</bcp14> be challenged for ownership as specified in
this document.
</dd> </dd>
<dt pn="section-4.2-3.13">I, R, T:</dt>
<dt>I, R, T:</dt><dd> <dd pn="section-4.2-3.14">
Defined in <xref target='RFC8505'/>. Defined in <xref target="RFC8505" format="default" sectionFormat="of"
derivedContent="RFC8505"/>.
</dd> </dd>
<dt>TID:</dt><dd> <dt pn="section-4.2-3.15">TID and Registration Lifetime:</dt>
Defined in <xref target='RFC8505'/>. <dd pn="section-4.2-3.16">
Defined in <xref target="RFC8505" format="default" sectionFormat="of"
derivedContent="RFC8505"/>.
</dd> </dd>
<dt pn="section-4.2-3.17">Registration Ownership Verifier (ROVR):</dt>
<dt>Registration Ownership Verifier (ROVR):</dt><dd> <dd pn="section-4.2-3.18">
When the "C" flag is set, this field contains a Crypto-ID. When the "C" flag is set, this field contains a Crypto-ID.
</dd> </dd>
</dl> </dl>
<t> <t indent="0" pn="section-4.2-4">
This specification uses Status values "Validation Requested" and This specification uses the status codes "Validation Requested" and
"Validation Failed", which are defined in <xref target='RFC8505'/>. "Validation Failed", which are defined in <xref target="RFC8505" format="
</t><t> default" sectionFormat="of" derivedContent="RFC8505"/>.
this specification does not define any new Status value. </t>
</t> <t indent="0" pn="section-4.2-5">
</section> This specification does not define any new status codes.
</t>
<section anchor='cryptoidopt'><name>Crypto-ID Parameters Option</name> </section>
<t> <section anchor="cryptoidopt" numbered="true" removeInRFC="false" toc="inc
This specification defines the Crypto-ID Parameters Option (CIPO). lude" pn="section-4.3">
The CIPO carries the parameters used to form a Crypto-ID. </t> <name slugifiedName="name-crypto-id-parameters-option">Crypto-ID Paramet
<t> ers Option</name>
In order to provide cryptographic agility <xref target='RFC7696'/>, this spe <t indent="0" pn="section-4.3-1">
cification supports different elliptic-curve based signature schemes, This specification defines the CIPO.
The CIPO carries the parameters used to form a Crypto-ID.</t>
<t indent="0" pn="section-4.3-2">
In order to provide cryptographic agility <xref target="RFC7696" format="def
ault" sectionFormat="of" derivedContent="BCP201"/>, this specification supports
different elliptic-curve-based signature schemes,
indicated by a Crypto-Type field: indicated by a Crypto-Type field:
</t> </t>
<ul> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4
<li> .3-3">
The ECDSA256 signature scheme, which uses ECDSA with the NIST P-256 curve <x <li pn="section-4.3-3.1">
ref target='FIPS186-4'/> and the hash function SHA-256 <xref target="RFC6234"></ The ECDSA256 signature scheme, which uses ECDSA with the NIST P-256 curve <x
xref> internally, ref target="FIPS186-4" format="default" sectionFormat="of" derivedContent="FIPS1
MUST be supported by all implementations. 86-4"/> and the hash function SHA-256 <xref target="RFC6234" format="default" se
ctionFormat="of" derivedContent="RFC6234"/> internally,
<bcp14>MUST</bcp14> be supported by all implementations.
</li> </li>
<li> <li pn="section-4.3-3.2">
The Ed25519 signature scheme, which uses the Pure Edwards-Curve Digital Sign The Ed25519 signature scheme, which uses the Pure Edwards-Curve Digital Sign
ature Algorithm (PureEdDSA) <xref target='RFC8032'/> with the twisted Edwards cu ature Algorithm (PureEdDSA) <xref target="RFC8032" format="default" sectionForma
rve Edwards25519 t="of" derivedContent="RFC8032"/> with the twisted Edwards curve Edwards25519
<xref target="RFC7748"></xref> and the hash function SHA-512 <xref target <xref target="RFC7748" format="default" sectionFormat="of" derivedContent
="RFC6234"></xref> internally, MAY be supported as an alternative. ="RFC7748"/> and the hash function SHA-512 <xref target="RFC6234" format="defaul
t" sectionFormat="of" derivedContent="RFC6234"/> internally, <bcp14>MAY</bcp14>
be supported as an alternative.
</li> </li>
<li> <li pn="section-4.3-3.3">
The ECDSA25519 signature scheme, which uses ECDSA <xref target='FIPS186-4'/> The ECDSA25519 signature scheme, which uses ECDSA <xref target="FIPS186-4" f
with the Weierstrass curve Wei25519 (see <xref target="curves"></xref>) and the ormat="default" sectionFormat="of" derivedContent="FIPS186-4"/> with the Weierst
hash function rass curve Wei25519 (see <xref target="curves" format="default" sectionFormat="o
SHA-256 <xref target="RFC6234"></xref> internally, MAY also be supported. f" derivedContent="Appendix B.4"/>) and the hash function
SHA-256 <xref target="RFC6234" format="default" sectionFormat="of" derive
dContent="RFC6234"/> internally, <bcp14>MAY</bcp14> also be supported.
</li> </li>
</ul> </ul>
<t> This specification uses signature schemes that target similar cryptog <t indent="0" pn="section-4.3-4"> This specification uses signature sche
raphic strength but rely on different curves, hash functions, signature algorith mes that target similar cryptographic strength but rely on different curves, has
ms, and/or h functions, signature algorithms, and/or
representation conventions. Future specification may extend this to diffe rent cryptographic algorithms and key sizes, e.g., to provide better security pr operties or a representation conventions. Future specification may extend this to diffe rent cryptographic algorithms and key sizes, e.g., to provide better security pr operties or a
simpler implementation. simpler implementation.
</t> </t>
<figure anchor="cgapar-fig" align="left" suppress-title="false" pn="figu
<figure anchor='cgapar-fig'><name>Crypto-ID Parameters Option</name> <art re-2">
work> <name slugifiedName="name-crypto-id-parameters-option-2">Crypto-ID Par
0 1 2 3 ameters Option</name>
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 <artwork align="left" pn="section-4.3-5.1">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Reserved1| Public Key Length | | Type | Length |Reserved1| Public Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Type | Modifier | EARO Length | | | Crypto-Type | Modifier | EARO Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
. . . .
. Public Key (variable length) . . Public Key (variable length) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Padding . . Padding .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> </artwork>
</figure> </figure>
<t> <dl spacing="normal" indent="3" newline="false" pn="section-4.3-6">
</t><dl spacing='normal'> <dt pn="section-4.3-6.1">Type:</dt>
<dt>Type:</dt><dd> 8-bit unsigned integer. <dd pn="section-4.3-6.2"> 8-bit unsigned integer.
to be assigned by IANA, see <xref target='nexndopt'/>. IANA has assigned value 39; see <xref target="nexndopt" format="defau
lt" sectionFormat="of" derivedContent="Table 2"/>.
</dd> </dd>
<dt pn="section-4.3-6.3">Length:</dt>
<dt>Length:</dt><dd> <dd pn="section-4.3-6.4">
8-bit unsigned integer. The length of the option in units of 8 octets . 8-bit unsigned integer. The length of the option in units of 8 octets .
</dd> </dd>
<dt pn="section-4.3-6.5">Reserved1:</dt>
<dt>Reserved1:</dt><dd> 5-bit unsigned integer. <dd pn="section-4.3-6.6"> 5-bit unsigned integer.
It MUST be set to zero by the sender and MUST be ignored by the receiver It <bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</bcp
. 14> be ignored by the receiver.
</dd> </dd>
<dt pn="section-4.3-6.7">Public Key Length:</dt>
<dt>Public Key Length:</dt><dd> <dd pn="section-4.3-6.8">
11-bit unsigned integer. The length of the Public Key field in bytes. 11-bit unsigned integer. The length of the Public Key field in bytes.
The actual length depends on the Crypto-Type value and on how the public key is The actual length depends on the Crypto-Type value and how the public key is re
represented. presented.
The valid values with this document are provided in <xref target The valid values with this document are provided in <xref target=
="cryptotypetable"/>. "cryptotypetable" format="default" sectionFormat="of" derivedContent="Table 1"/>
.
</dd> </dd>
<dt pn="section-4.3-6.9">Crypto-Type:</dt>
<dt>Crypto-Type:</dt><dd>8-bit unsigned integer. <dd pn="section-4.3-6.10">8-bit unsigned integer.
The type of cryptographic algorithm used in calculation Crypto-ID The type of cryptographic algorithm used in calculation of the Crypto-ID
indexed by IANA in the "Crypto-Type Subregistry" in the "Internet Contro indexed by IANA in the "Crypto-Types" subregistry in the "Internet Contr
l Message Protocol version 6 (ICMPv6) Parameters" ol Message Protocol version 6 (ICMPv6) Parameters" registry
(see <xref target='cryptotypereg'/>). (see <xref target="cryptotypereg" format="default" sectionFormat="of" de
rivedContent="Section 8.2"/>).
</dd> </dd>
<dt pn="section-4.3-6.11">Modifier:</dt>
<dt>Modifier:</dt><dd> <dd pn="section-4.3-6.12">
8-bit unsigned integer. Set to an arbitrary value by the creator of t 8-bit unsigned integer. Set to an arbitrary value by the creator of t
he Crypto-ID. he Crypto-ID. The role of the modifier is to enable the formation of multiple Cr
The role of the modifier is to enable the formation of multiple Crypto-IDs fr ypto-IDs from the same key pair. This reduces the traceability and, thus, improv
om a same key pair, which reduces the traceability and thus improves the privacy es the privacy of a constrained node without requiring many key pairs.
of a constrained node that could not maintain many key-pairs.
</dd> </dd>
<dt>EARO Length:</dt><dd> 8-bit unsigned integer. <dt pn="section-4.3-6.13">EARO Length:</dt>
<dd pn="section-4.3-6.14"> 8-bit unsigned integer.
The option length of the EARO that contains the Crypto-ID associated with the CIPO. The option length of the EARO that contains the Crypto-ID associated with the CIPO.
</dd> </dd>
<dt pn="section-4.3-6.15">Public Key:</dt>
<dt>Public Key:</dt><dd> A variable-length field, size indicated in the P <dd pn="section-4.3-6.16"> A variable-length field; the size is indica
ublic Key Length field. ted in the Public Key Length field.
</dd> </dd>
<dt pn="section-4.3-6.17">Padding:</dt>
<dt>Padding:</dt><dd> <dd pn="section-4.3-6.18">
A variable-length field completing the Public Key field to align to the A variable-length field that completes the Public Key field to align to
next 8-bytes boundary. It MUST be set to zero by the sender and MUST be ignored the next 8-byte boundary. It <bcp14>MUST</bcp14> be set to zero by the sender an
by the receiver. d <bcp14>MUST</bcp14> be ignored by the receiver.
</dd> </dd>
</dl><t> </dl>
</t> <t indent="0" pn="section-4.3-7">
<t>
The implementation of multiple hash functions in a constrained device may The implementation of multiple hash functions in a constrained device may
consume excessive amounts of program memory. This specification enables t he use of the same hash function SHA-256 <xref target='RFC6234'/> for two of the three supported ECC-based signature schemes. consume excessive amounts of program memory. This specification enables t he use of the same hash function SHA-256 <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> for two of the three supported EC C-based signature schemes.
Some code factorization is also possible for the ECC computation itself. Some code factorization is also possible for the ECC computation itself.
</t> </t>
<t> <t indent="0" pn="section-4.3-8">
<xref target='I-D.ietf-lwig-curve-representations'/> provides information <xref target="I-D.ietf-lwig-curve-representations" format="default" secti
on how to represent Montgomery curves and (twisted) Edwards curves as cur onFormat="of" derivedContent="CURVE-REPR"/> provides information
ves in short-Weierstrass form and illustrates how this can be used to implement on how to represent Montgomery curves and (twisted) Edwards curves as cur
elliptic curve computations using existing implementations that already provide, ves in short-Weierstrass form, and it illustrates how this can be used to implem
e.g., ECDSA and ECDH using NIST <xref target='FIPS186-4'/> prime curves. For mo ent elliptic curve computations using existing implementations that already prov
re details on representation conventions, we refer to ide, e.g., ECDSA and ECDH using NIST <xref target="FIPS186-4" format="default" s
<xref target='reprconv'/>.</t> ectionFormat="of" derivedContent="FIPS186-4"/> prime curves. For more details on
</section> representation conventions, refer to
<xref target="reprconv" format="default" sectionFormat="of" derivedConten
<section anchor='ndpso'><name>NDP Signature Option</name> t="Appendix B"/>.</t>
</section>
<t> <section anchor="ndpso" numbered="true" removeInRFC="false" toc="include"
This specification defines the NDP Signature Option (NDPSO). pn="section-4.4">
The NDPSO carries the signature that proves the ownership of the Crypto-ID. <name slugifiedName="name-ndp-signature-option">NDP Signature Option</na
The format of the NDPSO is illustrated in <xref target='ndpso-fig'/>. me>
</t> <t indent="0" pn="section-4.4-1">
<t> This specification defines the NDP Signature Option (NDPSO). The NDPSO ca
As opposed to the RSA Signature Option (RSAO) defined in section 5.2. of <xr rries the signature that proves the ownership of the Crypto-ID and validates the
ef target='RFC3971'>SEND</xref>, the NDPSO does not have a key hash field. Inste address being registered. The format of the NDPSO is illustrated in <xref targe
ad, the leftmost 128 bits of the ROVR field in the EARO are used as hash to retr t="ndpso-fig" format="default" sectionFormat="of" derivedContent="Figure 3"/>.
ieve the CIPO that contains the key material used for signature verification, le </t>
ft-padded if needed. <t indent="0" pn="section-4.4-2">
As opposed to the RSA Signature Option (RSAO) defined in <xref target="RFC39
</t> 71" sectionFormat="of" section="5.2" format="default" derivedLink="https://rfc-e
<t> ditor.org/rfc/rfc3971#section-5.2" derivedContent="RFC3971">SEND</xref>, the NDP
Another difference is that the NDPSO signs a fixed set of fields as opposed SO does not have a key hash field. Instead, the leftmost 128 bits of the ROVR fi
to all options that appear prior to it in the ND message that bears the signatur eld in the EARO are used as hash to retrieve the CIPO that contains the key mate
e. This allows to elide a CIPO that the 6LR already received, at the expense of rial used for signature verification, left-padded if needed.
the capability to add arbitrary options that would signed with a RSAO. </t>
</t> <t indent="0" pn="section-4.4-3">
<t> Another difference is that the NDPSO signs a fixed set of fields as opposed
An ND message that carries an NDPSO MUST have one and only one EARO. The EAR to all options that appear prior to it in the ND message that bears the signatur
O MUST contain a Crypto-ID in the ROVR field, and the Crypto-ID MUST be associat e. This allows a CIPO that the 6LR already received to be omitted, at the expens
ed with the keypair used for the Digital Signature in the NDPSO. e of the capability to add arbitrary options that would be signed with an RSAO.
</t> </t>
<t> <t indent="0" pn="section-4.4-4">
An ND message that carries an NDPSO <bcp14>MUST</bcp14> have one and only on
e EARO. The EARO <bcp14>MUST</bcp14> contain a Crypto-ID in the ROVR field, and
the Crypto-ID <bcp14>MUST</bcp14> be associated with the key pair used for the d
igital signature in the NDPSO.
</t>
<t indent="0" pn="section-4.4-5">
The CIPO may be present in the same message as the NDPSO. If it is not prese nt, it can 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 it is not prese nt, it can be found in an abstract table that was created by a previous message and indexed by the hash.
</t> </t>
<figure anchor='ndpso-fig'><name>NDP signature Option</name> <figure anchor="ndpso-fig" align="left" suppress-title="false" pn="figur
<artwork> e-3">
0 1 2 3 <name slugifiedName="name-ndp-signature-option-2">NDP Signature Option
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 </name>
<artwork align="left" pn="section-4.4-6.1">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Reserved1| Signature Length | | Type | Length |Reserved1| Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 | | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Digital Signature (variable length) . . Digital Signature (variable length) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Padding . . Padding .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> </artwork>
</figure> </figure>
<t> <dl spacing="normal" indent="3" newline="false" pn="section-4.4-7">
</t><dl spacing='normal'> <dt pn="section-4.4-7.1">Type:</dt>
<dt>Type:</dt><dd> <dd pn="section-4.4-7.2">
to be assigned by IANA, see <xref target='nexndopt'/>. IANA has assigned value 40; see <xref target="nexndopt" format="defau
lt" sectionFormat="of" derivedContent="Table 2"/>.
</dd> </dd>
<dt pn="section-4.4-7.3">Length:</dt>
<dt>Length:</dt><dd> <dd pn="section-4.4-7.4">
8-bit unsigned integer. The length of the option in units of 8 octets . 8-bit unsigned integer. The length of the option in units of 8 octets .
</dd> </dd>
<dt pn="section-4.4-7.5">Reserved1:</dt>
<dt>Reserved1:</dt><dd> 5-bit unsigned integer. <dd pn="section-4.4-7.6"> 5-bit unsigned integer.
It MUST be set to zero by the sender and MUST be ignored by the receiver It <bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</bcp
. 14> be ignored by the receiver.
</dd> </dd>
<dt pn="section-4.4-7.7">Digital Signature Length:</dt>
<dt>Digital Signature Length:</dt><dd> <dd pn="section-4.4-7.8">
11-bit unsigned integer. The length of the Digital Signature field in bytes. 11-bit unsigned integer. The length of the Digital Signature field in bytes.
</dd> </dd>
<dt pn="section-4.4-7.9">Reserved2:</dt>
<dt>Reserved2:</dt><dd> 32-bit unsigned integer. <dd pn="section-4.4-7.10"> 32-bit unsigned integer.
It MUST be set to zero by the sender and MUST be ignored by the receiver It <bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</bcp
. 14> be ignored by the receiver.
</dd> </dd>
<dt>Digital Signature:</dt><dd> <dt pn="section-4.4-7.11">Digital Signature:</dt>
A variable-length field containing the digital signature. The length and <dd pn="section-4.4-7.12">
computation of the digital signature both depend on the Crypto-Type which is fou A variable-length field containing the digital signature. The length and
nd in the associated CIPO, see <xref target='reprconv'/>. computation of the digital signature both depend on the Crypto-Type, which is fo
For the values of the Crypto-Type defined in this specification, and for und in the associated CIPO; see <xref target="reprconv" format="default" section
future values of the Crypto-Type unless specified otherwise, the signature is c Format="of" derivedContent="Appendix B"/>.
omputed as detailed in <xref target='ndpso-generation'/>. For the values of the Crypto-Type defined in this specification, and for
future values of the Crypto-Type unless specified otherwise, the signature is c
omputed as detailed in <xref target="ndpso-generation" format="default" sectionF
ormat="of" derivedContent="Section 6.2"/>.
</dd> </dd>
<dt pn="section-4.4-7.13">Padding:</dt>
<dt>Padding:</dt><dd> <dd pn="section-4.4-7.14">
A variable-length field completing the Digital Signature field to align A variable-length field completing the Digital Signature field to align
to the next 8-bytes boundary. It MUST be set to zero by the sender and MUST be i to the next 8-byte boundary. It <bcp14>MUST</bcp14> be set to zero by the sender
gnored by the receiver. and <bcp14>MUST</bcp14> be ignored by the receiver.
</dd> </dd>
</dl><t> </dl>
</t> </section>
</section> <section anchor="CIO" numbered="true" removeInRFC="false" toc="include" pn
="section-4.5">
<section anchor='CIO'> <name slugifiedName="name-extensions-to-the-capabilit">Extensions to the
<name>Extensions to the Capability Indication Option</name> Capability Indication Option</name>
<t> <t indent="0" pn="section-4.5-1">
This specification defines one new capability bits in the 6CIO, This specification defines one new capability bit in the 6LoWPAN Capabili
defined by <xref target="RFC7400"/> for use by the 6LR and 6LBR in IPv6 N ty Indication Option (6CIO),
D RA messages. as defined by <xref target="RFC7400" format="default" sectionFormat="of"
derivedContent="RFC7400"/>, for use by the 6LR and 6LBR in IPv6 ND RA messages.
</t> </t>
<figure anchor='fig6CIO' title="New Capability Bit in the 6CIO"> <figure anchor="fig6CIO" align="left" suppress-title="false" pn="figure-
<artwork> 4">
<![CDATA[ <name slugifiedName="name-new-capability-bit-in-the-6">New Capability
Bit in the 6CIO</name>
<artwork align="left" pn="section-4.5-2.1">
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 = 1 | Reserved |A|D|L|B|P|E|G| | Type | Length = 1 | Reserved |A|D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-4.5-3"> New Option Field:</t>
<t> New Option Field:</t> <dl spacing="normal" indent="3" newline="false" pn="section-4.5-4">
<dl spacing='normal'> <dt pn="section-4.5-4.1">A:</dt>
<dt>A:</dt><dd> 1-bit flag. Set to indicate that AP-ND is globally activa <dd pn="section-4.5-4.2"> 1-bit flag. Set to indicate that AP-ND is gl
ted in the network. obally activated in the network.
</dd> </dd>
</dl> </dl>
<t> <t indent="0" pn="section-4.5-5">
The "A" flag is set by the 6LBR that serves the network and propagated by th The "A" flag is set by the 6LBR that serves the network and is propagated by
e 6LRs. the 6LRs.
It is typically turned on when all 6LRs are migrated to this specification. It is typically turned on when all 6LRs are migrated to this specification.
</t> </t>
</section> <!--New 6LoWPAN Capability Bits in the Capability Indication Opti </section>
on --> </section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-5">
<name slugifiedName="name-protocol-scope">Protocol Scope</name>
<section><name>Protocol Scope</name> <t indent="0" pn="section-5-1">
<t> The scope of the protocol specified here is a 6LoWPAN LLN, typically
The scope of the protocol specified here is a 6LoWPAN LLN, typically a stub network connected to a larger IP network via a border router called a 6L
a stub network connected to a larger IP network via a Border Router called a 6L BR per <xref target="RFC6775" format="default" sectionFormat="of" derivedContent
BR per <xref target='RFC6775'/>. A 6LBR has sufficient capability to satisfy the ="RFC6775"/>. A 6LBR has sufficient capability to satisfy the needs of DAD.
needs of duplicate address detection. </t>
</t> <t indent="0" pn="section-5-2">
<t> The 6LBR maintains registration state for all devices in its attache
The 6LBR maintains registration state for all devices in its attache d LLN. Together with the first-hop router (the 6LR), the 6LBR assures uniquenes
d LLN. Together with the first-hop router (the 6LR), the 6LBR assures uniquenes s and grants ownership of an IPv6 address before it can be used in the LLN. This
s and grants ownership of an IPv6 address before it can be used in the LLN. This is in contrast to a traditional network that relies on IPv6 address autoconfigu
is in contrast to a traditional network that relies on IPv6 address auto-config ration <xref target="RFC4862" format="default" sectionFormat="of" derivedContent
uration <xref target='RFC4862'/>, where there is no guarantee of ownership from ="RFC4862"/>, where there is no guarantee of ownership from the network, and eac
the network, and each IPv6 Neighbor Discovery packet must be individually secure h IPv6 Neighbor Discovery packet must be individually secured <xref target="RFC3
d <xref target='RFC3971'/>. 971" format="default" sectionFormat="of" derivedContent="RFC3971"/>.
</t> </t>
<figure anchor='figco'><name>Basic Configuration</name> <figure anchor="figco" align="left" suppress-title="false" pn="figure-5">
<artwork><![CDATA[ <name slugifiedName="name-basic-configuration">Basic Configuration</name
>
<artwork align="left" pn="section-5-3.1">
---+-------- ............ ---+-------- ............
| External Network | External Network
| |
+-----+ +-----+
| | 6LBR | | 6LBR
+-----+ +-----+
o o o o o o
o o o o o o o o
o o LLN o o o o o LLN o o o
o o o o
o o o(6LR) o o o(6LR)
^ ^
o o | LLN link o o | LLN link
o o v o o v
o(6LN) o(6LN)
o o
]]></artwork> </artwork>
</figure> </figure>
<t> <t indent="0" pn="section-5-4">
In a mesh network, the 6LR is directly connected to the host device. In a mesh network, the 6LR is directly connected to the host device.
This specification mandates that the peer-wise layer-2 security is deployed so This specification mandates that the peer-wise L2 security is deployed so that
that all the packets from a particular host are securely identifiable by the 6LR all the packets from a particular host are protected. The 6LR may be multiple ho
. The 6LR may be multiple hops away from the 6LBR. Packets are routed between th ps away from the 6LBR. Packets are routed between the 6LR and the 6LBR via other
e 6LR and the 6LBR via other 6LRs. 6LRs.
</t> </t>
<t> <t indent="0" pn="section-5-5">
This specification mandates that all the LLN links between the 6LR and th e 6LBR are protected so that a packet that was validated by the first 6LR can be safely routed by other on-path 6LRs to the 6LBR. This specification mandates that all the LLN links between the 6LR and th e 6LBR are protected so that a packet that was validated by the first 6LR can be safely routed by other on-path 6LRs to the 6LBR.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-6">
<section><name>Protocol Flows</name> <name slugifiedName="name-protocol-flows">Protocol Flows</name>
<t> <t indent="0" pn="section-6-1">
The 6LR/6LBR ensures first-come/first-serve by storing the ROVR associat The 6LR/6LBR ensures first come, first served by storing the ROVR associ
ed to the address being registered upon the first registration and rejecting a r ated to the address being registered upon the first registration and rejecting a
egistration with a different ROVR value. A 6LN can claim any address as long as registration with a different ROVR value. A 6LN can claim any address as long a
it is the first to make that claim. After a successful registration, the 6LN bec s it is the first to make that claim. After a successful registration, the 6LN b
omes the owner of the registered address and the address is bound to the ROVR va ecomes the owner of the Registered Address, and the address is bound to the ROVR
lue in the 6LR/6LBR registry. value in the 6LR/6LBR registry.
</t> </t>
<t> <t indent="0" pn="section-6-2">
This specification protects the ownership of the address at the first hop (t This specification protects the ownership of the address at the
he edge). Its use in a network is signaled by the "A" flag in the 6CIO. The flag first hop (the edge). Its use in a network is signaled by the "A"
is set by the 6LBR and propagated unchanged by the 6LRs. flag in the 6CIO. The flag is set by the 6LBR and propagated
The "A" flag enables to migrate a network with the protection off and then t unchanged by the 6LRs. Once every node in the network is upgraded to support
urn it on globally. this specification, the "A" flag can be set to turn the protection on globally.
</t> </t>
<t> <t indent="0" pn="section-6-3">
The 6LN places a cryptographic token, the Crypto-ID, in the ROVR that is The 6LN places a cryptographic identifier, the Crypto-ID, in the ROVR th
associated with the address at the first registration, enabling the 6LR to late at is associated with the address at the first registration, enabling the 6LR to
r challenge it to verify that it is the original Registering Node. The challenge later challenge it to verify that it is the original Registering Node. The chal
may happen at any time at the discretion of the 6LR and the 6LBR. A valid regi lenge may happen at any time at the discretion of the 6LR and the 6LBR. A valid
stration in the 6LR or the 6LBR MUST NOT be altered until the challenge is compl registration in the 6LR or the 6LBR <bcp14>MUST NOT</bcp14> be altered until the
ete. challenge is complete.
</t> </t>
<t> <t indent="0" pn="section-6-4">
When the "A" flag is on, the 6LR MUST challenge the 6LN when it creates a b When the "A" flag in a subnet is set, the 6LR <bcp14>MUST</bcp14> challenge
inding with the "C" flag set in the ROVR and when a new registration attempts to the 6LN before it creates a Binding with the "C" flag set in the EARO. The 6LR
change a parameter of that binding that identifies the 6LN, for instance its So <bcp14>MUST</bcp14> also challenge the 6LN when a new registration attempts to c
urce Link-Layer Address. The verification protects against a rogue that would s hange a parameter of an already validated Binding for that 6LN, for instance, it
teal an address and attract its traffic, or use it as source address. s Source link-layer address. Such verification protects against an attacker that
</t> attempts to steal the address of an honest node.
<t> </t>
The 6LR MUST also challenge the 6LN if the 6LBR directly signals to do so, <t indent="0" pn="section-6-5">
using an EDAC Message with a "Validation Requested" status. The EDAR is The 6LR <bcp14>MUST</bcp14> indicate to the 6LBR that it performed a succes
echoed by the 6LR in the NA (EARO) back to the registering node. The 6LR sful validation by setting a status code of 5 ("Validation Requested") in the ED
SHOULD also challenge all its attached 6LNs at the time the 6LBR turns the AR. Upon a subsequent EDAR from a new 6LR with a status code that is not 5 for a
"A" flag on in the 6CIO, to detect an issue immediately. validated Binding, the 6LBR <bcp14>MUST</bcp14> indicate to the new 6LR that it
</t> needs to challenge the 6LN using a status code of 5 in the Extended Duplicate A
<t>If the 6LR does not support the Crypto-Type, it MUST reply with an EARO ddress Confirmation (EDAC).
Status 10 "Validation Failed" without a challenge. In that case, the 6LN </t>
may try another Crypto-Type until it falls back to Crypto-Type 0 that MUST <t indent="0" pn="section-6-6">
be supported by all 6LRs.
</t>
<t>
A node may use more than one IPv6 address at the same time. The separ
ation of the address and the cryptographic material avoids the need for the cons
trained device to compute multiple keys for multiple addresses. The 6LN MAY use
the same Crypto-ID to prove the ownership of multiple IPv6 addresses. The 6LN MA
Y also derive multiple Crypto-IDs from a same key.
</t>
<section anchor='first'><name>First Exchange with a 6LR</name>
<t>
A 6LN registers to a 6LR that is one hop away from it with the "C" fl
ag set in the EARO, indicating that the ROVR field contains a Crypto-ID. The Tar
get Address in the NS message indicates the IPv6 address that the 6LN is trying
to register <xref target='RFC8505'/>. The on-link (local) protocol interactions
are shown in <xref target='Dynamic-fig'/>. If the 6LR does not have a state with
the 6LN that is consistent with the NS(EARO), then it replies with a challenge
NA (EARO, status=Validation Requested) that contains a Nonce Option (shown as No
nceLR in <xref target='Dynamic-fig'/>).
</t>
<figure anchor='Dynamic-fig' suppress-title='false'><name>On-link Protoco The 6LR <bcp14>MUST</bcp14> challenge the 6LN when the 6LBR signals to do s
l Operation</name> o, which is done with an EDAC message with a status code of 5. The EDAC is echoe
<artwork><![CDATA[ d by the 6LR in the NA(EARO) back to the Registering Node. The 6LR <bcp14>SHOULD
</bcp14> also challenge all its attached 6LNs at the time the 6LBR turns the "A"
flag on in the 6CIO in orders to detect an issue immediately.
</t>
<t indent="0" pn="section-6-7">If the 6LR does not support the Crypto-Type
, it <bcp14>MUST</bcp14> reply with an EARO status code of 10 "Validation Failed
" without a challenge. In that case, the 6LN may try another Crypto-Type until i
t falls back to Crypto-Type 0, which <bcp14>MUST</bcp14> be supported by all 6LR
s.
</t>
<t indent="0" pn="section-6-8">
A node may use more than one IPv6 address at the same time. The separ
ation of the address and the cryptographic material avoids the need for the cons
trained device to compute multiple keys for multiple addresses. The 6LN <bcp14>M
AY</bcp14> use the same Crypto-ID to prove the ownership of multiple IPv6 addres
ses. The 6LN <bcp14>MAY</bcp14> also derive multiple Crypto-IDs from the same ke
y pair by changing the modifier.
</t>
<section anchor="first" numbered="true" removeInRFC="false" toc="include"
pn="section-6.1">
<name slugifiedName="name-first-exchange-with-a-6lr">First Exchange with
a 6LR</name>
<t indent="0" pn="section-6.1-1">
A 6LN registers to a 6LR that is one hop away from it with the "C" fl
ag set in the EARO, indicating that the ROVR field contains a Crypto-ID. The Tar
get Address in the NS message indicates the IPv6 address that the 6LN is trying
to register <xref target="RFC8505" format="default" sectionFormat="of" derivedCo
ntent="RFC8505"/>. The on-link (local) protocol interactions are shown in <xref
target="Dynamic-fig" format="default" sectionFormat="of" derivedContent="Figure
6"/>. If the 6LR does not have a state with the 6LN that is consistent with the
NS(EARO), then it replies with a challenge NA(EARO, status=Validation Requested)
that contains a Nonce Option (shown as NonceLR in <xref target="Dynamic-fig" fo
rmat="default" sectionFormat="of" derivedContent="Figure 6"/>).
</t>
<figure anchor="Dynamic-fig" suppress-title="false" align="left" pn="fig
ure-6">
<name slugifiedName="name-on-link-protocol-operation">On-Link Protocol
Operation</name>
<artwork align="left" pn="section-6.1-2.1">
6LN 6LR 6LN 6LR
| | | |
|<------------------------- RA -------------------------| |&lt;------------------------- RA -------------------------|
| | ^ | | ^
|---------------- NS with EARO (Crypto-ID) ------------>| | |---------------- NS with EARO (Crypto-ID) ------------&gt;| |
| | option | | option
|<- NA with EARO(status=Validation Requested), NonceLR | | |&lt;- NA with EARO(status=Validation Requested), NonceLR | |
| | v | | v
|------- NS with EARO, CIPO, NonceLN and NDPSO -------->| |------- NS with EARO, CIPO, NonceLN and NDPSO --------&gt;|
| | | |
|<------------------- NA with EARO ---------------------| |&lt;------------------- NA with EARO ---------------------|
| | | |
... ...
| | | |
|--------------- NS with EARO (Crypto-ID) ------------->| |--------------- NS with EARO (Crypto-ID) -------------&gt;|
| | | |
|<------------------- NA with EARO ---------------------| |&lt;------------------- NA with EARO ---------------------|
| | | |
... ...
| | | |
|--------------- NS with EARO (Crypto-ID) ------------->| |--------------- NS with EARO (Crypto-ID) -------------&gt;|
| | | |
|<------------------- NA with EARO ---------------------| |&lt;------------------- NA with EARO ---------------------|
| | | |
]]></artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-6.1-3">
<t> The Nonce Option contains a nonce value that, to the extent possible
The Nonce option contains a nonce value that, to the extent possible for for the implementation, was never used before. This specification inherits the i
the implementation, was never employed in association with the key pair used to dea from <xref target="RFC3971" format="default" sectionFormat="of" derivedConte
generate the Crypto-ID. This specification inherits from <xref target='RFC3971' nt="RFC3971"/> that the nonce is a random value. Ideally, an implementation uses
/> that simply indicates that the nonce is a random value. Ideally, an implement an unpredictable cryptographically random value <xref target="RFC4086" format="
ation uses an unpredictable cryptographically random value <xref target='RFC4086 default" sectionFormat="of" derivedContent="BCP106"/>. But that may be impractic
'/>. But that may be impractical in some LLN scenarios where the devices do not al in some LLN scenarios with resource-constrained devices.
have a guaranteed sense of time and for which computing complex hashes is detrim </t>
ental to the battery lifetime. <t indent="0" pn="section-6.1-4"> Alternatively, the device may use an a
</t> lways-incrementing value saved in the same stable storage as the key, so they ar
<t> Alternatively, e lost together, and start at a best-effort random value as either the nonce val
the device may use an always-incrementing value saved in the same stable ue or a component to its computation.
storage as the key, so they are lost together, and starting at a best effort ra </t>
ndom value, either as the nonce value or as a component to its computation. <t indent="0" pn="section-6.1-5">
</t> The 6LN replies to the challenge with an NS(EARO) that includes the N
<t> once Option (shown as NonceLN in <xref target="Dynamic-fig" format="default" sec
The 6LN replies to the challenge with an NS(EARO) that includes a new tionFormat="of" derivedContent="Figure 6"/>), the CIPO (<xref target="cryptoidop
Nonce option (shown as NonceLN in <xref target='Dynamic-fig'/>), the CIPO (<xre t" format="default" sectionFormat="of" derivedContent="Section 4.3"/>), and the
f target='cryptoidopt'/>), and the NDPSO containing the signature. Both Nonces a NDPSO containing the signature. Both nonces are included in the signed material.
re included in the signed material. This provides a "contributory behavior" that results in better security even wh
This provides a "contributory behavior", so that either party that knows en the nonces of one party are not generated as specified.
it generates a good quality nonce knows that the protocol will be secure. </t>
</t> <t indent="0" pn="section-6.1-6">
<t> The 6LR <bcp14>MUST</bcp14> store the information associated with a Cryp
The 6LR MUST store the information associated to a Crypto-ID on the firs to-ID on the first NS exchange where it appears in a fashion that the CIPO param
t NS exchange where it appears in a fashion that the CIPO parameters can be retr eters can be retrieved from the Crypto-ID alone.
ieved from the Crypto-ID alone.
</t>
<t>The steps for the registration to the 6LR are as follows:
</t> </t>
<t> <t indent="0" pn="section-6.1-7">The steps for the registration to the 6
Upon the first exchange with a 6LR, a 6LN will be challenged to prov LR are as follows:
e ownership of the Crypto-ID and the Target Address being registered in the Neig
hbor Solicitation message. When a 6LR receives a NS(EARO) registration with a ne
w Crypto-ID as a ROVR, and unless the registration is rejected for another reaso
n, it MUST challenge by responding with a NA(EARO) with a status of "Validation
Requested".
</t> </t>
<t> <t indent="0" pn="section-6.1-8">
Upon receiving a first NA(EARO) with a status of "Validation Request Upon the first exchange with a 6LR, a 6LN will be challenged to prov
ed" from a 6LR, the registering node SHOULD retry its registration with a Crypto e ownership of the Crypto-ID and the Target Address being registered in the Neig
-ID Parameters Option (CIPO) (<xref target='cryptoidopt'/>) that contains all th hbor Solicitation message. When a 6LR receives an NS(EARO) registration with a n
e necessary material for building the Crypto-ID, the NonceLN that it generated, ew Crypto-ID as a ROVR, and unless the registration is rejected for another reas
and the NDP signature (<xref target='ndpso'/>) option that proves its ownership on, it <bcp14>MUST</bcp14> challenge by responding with an NA(EARO) with a statu
of the Crypto-ID and intent of registering the Target Address. In subsequent rev s code of "Validation Requested".
alidation with the same 6LR, the 6LN MAY try to omit the CIPO to save bandwidth,
with the expectation that the 6LR saved it. If the validation fails and it gets
challenged again, then it SHOULD add the CIPO again.
</t> </t>
<t> <t indent="0" pn="section-6.1-9">
In order to validate the ownership, the 6LR performs the same steps Upon receiving a first NA(EARO) with a status code of "Validation Re
as the 6LN and rebuilds the Crypto-ID based on the parameters in the CIPO. If th quested" from a 6LR, the Registering Node <bcp14>SHOULD</bcp14> retry its regist
e rebuilt Crypto-ID matches the ROVR, the 6LN also verifies the signature contai ration with a CIPO (<xref target="cryptoidopt" format="default" sectionFormat="o
ned in the NDPSO option. If at that point the signature in the NDPSO option can f" derivedContent="Section 4.3"/>) that contains all the necessary material for
be verified, then the validation succeeds. Otherwise the validation fails. building the Crypto-ID, the NonceLN that it generated, and the NDP Signature Opt
ion (<xref target="ndpso" format="default" sectionFormat="of" derivedContent="Se
ction 4.4"/>) that proves its ownership of the Crypto-ID and intent of registeri
ng the Target Address. In subsequent revalidation with the same 6LR, the 6LN <bc
p14>MAY</bcp14> try to omit the CIPO to save bandwidth, with the expectation tha
t the 6LR saved it. If the validation fails and it gets challenged again, then i
t <bcp14>SHOULD</bcp14> add the CIPO again.
</t> </t>
<t> <t indent="0" pn="section-6.1-10">
If the 6LR fails to validate the signed NS(EARO), it responds with a In order to validate the ownership, the 6LR performs the
status of "Validation Failed". After receiving a NA(EARO) with a status of "Val same steps as the 6LN and rebuilds the Crypto-ID based on
idation Failed", the parameters in the CIPO. If the rebuilt Crypto-ID
the registering node SHOULD try and alternate Crypto-Type and if eve matches the ROVR, the 6LN also verifies the signature
n Crypto-Type 0 fails, it may try to register a different address in the NS mess contained in the NDPSO. At that point, if the signature in the NDPSO
age. can be verified, then the validation succeeds. Otherwise, the validation fails.
</t>
</t> <t indent="0" pn="section-6.1-11">
</section> If the 6LR fails to validate the signed NS(EARO), it responds with a
status code of "Validation Failed". After receiving an NA(EARO) with a status c
<section anchor='ndpso-generation'><name>NDPSO generation and verification</ ode of "Validation Failed",
name> the Registering Node <bcp14>SHOULD</bcp14> try an alternate Crypto-T
ype; even if Crypto-Type 0 fails, it may try to register a different address in
the NS message.
<t> </t>
The signature generated by the 6LN to provide proof-of-ownership of </section>
the <section anchor="ndpso-generation" numbered="true" removeInRFC="false" toc
private-key is carried in the NDP Signature Option (NDPSO). ="include" pn="section-6.2">
<name slugifiedName="name-ndpso-generation-and-verifi">NDPSO Generation
and Verification</name>
<t indent="0" pn="section-6.2-1">
The signature generated by the 6LN to provide proof of ownership of
the
private key is carried in the NDPSO.
It is generated by the 6LN in a fashion that depends on the Cryp to-Type It is generated by the 6LN in a fashion that depends on the Cryp to-Type
(see <xref target='cryptotypetable'/> in (see <xref target="cryptotypetable" format="default" sectionForm
<xref target='cryptotypereg'/>) chosen by the 6LN as follows: at="of" derivedContent="Table 1"/> in
</t> <xref target="cryptotypereg" format="default" sectionFormat="of"
<ul> derivedContent="Section 8.2"/>) chosen by the 6LN as follows:
<li><t> Form the message to be signed, by concatenating the following b </t>
yte-strings in the order listed:</t> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6
.2-2">
<ol spacing='compact'> <li pn="section-6.2-2.1">
<li>The 128-bit Message Type tag <xref target='RFC3972'/> <t indent="0" pn="section-6.2-2.1.1"> Form the message to be signed,
(in network byte order). by concatenating the following byte-strings in the order listed:</t>
For this specification the tag is given in <xref target='cgam'/> <ol spacing="normal" indent="adaptive" start="1" type="1" pn="sectio
. n-6.2-2.1.2">
(The tag value has been generated by the editor of this specifica <li pn="section-6.2-2.1.2.1" derivedCounter="1.">The 128-
tion on random.org).</li> bit Message Type tag <xref target="RFC3972" format="default" sectionFormat="of"
<li>the CIPO</li> derivedContent="RFC3972"/> (in network byte order).
<li>the 16-byte Target Address (in network byte order) se For this specification, the tag is given in <xref target="cgam"
nt in the Neighbor Solicitation (NS) message. It is the address which the 6LN is format="default" sectionFormat="of" derivedContent="Section 8.1"/>.
registering with the 6LR and 6LBR.</li> (The tag value has been generated by the editor of this specifica
<li>NonceLR received from the 6LR (in network byte order) tion on <eref target="https://www.random.org" brackets="angle"/>.)</li>
in the Neighbor Advertisement (NA) message. The nonce is at least 6 bytes long <li pn="section-6.2-2.1.2.2" derivedCounter="2.">The CIPO.</li>
as defined in <xref target='RFC3971'/>.</li> <li pn="section-6.2-2.1.2.3" derivedCounter="3.">The 16-byte Targe
<li>NonceLN sent from the 6LN (in network byte order). Th t Address (in network byte order) sent in the NS message. It is the address that
e nonce is at least 6 bytes long as defined in <xref target='RFC3971'/>.</li> the 6LN is registering with the 6LR and 6LBR.</li>
<li>1-byte Option Length of the EARO containing the Crypto-ID.</ <li pn="section-6.2-2.1.2.4" derivedCounter="4.">The NonceLR recei
li> ved from the 6LR (in
</ol> network byte order) in the NA message. The
nonce is at least 6 bytes long as defined in <xref target
="RFC3971" format="default" sectionFormat="of" derivedContent="RFC3971"/>.</li>
<li pn="section-6.2-2.1.2.5" derivedCounter="5.">The NonceLN sent
from the 6LN (in network
byte order). The nonce is at least 6 bytes long as define
d in <xref target="RFC3971" format="default" sectionFormat="of" derivedContent="
RFC3971"/>.</li>
<li pn="section-6.2-2.1.2.6" derivedCounter="6.">The 1-byte option
length of the EARO containing the Crypto-ID.</li>
</ol>
</li> </li>
<li> <li pn="section-6.2-2.2">
Apply the signature algorithm specified by the Crypto-Type using the p rivate key.</li> Apply the signature algorithm specified by the Crypto-Type using the p rivate key.</li>
</ul> </ul>
<t indent="0" pn="section-6.2-3">
<t> Upon receiving the NDPSO and CIPO options, the 6LR first checks that
The 6LR on receiving the NDPSO and CIPO options first checks that th the EARO Length in the CIPO matches the length of the EARO. If so, it regenerat
e EARO Length in the CIPO matches the length of the EARO. If so it regenerates t es the Crypto-ID based on the CIPO to make sure that the leftmost bits up to the
he Crypto-ID based on the CIPO to make sure that the leftmost bits up to the siz size of the ROVR match.
e of the ROVR match. </t>
</t> <t indent="0" pn="section-6.2-4">
<t> If, and only if, the check is successful, it tries to verify
If and only if the check is successful, it tries to verify the signatur the signature in the NDPSO using the following steps:
e in the NDPSO option using the following: </t>
</t> <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6
<ul> .2-5">
<li><t>Form the message to be verified, by concatenating the following <li pn="section-6.2-5.1">
byte-strings in the order listed:</t> <t indent="0" pn="section-6.2-5.1.1">Form the message to be verified
<ol spacing='compact'> , by concatenating the following byte-strings in the order listed:</t>
<li>The 128-bit Message Type tag given in <xref target='cgam'/> <ol spacing="normal" indent="adaptive" start="1" type="1" pn="sectio
(in network byte order)</li> n-6.2-5.1.2">
<li>the CIPO</li> <li pn="section-6.2-5.1.2.1" derivedCounter="1.">The 128-bit Mes
<li>the 16-byte Target Address (in network byte order) received sage Type tag given in <xref target="cgam" format="default" sectionFormat="of" d
in the Neighbor Solicitation (NS) message. It is the address which the 6LN is re erivedContent="Section 8.1"/> (in network byte order).</li>
gistering with the 6LR and 6LBR.</li> <li pn="section-6.2-5.1.2.2" derivedCounter="2.">The CIPO.</li>
<li>NonceLR sent in the Neighbor Advertisement (NA) message. The <li pn="section-6.2-5.1.2.3" derivedCounter="3.">The 16-byte Targe
nonce is at least 6 bytes long as defined in <xref target='RFC3971'/>.</li> t Address (in network byte order) received in the NS message. It is the address
<li>NonceLN received from the 6LN (in network byte order) in the that the 6LN is registering with the 6LR and 6LBR.</li>
NS message. The nonce is at least 6 bytes long as defined in <xref target='RFC3 <li pn="section-6.2-5.1.2.4" derivedCounter="4.">The NonceLR sent
971'/>.</li> in the NA message. The nonce is
<li>1-byte EARO Length received in the CIPO.</li> at least 6 bytes long as defined in <xref target="RFC3971" format
</ol> ="default" sectionFormat="of" derivedContent="RFC3971"/>.</li>
</li> <li pn="section-6.2-5.1.2.5" derivedCounter="5.">The NonceLN recei
<li> ved from the 6LN (in network byte
Verify the signature on this message with the public-key in the CIPO a order) in the NS message. The nonce is at least 6 bytes long as d
nd the locally computed values using the signature algorithm specified by the Cr efined in <xref target="RFC3971" format="default" sectionFormat="of" derivedCont
ypto-Type. If the verification succeeds, the 6LR propagates the information to t ent="RFC3971"/>.</li>
he 6LBR using a EDAR/EDAC flow. <li pn="section-6.2-5.1.2.6" derivedCounter="6.">The 1-byte EARO L
ength received in the CIPO.</li>
</ol>
</li> </li>
<li> <li pn="section-6.2-5.2">
Due to the first-come/first-serve nature of the registration, if the a Verify the signature on this message with the public key in the CIPO a
ddress is not registered to the 6LBR, then flow succeeds and both the 6LR and 6L nd the locally computed values using the signature algorithm specified by the Cr
BR add the state information about the Crypto-ID and Target Address being regist ypto-Type. If the verification succeeds, the 6LR propagates the information to t
ered to their respective abstract database. he 6LBR using an EDAR/EDAC flow.
</li>
<li pn="section-6.2-5.3">
Due to the first-come, first-served nature of the registration, if the
address is not registered to the 6LBR, then flow succeeds and both the 6LR and
6LBR add the state information about the Crypto-ID and Target Address being regi
stered to their respective abstract databases.
</li> </li>
</ul> </ul>
</section>
</section> <section anchor="mhopo" numbered="true" removeInRFC="false" toc="include"
pn="section-6.3">
<section anchor='mhopo'><name>Multihop Operation</name> <name slugifiedName="name-multi-hop-operation">Multi-Hop Operation</name
<t> >
A new 6LN that joins the network auto-configures an address and performs an <t indent="0" pn="section-6.3-1">
initial registration to a neighboring 6LR with an NS message that carries an Ad A new 6LN that joins the network autoconfigures an address and performs an
dress Registration Option (EARO) <xref target='RFC8505'/>. initial registration to a neighboring 6LR with an NS message that carries an EAR
</t> O <xref target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC
<t> 8505"/>.
In a multihop 6LoWPAN, the registration with Crypto-ID is propagated to 6LB </t>
R as shown in <xref target='figReg'/>, which illustrates the <t indent="0" pn="section-6.3-2">
registration flow all the way to a 6LowPAN Backbone Router (6BBR) In a multi-hop 6LoWPAN, the registration with Crypto-ID is propagated to 6L
<xref target='I-D.ietf-6lo-backbone-router'/>. BR as shown in <xref target="figReg" format="default" sectionFormat="of" derived
</t> Content="Figure 7"/>, which illustrates the
registration flow all the way to a 6LoWPAN Backbone Router (6BBR)
<figure anchor='figReg' suppress-title='false'><name>(Re-)Registration Fl <xref target="RFC8929" format="default" sectionFormat="of" derivedContent="R
ow</name> FC8929"/>.
<artwork><![CDATA[ </t>
<figure anchor="figReg" suppress-title="false" align="left" pn="figure-7
">
<name slugifiedName="name-re-registration-flow">(Re-)Registration Flow
</name>
<artwork align="left" pn="section-6.3-3.1">
6LN 6LR 6LBR 6BBR 6LN 6LR 6LBR 6BBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | | |---------------&gt;| | |
| | Extended DAR | | | | Extended DAR | |
| |-------------->| | | |--------------&gt;| |
| | | proxy NS(EARO) | | | | proxy NS(EARO) |
| | |--------------->| | | |---------------&gt;|
| | | | NS(DAD) | | | | NS(DAD)
| | | | ------> | | | | ------&gt;
| | | | | | | |
| | | | <wait&gt; | | | | <wait&gt;
| | | | | | | |
| | | proxy NA(EARO) | | | | proxy NA(EARO) |
| | |<---------------| | | |&lt;---------------|
| | Extended DAC | | | | Extended DAC | |
| |<--------------| | | |&lt;--------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |&lt;---------------| | |
| | | | | | | |
]]></artwork> </artwork>
</figure> </figure>
<t indent="0" pn="section-6.3-4">
<t> The 6LR and the 6LBR communicate using ICMPv6 EDAR and EDAC messages <xref
The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate Address Re target="RFC8505" format="default" sectionFormat="of" derivedContent="RFC8505"/>
quest (EDAR) and Extended Duplicate Address Confirmation (EDAC) messages <xref t as shown in <xref target="figReg" format="default" sectionFormat="of" derivedCon
arget='RFC8505'/> as shown in <xref target='figReg'/>. tent="Figure 7"/>.
This specification extends EDAR/EDAC messages to carry cryptographically ge nerated ROVR. This specification extends EDAR/EDAC messages to carry cryptographically ge nerated ROVR.
</t> </t>
<t> <t indent="0" pn="section-6.3-5">
The assumption is that the 6LR and the 6LBR maintain a security association The assumption is that the 6LR and the 6LBR maintain a security association
to authenticate and protect the integrity of the EDAR and EDAC messages, so the to authenticate and protect the integrity of the EDAR and EDAC messages, so the
re is no need to propagate the proof of ownership to the 6LBR. The 6LBR implicit re is no need to propagate the proof of ownership to the 6LBR. The 6LBR implicit
ly trusts that the 6LR performs the verification when the 6LBR requires it, and ly trusts that the 6LR performs the verification when the 6LBR requires it, and
if there is no further exchange from the 6LR to remove the state, that the verif if there is no further exchange from the 6LR to remove the state, the verificati
ication succeeded. on succeeded.
</t> </t>
</section>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-7">
</section> <name slugifiedName="name-security-considerations">Security Considerations
</name>
<section><name>Security Considerations</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-7.1
">
<section><name>Brown Field</name> <name slugifiedName="name-brown-field">Brown Field</name>
<t> <t indent="0" pn="section-7.1-1">
Only 6LRs that are upgraded to this specification are capable to challenge a Only 6LRs that are upgraded to this specification are capable of challenging
registration and repel an attack. a registration and avoiding an attack. In a brown (mixed) network, an attacker
In a brown (mixed) network, an attacker may attach to a legacy may attach to a legacy 6LR and fool the 6LBR. So even if the "A" flag could be s
6LR and fool the 6LBR. et at any time to
So even if the "A" flag could be set at any time to
test the protocol operation, the security will only be effective when all th e 6LRs are upgraded. test the protocol operation, the security will only be effective when all th e 6LRs are upgraded.
</t> </t>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-7.2
<section><name>Inheriting from RFC 3971</name> ">
<t> <name slugifiedName="name-threats-identified-in-rfc-3">Threats Identifie
Observations regarding the following threats to the local network in < d in RFC 3971</name>
xref target='RFC3971'/> also apply to this specification. <t indent="0" pn="section-7.2-1">
</t> Observations regarding the following threats to the local network in <
<dl spacing='normal'> xref target="RFC3971" format="default" sectionFormat="of" derivedContent="RFC397
<dt>Neighbor Solicitation/Advertisement Spoofing:</dt><dd> 1"/> also apply to this specification.
Threats in section 9.2.1 of RFC3971 apply. AP-ND counter </t>
s the threats on NS(EARO) messages by requiring that the NDP Signature and CIPO <dl spacing="normal" indent="3" newline="false" pn="section-7.2-2">
options be present in these solicitations.</dd> <dt pn="section-7.2-2.1">Neighbor Solicitation/Advertisement Spoofing:
<!--<t hangText="Neighbor Unreachability Detection Failure"> </dt>
<vspace blankLines="1"/> <dd pn="section-7.2-2.2">
With RFC6775, a Neighbor Unreadability Detection (NUD) ca Threats in <xref target="RFC3971" sectionFormat="of" sect
n still be used by the endpoint to assess the liveness of a device. The NUD requ ion="9.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3971#sec
est may be protected by SEND in which case the provision in section 9.2 of RFC 3 tion-9.2.1" derivedContent="RFC3971"/> apply. AP-ND counters the threats on NS(E
972 applies. The response to the NUD may be proxied by a backbone router only if ARO) messages by requiring that the NDPSO and CIPO be present in these solicitat
it has a fresh registration state for it. For a registration being protected by ions.</dd>
this specification, the proxied NUD response provides truthful information on t <dt pn="section-7.2-2.3">Duplicate Address Detection DoS Attack:</dt>
he original owner of the address but it cannot be proven using SEND. If the NUD <dd pn="section-7.2-2.4">
response is not proxied, the 6LR will pass the lookup to the end device which wi Inside the LLN, duplicate addresses are sorted out using t
ll respond with a traditional NA. If the 6LR does not have a registration associ he ROVR. A different ROVR for the same Registered Address entails a rejection of
ated for the device, it can issue a NA with EARO (status=Validation Requested) u the second registration <xref target="RFC8505" format="default" sectionFormat="
pon the NA from the device, which will trigger a NS that will recreate and reval of" derivedContent="RFC8505"/>. DADs coming from the backbone network are not fo
idate the ND registration. rwarded over the LLN to provide some protection against DoS attacks inside the r
</t>--> esource-constrained part of the network. However, the EARO is present in the NS/
<dt>Duplicate Address Detection DoS Attack:</dt><dd> NA messages exchanged over the backbone network. This protects against misinterp
Inside the LLN, Duplicate Addresses are sorted out using t reting node movement as a duplication and enables the Backbone Routers to determ
he ROVR, which differentiates it from a movement. A different ROVR for the same ine which subnet has the most recent registration <xref target="RFC8505" format=
Registered address entails a rejection of the second registration <xref target=' "default" sectionFormat="of" derivedContent="RFC8505"/> and is thus the best can
RFC8505'/>. didate to validate the registration <xref target="RFC8929" format="default" sect
DAD coming from the backbone are not forwarded over the LL ionFormat="of" derivedContent="RFC8929"/>.
N, which provides some protection against DoS attacks inside the resource-constr
ained part of the network. Over the backbone, the EARO option is present in NS/N
A messages. This protects against misinterpreting a movement for a duplication,
and enables the backbone routers to determine which one has the freshest registr
ation <xref target='RFC8505'/> and is thus the best candidate to validate the re
gistration for the device attached to it <xref target='I-D.ietf-6lo-backbone-rou
ter'/>. But this specification does not guarantee that the backbone router claim
ing an address over the backbone is not an attacker.
</dd> </dd>
<dt>Router Solicitation and Advertisement Attacks:</dt><dd> <dt pn="section-7.2-2.5">Router Solicitation and Advertisement Attacks
This specification does not change the protection of RS a :</dt>
nd RA which can still be protected by SEND.</dd> <dd pn="section-7.2-2.6">
<dt>Replay Attacks</dt><dd> This specification does not change the protection of RS a
A nonce should never repeat for a single key, but nonces nd RA, which can still be protected by SEND.</dd>
do not need to be unpredictable for secure operation. Using nonces (NonceLR and <dt pn="section-7.2-2.7">Replay Attacks:</dt>
NonceLN) generated by both the 6LR and 6LN ensure a contributory behavior that p <dd pn="section-7.2-2.8">
rovides an efficient protection against replay attacks of the challenge/response Nonces should never repeat but they do not need to be unp
flow. The quality of the protection by a random nonce depends on the random num redictable for secure operation. Using nonces (NonceLR and NonceLN) generated by
ber generator and its parameters (e.g., sense of time). both the 6LR and 6LN ensures a contributory behavior that provides an efficient
protection against replay attacks of the challenge/response flow. The quality o
f the protection by a random nonce depends on the random number generator.
</dd> </dd>
<dt>Neighbor Discovery DoS Attack:</dt><dd> <dt pn="section-7.2-2.9">Neighbor Discovery DoS Attack:</dt>
A rogue node that managed to access the L2 network may fo <dd pn="section-7.2-2.10">
rm many addresses and register them using AP-ND. The perimeter of the attack is A rogue node that can access the L2 network may form many
all the 6LRs in range of the attacker. The 6LR MUST protect itself against overf addresses and register them using AP-ND. The perimeter of the attack is all the
lows and reject excessive registration with a status 2 "Neighbor Cache Full". Th 6LRs in range of the attacker. The 6LR <bcp14>MUST</bcp14> protect itself again
is effectively blocks another (honest) 6LN from registering to the same 6LR, but st overflows and reject excessive registration with a status code of 2 "Neighbor
the 6LN may register to other 6LRs that are in its range but not in that of the Cache Full". This effectively blocks another (honest) 6LN from registering to t
rogue. he same 6LR, but the 6LN may register to other 6LRs that are in its range but no
t in that of the attacker.
</dd> </dd>
</dl> </dl>
</section> </section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-7.3
">
<name slugifiedName="name-related-to-6lowpan-nd">Related to 6LoWPAN ND</
name>
<t indent="0" pn="section-7.3-1">
The threats and mitigations discussed in 6LoWPAN ND
<xref target="RFC6775" format="default" sectionFormat="of" derive
dContent="RFC6775"/> <xref target="RFC8505" format="default" sectionFormat="of"
derivedContent="RFC8505"/> also
apply here, in particular, denial-of-service (DoS) attacks agains
t the registry at the 6LR or 6LBR.
<section><name>Related to 6LoWPAN ND</name> </t>
<t> <t indent="0" pn="section-7.3-2">
The threats and mediations discussed in 6LoWPAN ND <xref target=' Secure ND <xref target="RFC3971" format="default" sectionFormat="of"
RFC6775'/><xref target='RFC8505'/> also apply here, in particular denial-of-serv derivedContent="RFC3971"/> forces the IPv6 address to be cryptographic since it
ice attacks against the registry at the 6LR or 6LBR. integrates the CGA as the IID in the IPv6 address. In contrast, this specificat
ion saves about 1 KB in every NS/NA message. Also, this specification separates
the cryptographic identifier from the registered IPv6 address so that a node can
have more than one IPv6 address protected by the same cryptographic identifier.
</t>
<t indent="0" pn="section-7.3-3">
With this specification, the 6LN can freely form its IPv6 address(es
) in any fashion, thereby enabling either 6LoWPAN compression for IPv6 addresses
that are derived from L2 addresses or temporary addresses that cannot be compre
ssed, e.g., formed pseudorandomly and released in relatively short cycles for pr
ivacy reasons <xref target="RFC8064" format="default" sectionFormat="of" derived
Content="RFC8064"/><xref target="RFC8065" format="default" sectionFormat="of" de
rivedContent="RFC8065"/>.
</t>
<t indent="0" pn="section-7.3-4">
This specification provides added protection for addresses that are
obtained following due procedure <xref target="RFC8505" format="default" section
Format="of" derivedContent="RFC8505"/> but does not constrain the way the addres
ses are formed or the number of addresses that are used in parallel by a same en
tity. An attacker may still perform a DoS attack against the registry at the 6LR
or 6LBR or attempt to deplete the pool of available addresses at L2 or L3.
</t><t> </t>
Secure ND <xref target='RFC3971'/> forces the IPv6 address to be cry </section>
ptographic since it integrates the CGA as the IID in the IPv6 address. In contra <section numbered="true" removeInRFC="false" toc="include" pn="section-7.4
st, this specification saves about 1Kbyte in every NS/NA message. Also, this spe ">
cification separates the cryptographic identifier from the registered IPv6 addre <name slugifiedName="name-compromised-6lr">Compromised 6LR</name>
ss so that a node can have more than one IPv6 address protected by the same cryp <t indent="0" pn="section-7.4-1">
tographic identifier. This specification distributes the challenge and its validation at the e
</t><t> dge of the network, between the 6LN and its 6LR. This protects against DoS attac
With this specification the 6LN can freely form its IPv6 address(es) ks targeted at that central 6LBR. This also saves back-and-forth exchanges acros
in any fashion, thereby enabling either 6LoWPAN compression for IPv6 addresses s a potentially large and constrained network.
that are derived from Layer-2 addresses, or temporary addresses, e.g., formed ps </t>
eudo-randomly and released in relatively short cycles for privacy reasons <xref <t indent="0" pn="section-7.4-2">
target='RFC8064'/><xref target='RFC8065'/>, that cannot be compressed. The downside is that the 6LBR needs to trust the 6LR to perform the chec
</t><t> king adequately, and the communication between the 6LR and the 6LBR must be prot
This specification provides added protection for addresses that are ected to avoid tampering with the result of the validation.
obtained following due procedure <xref target='RFC8505'/> but does not constrai
n the way the addresses are formed or the number of addresses that are used in p
arallel by a same entity. A rogue may still perform denial-of-service attack aga
inst the registry at the 6LR or 6LBR, or attempt to deplete the pool of availabl
e addresses at Layer-2 or Layer-3.
</t> </t>
</section> <t indent="0" pn="section-7.4-3">
<section><name>Compromised 6LR</name> If a 6LR is compromised, and provided that it knows the ROVR field used b
<t> y the real owner of the address, the 6LR may pretend that the owner has moved, i
This specification distributes the challenge and its validation at the e s now attached to it, and has successfully passed the Crypto-ID validation. The
dge of the network, between the 6LN and its 6LR. This protects against DOS attac 6LR may then attract and inject traffic at will on behalf of that address, or le
ks targeted at that central 6LBR. This also saves back and forth exchanges acros t an attacker take ownership of the address.
s a potentially large and constrained network. </t>
</t><t> </section>
The downside is that the 6LBR needs to trust the 6LR for performing the <section anchor="sec-col" numbered="true" removeInRFC="false" toc="include
checking adequately, and the communication between the 6LR and the 6LBR must be " pn="section-7.5">
protected to avoid tampering with the result of the test. <name slugifiedName="name-rovr-collisions">ROVR Collisions</name>
<t indent="0" pn="section-7.5-1">
</t><t> A collision of ROVRs (i.e., the Crypto-ID in this specification) is possi
If a 6LR is compromised, and provided that it knows the ROVR field used b ble, but it is a rare event. Assuming that the hash used for calculating the Cry
y the real owner of the address, the 6LR may pretend that the owner has moved, i pto-ID is a well-behaved cryptographic hash, and, thus, random collisions are th
s now attached to it and has successfully passed the Crpto-ID validation. The 6L e only ones possible, if n = 2<sup>k</sup> is the maximum number of hash values
R may then attract and inject traffic at will on behalf of that address or let a (i.e., a k-bit hash) and p is the number of nodes, then (assuming one Crypto-ID
rogue take ownership of the address. per node) the formula 1 - e<sup>-p<sup>2</sup>/(2n)</sup> provides an approximat
</t> ion of the probability that there is at least one collision (birthday paradox).
</section> </t>
<section anchor='sec-col'><name>ROVR Collisions</name> <t indent="0" pn="section-7.5-2">
<t> If the Crypto-ID is 64 bits (the least possible size allowed), the chanc
A collision of Registration Ownership Verifiers (ROVR) (i.e., the Crypto- e of a collision is 0.01% for a network of 66 million nodes. Moreover, the colli
ID in this specification) is possible, but it is a rare event. sion is only relevant when this happens within one stub network (6LBR). In the c
Assuming in the calculations/discussion below that the hash used for cal ase of such a collision, an honest node might accidentally claim the Registered
culating the Crypto-ID is a well-behaved cryptographic hash and thus Address of another legitimate node (with the same Crypto-ID). To prevent such ra
that random collisions are the only ones possible, the formula (birthday re events, it is <bcp14>RECOMMENDED</bcp14> that nodes do not derive the address
paradox) for calculating the probability of a collision is 1 - e^{-p^2/(2n)} wh being registered from the ROVR.
ere n is the maximum population size (2^64 here, 1.84E19) and p is the actual po </t>
pulation (number of nodes, assuming one Crypto-ID per node). </section>
</t><t> <section numbered="true" removeInRFC="false" toc="include" pn="section-7.6
If the Crypto-ID is 64-bits (the least possible size allowed), the chanc ">
e of a collision is 0.01% for network of 66 million nodes. Moreover, the collisi <name slugifiedName="name-implementation-attacks">Implementation Attacks
on is only relevant when this happens within one stub network (6LBR). In the cas </name>
e of such a collision, a third party node would be able to claim the registered <t indent="0" pn="section-7.6-1"> The signature schemes referenced in th
address of an another legitimate node, provided that it wishes to use the same a is specification comply with NIST <xref target="FIPS186-4" format="default" sect
ddress. ionFormat="of" derivedContent="FIPS186-4"/> or Crypto Forum Research Group (CFRG
To prevent address disclosure and avoid the chances of collision on both ) standards <xref target="RFC8032" format="default" sectionFormat="of" derivedCo
the ROVR and the address, it is RECOMMENDED that nodes do not derive the addres ntent="RFC8032"/> and offer strong algorithmic security at roughly a 128-bit sec
s being registered from the ROVR. urity level. These signature schemes use elliptic curves that either were specif
</t> ically designed with exception-free and constant-time arithmetic in mind <xref t
</section> arget="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/> o
<section><name>Implementation Attacks</name> r have extensive implementation experience of resistance
<t> The signature schemes referenced in this specification comply with NI to timing attacks <xref target="FIPS186-4" format="default" secti
ST <xref target='FIPS186-4'/> or Crypto Forum Research Group (CFRG) standards onFormat="of" derivedContent="FIPS186-4"/>.
<xref target='RFC8032'/> and offer strong algorithmic security at
roughly 128-bit security level. These signature schemes use elliptic curves tha
t were either
specifically designed with exception-free and constant-time arith
metic in mind <xref target='RFC7748'/> or where one has extensive implementation
experience of resistance
to timing attacks <xref target='FIPS186-4'/>.
</t> </t>
<t> <t indent="0" pn="section-7.6-2">
However, careless implementations of the signing operations could nevert heless leak information on private keys. For example, However, careless implementations of the signing operations could nevert heless leak information on private keys. For example,
there are micro-architectural side channel attacks that implement ors should be aware of <xref target='breaking-ed25519'/>. there are micro-architectural side channel attacks that implement ors should be aware of <xref target="breaking-ed25519" format="default" sectionF ormat="of" derivedContent="breaking-ed25519"/>.
Implementors should be particularly aware that Implementors should be particularly aware that
a secure implementation of Ed25519 requires a protected implement ation of the hash function SHA-512, whereas this is not required with implementa tions of the hash function a secure implementation of Ed25519 requires a protected implement ation of the hash function SHA-512, whereas this is not required with implementa tions of the hash function
SHA-256 used with ECDSA256 and ECDSA25519. SHA-256 used with ECDSA256 and ECDSA25519.
</t>
</section>
<section><name>Cross-Algorithm and Cross-Protocol Attacks</name>
<t>
The keypair used in this specification can be self-generated and the pub
lic key does not need to be exchanged, e.g., through certificates, with a third
party before it is used.
</t> </t>
<t> </section>
New keypairs can be formed for new registration as the node desires. <section numbered="true" removeInRFC="false" toc="include" pn="section-7.7
On the other hand, it is safer to allocate a keypair that is used only f ">
or the address protection and only for one instantiation of the signature scheme <name slugifiedName="name-cross-algorithm-and-cross-p">Cross-Algorithm a
(which includes nd Cross-Protocol Attacks</name>
choice of elliptic curve domain parameters, used hash function, a <t indent="0" pn="section-7.7-1">
nd applicable representation conventions). The key pair used in this specification can be self-generated, and the p
ublic key does not need to be exchanged, e.g., through certificates, with a thir
d party before it is used.
</t> </t>
<t> <t indent="0" pn="section-7.7-2">
The same private key MUST NOT be reused with more than one instantiation New key pairs can be formed for new registrations if the node desires. H
of the signature scheme in this specification. The same private key MUST NOT be owever, the same private key <bcp14>MUST NOT</bcp14> be reused with more than on
used for anything other than computing NDPSO signatures per this specification. e instantiation of the signature scheme in this specification. Also, the same pr
</t> ivate key <bcp14>MUST NOT</bcp14> be used for anything other than computing NDPS
O signatures per this specification.
<t> ECDSA shall be used strictly as specified in <xref target="FI </t>
PS186-4"></xref>. In particular, each signing operation of ECDSA MUST use random <t indent="0" pn="section-7.7-3"> ECDSA shall be used strictly as specif
ly generated ied in <xref target="FIPS186-4" format="default" sectionFormat="of" derivedConte
ephemeral private keys and MUST NOT reuse these ephemeral private nt="FIPS186-4"/>. In particular, each signing operation of ECDSA <bcp14>MUST</bc
keys k accross signing operations. This precludes the use of deterministic ECDS p14> use randomly generated ephemeral private keys and <bcp14>MUST NOT</bcp14> r
A without a random input euse the ephemeral private key k across signing operations. This precludes the u
for determination of k, which is deemed dangerous for the intende se of deterministic ECDSA without a random input for the determination of k, whi
d applications this document aims to serve.</t> ch is deemed dangerous for the intended applications this document aims to serve
</section> .</t>
</section>
<section><name>Public Key Validation</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-7.8
<t>Public keys contained in the CIPO field (which are used for signature ">
verification) shall be verified to be correctly formed, by checking that this pu <name slugifiedName="name-public-key-validation">Public Key Validation</
blic key is indeed a name>
<t indent="0" pn="section-7.8-1">Public keys contained in the CIPO field
(which are used for signature verification) shall be verified to be correctly f
ormed, by checking that this public key is indeed a
point of the elliptic curve indicated by the Crypto-Type and that this po int does have the proper order. point of the elliptic curve indicated by the Crypto-Type and that this po int does have the proper order.
</t>
<t>
For points used with the signature scheme Ed25519, one MUST check
that this point is not a point in the small subgroup (see Appendix B.1 of
<xref target='I-D.ietf-lwig-curve-representations'/>); for points used with the
signature scheme
ECDSA (i.e., both ECDSA256 and ECDSA25519), one MUST check that the point
has the same order as the base point of the curve in question. This is commonly
called
full public key validation (again, see Appendix B.1 of <xref target='I-D.
ietf-lwig-curve-representations'/>). </t>
</section>
<section><name>Correlating Registrations</name>
<t>
The ROVR field in the EARO introduced in <xref target='RFC8505'/> exte
nds the EUI-64 field of the ARO defined in <xref target='RFC6775'/>. One of the
drawbacks of using an EUI-64 as ROVR is that an attacker that is aware of the re
gistrations can correlate traffic for a same 6LN across multiple addresses. Sect
ion 3 of <xref target='RFC8505'/> indicates that the ROVR and the address being
registered are decoupled. A 6LN may use a same ROVR for multiple registrations o
r a different ROVR per registration, and the IID must not derive from the ROVR.
In theory different 6LNs could use a same ROVR as long as they do not attempt to
register the same address.
</t>
<t>
The Modifier used in the computation of the Crypto-ID enables a 6LN to
build different Crypto-IDs for different addresses with a same keypair. Using t
hat facility improves the privacy of the 6LN as the expense of storage in the 6L
R, which will need to store multiple CIPOs that contain the same public key. Not
e that if the attacker is the 6LR, then the Modifier alone does not provide a pr
otection, and the 6LN would need to use different keys and MAC addresses in an a
ttempt to obfuscate its multiple ownership.
</t> </t>
<t indent="0" pn="section-7.8-2">
For points used with the signature scheme Ed25519, one <bcp14>MUST</bcp1
4> check
that this point is not in the small subgroup (see <xref target="I-D.ietf-
lwig-curve-representations" sectionFormat="of" section="B.1" format="default" de
rivedLink="https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-14#
appendix-B.1" derivedContent="CURVE-REPR"/>); for points used with the signature
scheme
ECDSA (i.e., both ECDSA256 and ECDSA25519), one <bcp14>MUST</bcp14> check
that the point has the same order as the base point of the curve in question. T
his is commonly called
"full public key validation" (again, see <xref target="I-D.ietf-lwig-curv
e-representations" sectionFormat="of" section="B.1" format="default" derivedLink
="https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-14#appendix-
B.1" derivedContent="CURVE-REPR"/>). </t>
</section>
<section numbered="true" removeInRFC="false" toc="include" pn="section-7.9
">
<name slugifiedName="name-correlating-registrations">Correlating Registr
ations</name>
<t indent="0" pn="section-7.9-1">
The ROVR field in the EARO introduced in <xref target="RFC8505" format
="default" sectionFormat="of" derivedContent="RFC8505"/> extends the EUI-64 fiel
d of the ARO defined in <xref target="RFC6775" format="default" sectionFormat="o
f" derivedContent="RFC6775"/>. One of the drawbacks of using an EUI-64 as ROVR i
s that an attacker that is aware of the registrations can correlate traffic for
the same 6LN across multiple addresses. <xref target="RFC8505" sectionFormat="of
" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8505#s
ection-3" derivedContent="RFC8505"/> indicates that the ROVR and the address bei
ng registered are decoupled. A 6LN may use the same ROVR for multiple registrati
ons or a different ROVR per registration, and the IID must not be derived from t
he ROVR. In theory, different 6LNs could use the same ROVR as long as they do no
t attempt to register the same address.
</t>
<t indent="0" pn="section-7.9-2">
The modifier used in the computation of the Crypto-ID enables a 6LN to
build different Crypto-IDs for different addresses with the same key pair. Usin
g that facility improves the privacy of the 6LN at the expense of storage in the
6LR, which will need to store multiple CIPOs that contain the same public key.
Note that if an attacker gains access to the 6LR, then the modifier alone does n
ot provide protection, and the 6LN would need to generate different key pairs an
d link-layer addresses in an attempt to obfuscate its multiple ownership.
</t>
</section>
</section> </section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-8">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section><name>IANA considerations</name> <section anchor="cgam" numbered="true" removeInRFC="false" toc="include" p
n="section-8.1">
<section anchor='cgam'><name>CGA Message Type</name> <name slugifiedName="name-cga-message-type">CGA Message Type</name>
<t> <t indent="0" pn="section-8.1-1">
This document defines a new 128-bit value of a Message Type tag under th
e CGA Message Type <xref target='RFC3972'/> name space: 0x8701 55c8 0cca dd32 6a
b7 e415 f148 84d0.
</t>
</section>
<section anchor='cryptotypereg'><name>Crypto-Type Subregistry</name>
<t>
IANA is requested to create a new subregistry "Crypto-Type Subreg
istry" in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters".
The registry is indexed by
an integer in the interval 0..255 and contains an Elliptic Curve,
a Hash Function, a Signature Algorithm, Representation Conventions,
Public key size, and Signature size, as shown in
<xref target='cryptotypetable'/>, which together specify a signat
ure scheme (and which are fully specified in <xref target="reprconv"></xref>).
</t>
<t>The following Crypto-Type values are defined in this document:
</t>
<table anchor="cryptotypetable"><name>Crypto-Types</name>
<thead>
<tr>
<th>Crypto-Type value</th>
<th align='center'> 0 (ECDSA256) </th>
<th align='center'> 1 (Ed25519) </th>
<th align='center'> 2 (ECDSA25519) </th>
</tr>
</thead><tbody>
<tr><td>Elliptic curve</td> This document defines a new 128-bit CGA Extension Type Tag under the "CG
<td align='center'> NIST P-256 <xref target='FIPS186-4'/> A Extension Type Tags" subregistry of the
</td> Cryptographically Generated Addresses (CGA) Message Type Name Space created by <
<td align='center'> Curve25519 <xref target='RFC7748'/></ xref target="RFC3972" format="default" sectionFormat="of" derivedContent="RFC397
td> 2"/>. </t>
<td align='center'> Curve25519 <xref target='RFC7748'/></ <t indent="0" pn="section-8.1-2">
td> Tag: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0.
</t>
</section>
<section anchor="cryptotypereg" numbered="true" removeInRFC="false" toc="i
nclude" pn="section-8.2">
<name slugifiedName="name-crypto-type-subregistry">Crypto-Type Subregist
ry</name>
<t indent="0" pn="section-8.2-1">
IANA has created the "Crypto-Types" subregistry in the "Internet
Control Message Protocol version 6 (ICMPv6) Parameters" registry. The registry
is indexed by
an integer in the interval 0..255 and contains an elliptic curve,
a hash function, a signature algorithm, representation conventions,
public key size, and signature size, as shown in
<xref target="cryptotypetable" format="default" sectionFormat="of
" derivedContent="Table 1"/>, which together specify a signature scheme. Detaile
d explanations are provided in <xref target="reprconv" format="default" sectionF
ormat="of" derivedContent="Appendix B"/>.
</t>
<t indent="0" pn="section-8.2-2">The following Crypto-Type values are de
fined in this document:
</t>
<table anchor="cryptotypetable" align="center" pn="table-1">
<name slugifiedName="name-crypto-types">Crypto-Types</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Crypto-Type Value</th>
<th align="center" colspan="1" rowspan="1"> 0 (ECDSA256) </th>
<th align="center" colspan="1" rowspan="1"> 1 (Ed25519) </th>
<th align="center" colspan="1" rowspan="1"> 2 (ECDSA25519) </th>
</tr> </tr>
<tr><td>Hash function</td> </thead>
<td align='center'> SHA-256 <xref target='RFC6234'/></td> <tbody>
<td align='center'> SHA-512 <xref target='RFC6234 <tr>
'/></td> <td align="left" colspan="1" rowspan="1">Elliptic Curve</td>
<td align='center'> SHA-256 <xref target='RFC6234'/>< <td align="center" colspan="1" rowspan="1"> NIST P-256 <xref targe
/td> t="FIPS186-4" format="default" sectionFormat="of" derivedContent="FIPS186-4"/></
td>
<td align="center" colspan="1" rowspan="1"> Curve25519 <xref targe
t="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/></td>
<td align="center" colspan="1" rowspan="1"> Curve25519 <xref targe
t="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/></td>
</tr> </tr>
<tr><td>Signature algorithm</td> <tr>
<td align='center'> ECDSA <xref target='FIPS186-4 <td align="left" colspan="1" rowspan="1">Hash Function</td>
'/></td> <td align="center" colspan="1" rowspan="1"> SHA-256 <xref target="
<td align='center'> Ed25519 <xref target='RFC8032'/>< RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/></td>
/td> <td align="center" colspan="1" rowspan="1"> SHA-512 <xref target="
<td align='center'> ECDSA <xref target='FIPS186-4 RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/></td>
'/></td> <td align="center" colspan="1" rowspan="1"> SHA-256 <xref target="
RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/></td>
</tr> </tr>
<tr><td>Representation conventions</td> <tr>
<td align='center'> Weierstrass, (un)compressed, <td align="left" colspan="1" rowspan="1">Signature Algorithm</td>
MSB/msb first, <xref target='RFC7518'/> </td> <td align="center" colspan="1" rowspan="1"> ECDSA <xref target="FI
<td align='center'> Edwards, compressed, LSB/lsb firs PS186-4" format="default" sectionFormat="of" derivedContent="FIPS186-4"/></td>
t, <xref target='RFC8037'/></td> <td align="center" colspan="1" rowspan="1"> Ed25519 <xref target="
<td align='center'> Weierstrass, (un)compressed, MSB/ RFC8032" format="default" sectionFormat="of" derivedContent="RFC8032"/></td>
msb first, <xref target='I-D.ietf-lwig-curve-representations'/></td></tr> <td align="center" colspan="1" rowspan="1"> ECDSA <xref target="FI
<tr><td>Public key size</td> PS186-4" format="default" sectionFormat="of" derivedContent="FIPS186-4"/></td>
<td align='center'> 33/65 bytes (compressed/uncom </tr>
pressed)</td> <tr>
<td align='center'> 32 bytes (compressed)</td> <td align="left" colspan="1" rowspan="1">Representation Convention
<td align='center'> 33/65 bytes (compressed/uncompres s</td>
sed) </td></tr> <td align="center" colspan="1" rowspan="1"> Weierstrass, (un)compr
<tr><td>Signature size</td> essed, MSB/msb-order, <xref target="SEC1" format="default" sectionFormat="of" de
<td align='center'> 64 bytes </td> rivedContent="SEC1"/> </td>
<td align='center'> 64 bytes </td> <td align="center" colspan="1" rowspan="1"> Edwards, compressed, L
<td align='center'> 64 bytes </td></tr> SB/lsb-order, <xref target="RFC8032" format="default" sectionFormat="of" derived
<tr><td>Defining specification</td> Content="RFC8032"/></td>
<td align='center'>This_RFC</td> <td align="center" colspan="1" rowspan="1"> Weierstrass, (un)compr
<td align='center'>This_RFC</td> essed, MSB/msb-order, <xref target="I-D.ietf-lwig-curve-representations" format=
<td align='center'>This_RFC</td> "default" sectionFormat="of" derivedContent="CURVE-REPR"/></td>
</tr> </tr>
</tbody> <tr>
</table> <td align="left" colspan="1" rowspan="1">Public Key Size</td>
<t> <td align="center" colspan="1" rowspan="1"> 33/65 bytes (compresse
New Crypto-Type values providing similar or better security may be de d/uncompressed)</td>
fined in the future. <td align="center" colspan="1" rowspan="1"> 32 bytes (compressed)<
</t> /td>
<t> <td align="center" colspan="1" rowspan="1"> 33/65 bytes (compresse
Assignment of new values for new Crypto-Type MUST be done through IANA with d/uncompressed) </td>
either "Specification Required" or "IESG Approval" as defined in BCP 26 </tr>
<xref target='RFC8126'/>. <tr>
</t> <td align="left" colspan="1" rowspan="1">Signature Size</td>
<td align="center" colspan="1" rowspan="1"> 64 bytes </td>
</section> <td align="center" colspan="1" rowspan="1"> 64 bytes </td>
<td align="center" colspan="1" rowspan="1"> 64 bytes </td>
<section anchor='ndopt'><name>IPv6 ND option types </name> </tr>
<t> <tr>
<td align="left" colspan="1" rowspan="1">Reference</td>
<td align="center" colspan="1" rowspan="1">RFC 8928</td>
<td align="center" colspan="1" rowspan="1">RFC 8928</td>
<td align="center" colspan="1" rowspan="1">RFC 8928</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-8.2-4">
New Crypto-Type values providing similar or better security may be define
d in the future.
</t>
<t indent="0" pn="section-8.2-5">
Assignment of values for new Crypto-Type <bcp14>MUST</bcp14> be done through
IANA with either "Specification Required" or "IESG Approval" as defined in <xre
f target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126">
BCP 26</xref>.
</t>
</section>
<section anchor="ndopt" numbered="true" removeInRFC="false" toc="include"
pn="section-8.3">
<name slugifiedName="name-ipv6-nd-option-types">IPv6 ND Option Types</na
me>
<t indent="0" pn="section-8.3-1">
This document registers two new ND option types under the subregistry "I Pv6 Neighbor Discovery Option Formats": This document registers two new ND option types under the subregistry "I Pv6 Neighbor Discovery Option Formats":
</t> </t>
<table anchor="nexndopt" align="center" pn="table-2">
<table anchor="nexndopt"><name>New ND options</name> <name slugifiedName="name-new-nd-options">New ND Options</name>
<thead> <thead>
<tr>
<tr> <th align="left" colspan="1" rowspan="1">Description</th>
<th align='center'>Option Name</th> <th align="center" colspan="1" rowspan="1">Type</th>
<th align='center'>Suggested Value</th> <th align="left" colspan="1" rowspan="1">Reference</th>
<th align='left'>Reference</th> </tr>
</tr> </thead>
<tbody>
</thead><tbody> <tr>
<td align="left" colspan="1" rowspan="1">Crypto-ID Parameters Opti
<tr> on (CIPO)</td>
<td align='center'>NDP Signature Option (NDPSO)</td> <td align="center" colspan="1" rowspan="1">39</td>
<td align='center'>38</td> <td align="left" colspan="1" rowspan="1">RFC 8928</td>
<td align='left'>This document</td> </tr>
</tr> <tr>
<td align="left" colspan="1" rowspan="1">NDP Signature Option (NDP
<tr> SO)</td>
<td align='center'>Crypto-ID Parameters Option (CIPO)</td> <td align="center" colspan="1" rowspan="1">40</td>
<td align='center'>39</td> <td align="left" colspan="1" rowspan="1">RFC 8928</td>
<td align='left'>This document</td> </tr>
</tr> </tbody>
</tbody>
</table> </table>
</section>
</section> <section numbered="true" removeInRFC="false" toc="include" pn="section-8.4
">
<section title="New 6LoWPAN Capability Bit"> <name slugifiedName="name-new-6lowpan-capability-bit">New 6LoWPAN Capabi
<t> lity Bit</name>
IANA is requested to make additions to the Subregistry for <t indent="0" pn="section-8.4-1">
"6LoWPAN Capability Bits" created for <xref target='RFC7400'/> IANA has made an addition to the subregistry for
"6LoWPAN Capability Bits" created for <xref target="RFC7400" format="
default" sectionFormat="of" derivedContent="RFC7400"/>
as follows: as follows:
</t> </t>
<table anchor="CIOdat" align="center" pn="table-3">
<table anchor="CIOdat"><name>New 6LoWPAN Capability Bit</name> <name slugifiedName="name-new-6lowpan-capability-bit-2">New 6LoWPAN Ca
<thead> pability Bit</name>
<tr> <thead>
<th align='center'>Capability Bit</th> <tr>
<th align='left'>Description </th> <th align="center" colspan="1" rowspan="1">Bit</th>
<th align='left'>Document</th> <th align="left" colspan="1" rowspan="1">Description </th>
</tr> <th align="left" colspan="1" rowspan="1">Reference</th>
</thead><tbody>
<tr>
<td align='center'>09</td>
<td align='left'>AP-ND Enabled (1 bit)</td>
<td align='left'>This_RFC</td>
</tr> </tr>
</thead>
</tbody> <tbody>
</table> <tr>
<td align="center" colspan="1" rowspan="1">9</td>
</section> <!-- end section "New 6LoWPAN Capability Bits" --> <td align="left" colspan="1" rowspan="1">AP-ND Enabled (1 bit)</td
>
</section> <td align="left" colspan="1" rowspan="1">RFC 8928</td>
</tr>
<section><name>Acknowledgments</name> </tbody>
<t> </table>
Many thanks to Charlie Perkins for his in-depth review and constructive </section>
suggestions. The authors are also especially grateful to Robert Moskowitz </section>
and Benjamin Kaduk for their comments and discussions that led to many impr </middle>
ovements. <back>
The authors wish to also thank Shwetha Bhandari for actively shepherding th <displayreference target="I-D.ietf-lwig-curve-representations" to="CURVE-REP
is document and Roman Danyliw, Alissa Cooper, Mirja Kuhlewind, Eric Vyncke, Vija R"/>
y Gurbani, Al Morton, and Adam Montville for their constructive reviews during t <displayreference target="RFC7696" to="BCP201"/>
he IESG process. <displayreference target="RFC4086" to="BCP106"/>
Finally Many thanks to our INT area ADs, Suresh Krishnan and then Erik Klin <references pn="section-9">
e, who <name slugifiedName="name-references">References</name>
supported us along the whole process. <references pn="section-9.1">
</t> <name slugifiedName="name-normative-references">Normative References</na
</section> me>
<reference anchor="FIPS186-4" target="https://nvlpubs.nist.gov/nistpubs/
</middle> fips/nist.fips.186-4.pdf" quoteTitle="true" derivedAnchor="FIPS186-4">
<front>
<back> <title>Digital Signature Standard (DSS)</title>
<author>
<displayreference target="I-D.ietf-6lo-backbone-router" to="BACK <organization showOnFrontPage="true">National Institute of Standar
BONE-ROUTER"/> ds and Technology</organization>
<displayreference target="I-D.ietf-lwig-curve-representations" to="CURV </author>
E-REPR"/> <date month="July" year="2013"/>
<displayreference target="RFC7696" to="BCP 201"/> </front>
<displayreference target="RFC4086" to="BCP 106"/> <seriesInfo name="FIPS" value="186-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
<references><name>Normative References</name> </reference>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
nce.RFC.2119.xml'/> 119" quoteTitle="true" derivedAnchor="RFC2119">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <front>
nce.RFC.3971.xml'/> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere le>
nce.RFC.6234.xml'/> <author initials="S." surname="Bradner" fullname="S. Bradner">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <organization showOnFrontPage="true"/>
nce.RFC.6775.xml'/> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <date year="1997" month="March"/>
nce.RFC.7400.xml'/> <abstract>
<!--xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref <t indent="0">In many standards track documents several words are
erence.RFC.7515.xml'/> used to signify the requirements in the specification. These words are often ca
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere pitalized. This document defines these words as they should be interpreted in IE
nce.RFC.7517.xml'/--> TF documents. This document specifies an Internet Best Current Practices for th
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere e Internet Community, and requests discussion and suggestions for improvements.<
nce.RFC.7748.xml'/> /t>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere </abstract>
nce.RFC.8032.xml'/> </front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <seriesInfo name="BCP" value="14"/>
nce.RFC.8174.xml'/> <seriesInfo name="RFC" value="2119"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <seriesInfo name="DOI" value="10.17487/RFC2119"/>
nce.RFC.8505.xml'/> </reference>
<reference anchor="RFC3971" target="https://www.rfc-editor.org/info/rfc3
<reference anchor='FIPS186-4'> 971" quoteTitle="true" derivedAnchor="RFC3971">
<front> <front>
<title> Digital Signature Standard (DSS), Federal Information <title>SEcure Neighbor Discovery (SEND)</title>
Processing Standards Publication 186-4 </title> <author initials="J." surname="Arkko" fullname="J. Arkko" role="edit
<author> or">
<organization> <organization showOnFrontPage="true"/>
FIPS 186-4 </author>
</organization> <author initials="J." surname="Kempf" fullname="J. Kempf">
</author> <organization showOnFrontPage="true"/>
<date month='July' year='2013'/> </author>
</front> <author initials="B." surname="Zill" fullname="B. Zill">
<seriesInfo name='US Department of Commerce/National Institute of Standa <organization showOnFrontPage="true"/>
rds and Technology' value=''/> </author>
</reference> <author initials="P." surname="Nikander" fullname="P. Nikander">
<organization showOnFrontPage="true"/>
<reference anchor='SEC1'> </author>
<front> <date year="2005" month="March"/>
<title>SEC 1: Elliptic Curve Cryptography, Version 2.0 </title> <abstract>
<author> <t indent="0">IPv6 nodes use the Neighbor Discovery Protocol (NDP)
<organization> to discover other nodes on the link, to determine their link-layer addresses to
SEC1 find routers, and to maintain reachability information about the paths to activ
</organization> e neighbors. If not secured, NDP is vulnerable to various attacks. This docume
</author> nt specifies security mechanisms for NDP. Unlike those in the original NDP spec
<date month='June' year='2009'/> ifications, these mechanisms do not use IPsec. [STANDARDS-TRACK]</t>
</front> </abstract>
<seriesInfo name='Standards for Efficient Cryptography' value=''/> </front>
</reference> <seriesInfo name="RFC" value="3971"/>
<seriesInfo name="DOI" value="10.17487/RFC3971"/>
</references> </reference>
<reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc6
<references><name>Informative references</name> 234" quoteTitle="true" derivedAnchor="RFC6234">
<front>
<!--reference anchor="IANA.JOSE.Algorithms"> <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</
<front> title>
<title> JSON Web Signature and Encryption Algorithms </ti <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
tle> rd">
<author> <organization showOnFrontPage="true"/>
<organization> </author>
IANA <author initials="T." surname="Hansen" fullname="T. Hansen">
</organization> <organization showOnFrontPage="true"/>
</author> </author>
<date year=""></date> <date year="2011" month="May"/>
</front> <abstract>
<seriesInfo name="IANA," value="https://www.iana.org/assignments/ <t indent="0">Federal Information Processing Standard, FIPS</t>
jose/jose.xhtml#web-signature-encryption-algorithms"></seriesInfo> </abstract>
</reference> </front>
<reference anchor="IANA.JOSE.Curves"> <seriesInfo name="RFC" value="6234"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC6234"/>
<title> JSON Web Key Elliptic Curve </title> </reference>
<author> <reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc6
<organization> 775" quoteTitle="true" derivedAnchor="RFC6775">
IANA <front>
</organization> <title>Neighbor Discovery Optimization for IPv6 over Low-Power Wirel
</author> ess Personal Area Networks (6LoWPANs)</title>
<date year=""></date> <author initials="Z." surname="Shelby" fullname="Z. Shelby" role="ed
</front> itor">
<seriesInfo name="IANA," value="https://www.iana.org/assignments/ <organization showOnFrontPage="true"/>
jose/jose.xhtml#web-key-elliptic-curve"></seriesInfo> </author>
</reference--> <author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti
">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <organization showOnFrontPage="true"/>
nce.RFC.3972.xml'/> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <author initials="E." surname="Nordmark" fullname="E. Nordmark">
nce.RFC.4086.xml'/> <organization showOnFrontPage="true"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere </author>
nce.RFC.4861.xml'/> <author initials="C." surname="Bormann" fullname="C. Bormann">
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <organization showOnFrontPage="true"/>
nce.RFC.4862.xml'/> </author>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <date year="2012" month="November"/>
nce.RFC.4919.xml'/> <abstract>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <t indent="0">The IETF work in IPv6 over Low-power Wireless Person
nce.RFC.4944.xml'/> al Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and othe
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere r similar link technologies have limited or no usage of multicast signaling due
nce.RFC.6282.xml'/> to energy conservation. In addition, the wireless network may not strictly foll
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere ow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery
nce.RFC.7039.xml'/> was not designed for non- transitive wireless links, as its reliance on the trad
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere itional IPv6 link concept and its heavy use of multicast make it inefficient and
nce.RFC.7217.xml'/> sometimes impractical in a low-power and lossy network. This document describe
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere s simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, an
nce.RFC.7518.xml'/> d duplicate address detection for Low- power Wireless Personal Area Networks and
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere similar networks. The document thus updates RFC 4944 to specify the use of the
nce.RFC.7696.xml'/> optimizations defined here. [STANDARDS-TRACK]</t>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere </abstract>
nce.RFC.8037.xml'/> </front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <seriesInfo name="RFC" value="6775"/>
nce.RFC.8064.xml'/> <seriesInfo name="DOI" value="10.17487/RFC6775"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere </reference>
nce.RFC.8065.xml'/> <reference anchor="RFC7400" target="https://www.rfc-editor.org/info/rfc7
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere 400" quoteTitle="true" derivedAnchor="RFC7400">
nce.RFC.8126.xml'/> <front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refer <title>6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Pow
ence.I-D.ietf-6lo-backbone-router.xml'/> er Wireless Personal Area Networks (6LoWPANs)</title>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refer <author initials="C." surname="Bormann" fullname="C. Bormann">
ence.I-D.ietf-lwig-curve-representations.xml'/> <organization showOnFrontPage="true"/>
</author>
<reference anchor='breaking-ed25519' target='https://link.springer.com/ch <date year="2014" month="November"/>
apter/10.1007/978-3-319-76953-0_1'> <abstract>
<front> <t indent="0">RFC 6282 defines header compression in 6LoWPAN packe
ts (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Networ
k"). The present document specifies a simple addition that enables the compress
ion of generic headers and header-like payloads, without a need to define a new
header compression scheme for each such new header or header-like payload.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7400"/>
<seriesInfo name="DOI" value="10.17487/RFC7400"/>
</reference>
<reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7
748" quoteTitle="true" derivedAnchor="RFC7748">
<front>
<title>Elliptic Curves for Security</title>
<author initials="A." surname="Langley" fullname="A. Langley">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Hamburg" fullname="M. Hamburg">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Turner" fullname="S. Turner">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="January"/>
<abstract>
<t indent="0">This memo specifies two elliptic curves over prime f
ields that offer a high level of practical security in cryptographic application
s, including Transport Layer Security (TLS). These curves are intended to opera
te at the ~128-bit and ~224-bit security level, respectively, and are generated
deterministically based on a list of required properties.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7748"/>
<seriesInfo name="DOI" value="10.17487/RFC7748"/>
</reference>
<reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8
032" quoteTitle="true" derivedAnchor="RFC8032">
<front>
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
<author initials="S." surname="Josefsson" fullname="S. Josefsson">
<organization showOnFrontPage="true"/>
</author>
<author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="January"/>
<abstract>
<t indent="0">This document describes elliptic curve signature sch
eme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instant
iated with recommended parameters for the edwards25519 and edwards448 curves. A
n example implementation and test vectors are provided.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8032"/>
<seriesInfo name="DOI" value="10.17487/RFC8032"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8505" target="https://www.rfc-editor.org/info/rfc8
505" quoteTitle="true" derivedAnchor="RFC8505">
<front>
<title>Registration Extensions for IPv6 over Low-Power Wireless Pers
onal Area Network (6LoWPAN) Neighbor Discovery</title>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti
">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="November"/>
<abstract>
<t indent="0">This specification updates RFC 6775 -- the Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to
clarify the role of the protocol as a registration technique and simplify the r
egistration operation in 6LoWPAN routers, as well as to provide enhancements to
the registration capabilities and mobility detection for different network topol
ogies, including the Routing Registrars performing routing for host routes and/o
r proxy Neighbor Discovery in a low-power network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8505"/>
<seriesInfo name="DOI" value="10.17487/RFC8505"/>
</reference>
<reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf" quote
Title="true" derivedAnchor="SEC1">
<front>
<title>SEC 1: Elliptic Curve Cryptography</title>
<author>
<organization showOnFrontPage="true">Standards for Efficient Crypt
ography</organization>
</author>
<date month="May" year="2009"/>
</front>
<refcontent>Version 2</refcontent>
</reference>
</references>
<references pn="section-9.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4
086" quoteTitle="true" derivedAnchor="BCP106">
<front>
<title>Randomness Requirements for Security</title>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
rd">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Schiller" fullname="J. Schiller">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Crocker" fullname="S. Crocker">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="June"/>
<abstract>
<t indent="0">Security systems are built on strong cryptographic a
lgorithms that foil pattern analysis attempts. However, the security of these s
ystems is dependent on generating secret quantities for passwords, cryptographic
keys, and similar quantities. The use of pseudo-random processes to generate s
ecret quantities can result in pseudo-security. A sophisticated attacker may fin
d it easier to reproduce the environment that produced the secret quantities and
to search the resulting small set of possibilities than to locate the quantitie
s in the whole of the potential number space.</t>
<t indent="0">Choosing random quantities to foil a resourceful and
motivated adversary is surprisingly difficult. This document points out many p
itfalls in using poor entropy sources or traditional pseudo-random number genera
tion techniques for generating such quantities. It recommends the use of truly
random hardware techniques and shows that the existing hardware on many systems
can be used for this purpose. It provides suggestions to ameliorate the problem
when a hardware solution is not available, and it gives examples of how large su
ch quantities need to be for some applications. This document specifies an Inte
rnet Best Current Practices for the Internet Community, and requests discussion
and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC7696" target="https://www.rfc-editor.org/info/rfc7
696" quoteTitle="true" derivedAnchor="BCP201">
<front>
<title>Guidelines for Cryptographic Algorithm Agility and Selecting
Mandatory-to-Implement Algorithms</title>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="November"/>
<abstract>
<t indent="0">Many IETF protocols use cryptographic algorithms to
provide confidentiality, integrity, authentication, or digital signature. Commu
nicating peers must support a common set of cryptographic algorithms for these m
echanisms to work properly. This memo provides guidelines to ensure that protoc
ols have the ability to migrate from one mandatory-to-implement algorithm suite
to another over time.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="201"/>
<seriesInfo name="RFC" value="7696"/>
<seriesInfo name="DOI" value="10.17487/RFC7696"/>
</reference>
<reference anchor="breaking-ed25519" target="https://link.springer.com/c
hapter/10.1007/978-3-319-76953-0_1" quoteTitle="true" derivedAnchor="breaking-ed
25519">
<front>
<title>Breaking Ed25519 in WolfSSL</title> <title>Breaking Ed25519 in WolfSSL</title>
<author initials='N.' surname='Samwel' fullname='Niels Samwel'> <author initials="N." surname="Samwel" fullname="Niels Samwel">
</author> </author>
<author initials='L.' surname='Batina' fullname='Leija Batina'> <author initials="L." surname="Batina" fullname="Leija Batina">
</author> </author>
<author initials='G.' surname='Bertoni' fullname='Guido Bertoni'> <author initials="G." surname="Bertoni" fullname="Guido Bertoni">
</author> </author>
<author initials='J.' surname='Daemen' fullname='Joan Daemen'> <author initials="J." surname="Daemen" fullname="Joan Daemen">
</author> </author>
<author initials='R.' surname='Susella' fullname='Ruggero Susella'> <author initials="R." surname="Susella" fullname="Ruggero Susella">
</author> </author>
<date year='2018'/> <date month="March" year="2018"/>
</front> </front>
<seriesInfo name='Cryptographers’ Track at the RSA Conference' value=''/ <refcontent>Topics in Cryptology - CT-RSA, pp. 1-20</refcontent>
> </reference>
</reference> <reference anchor="I-D.ietf-lwig-curve-representations" quoteTitle="true
</references> " target="https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-14"
derivedAnchor="CURVE-REPR">
<front>
<title>Alternative Elliptic Curve Representations</title>
<author fullname="Rene Struik">
<organization showOnFrontPage="true">Struik Security Consultancy</
organization>
</author>
<date month="November" day="15" year="2020"/>
<abstract>
<t indent="0"> This document specifies how to represent Montgome
ry curves and
(twisted) Edwards curves as curves in short-Weierstrass form and
illustrates how this can be used to carry out elliptic curve
computations using existing implementations of, e.g., ECDSA and ECDH
using NIST prime curves. We also provide extensive background
material that may be useful for implementers of elliptic curve
cryptography.
<section anchor='ps'><name>Requirements Addressed in this Document</name> </t>
<t> </abstract>
In this section we state requirements of a secure neighbor discovery </front>
protocol for low-power and lossy networks. <seriesInfo name="Internet-Draft" value="draft-ietf-lwig-curve-represe
</t><ul spacing='compact'> ntations-14"/>
<li> <format type="TXT" target="https://www.ietf.org/internet-drafts/draft-
The protocol MUST be based on the Neighbor Discovery Optimization f ietf-lwig-curve-representations-14.txt"/>
or Low-power and Lossy Networks protocol defined in <xref target='RFC6775'/>. RF <refcontent>Work in Progress</refcontent>
C6775 utilizes optimizations such as host-initiated interactions for sleeping re </reference>
source-constrained hosts and elimination of multicast address resolution. <reference anchor="RFC3972" target="https://www.rfc-editor.org/info/rfc3
972" quoteTitle="true" derivedAnchor="RFC3972">
<front>
<title>Cryptographically Generated Addresses (CGA)</title>
<author initials="T." surname="Aura" fullname="T. Aura">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="March"/>
<abstract>
<t indent="0">This document describes a method for binding a publi
c signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) proto
col. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which t
he interface identifier is generated by computing a cryptographic one-way hash f
unction from a public key and auxiliary parameters. The binding between the pub
lic key and the address can be verified by re-computing the hash value and by co
mparing the hash with the interface identifier. Messages sent from an IPv6 addr
ess can be protected by attaching the public key and auxiliary parameters and by
signing the message with the corresponding private key. The protection works w
ithout a certification authority or any security infrastructure. [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3972"/>
<seriesInfo name="DOI" value="10.17487/RFC3972"/>
</reference>
<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4
861" quoteTitle="true" derivedAnchor="RFC4861">
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Simpson" fullname="W. Simpson">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Soliman" fullname="H. Soliman">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="September"/>
<abstract>
<t indent="0">This document specifies the Neighbor Discovery proto
col for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to dis
cover each other's presence, to determine each other's link-layer addresses, to
find routers, and to maintain reachability information about the paths to active
neighbors. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4861"/>
<seriesInfo name="DOI" value="10.17487/RFC4861"/>
</reference>
<reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4
862" quoteTitle="true" derivedAnchor="RFC4862">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author initials="S." surname="Thomson" fullname="S. Thomson">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Jinmei" fullname="T. Jinmei">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="September"/>
<abstract>
<t indent="0">This document specifies the steps a host takes in de
ciding how to autoconfigure its interfaces in IP version 6. The autoconfigurati
on process includes generating a link-local address, generating global addresses
via stateless address autoconfiguration, and the Duplicate Address Detection pr
ocedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference>
<reference anchor="RFC4919" target="https://www.rfc-editor.org/info/rfc4
919" quoteTitle="true" derivedAnchor="RFC4919">
<front>
<title>IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs
): Overview, Assumptions, Problem Statement, and Goals</title>
<author initials="N." surname="Kushalnagar" fullname="N. Kushalnagar
">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Montenegro" fullname="G. Montenegro">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Schumacher" fullname="C. Schumacher">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="August"/>
<abstract>
<t indent="0">This document describes the assumptions, problem sta
tement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of g
oals enumerated in this document form an initial set only. This memo provides i
nformation for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4919"/>
<seriesInfo name="DOI" value="10.17487/RFC4919"/>
</reference>
<reference anchor="RFC4944" target="https://www.rfc-editor.org/info/rfc4
944" quoteTitle="true" derivedAnchor="RFC4944">
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</tit
le>
<author initials="G." surname="Montenegro" fullname="G. Montenegro">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Kushalnagar" fullname="N. Kushalnagar
">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Culler" fullname="D. Culler">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="September"/>
<abstract>
<t indent="0">This document describes the frame format for transmi
ssion of IPv6 packets and the method of forming IPv6 link-local addresses and st
atelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifi
cations include a simple header compression scheme using shared context and prov
isions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4944"/>
<seriesInfo name="DOI" value="10.17487/RFC4944"/>
</reference>
<reference anchor="RFC6282" target="https://www.rfc-editor.org/info/rfc6
282" quoteTitle="true" derivedAnchor="RFC6282">
<front>
<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Base
d Networks</title>
<author initials="J." surname="Hui" fullname="J. Hui" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="September"/>
<abstract>
<t indent="0">This document updates RFC 4944, "Transmission of IPv
6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header
compression format for IPv6 packet delivery in Low Power Wireless Personal Area
Networks (6LoWPANs). The compression format relies on shared context to allow c
ompression of arbitrary prefixes. How the information is maintained in that sha
red context is out of scope. This document specifies compression of multicast ad
dresses and a framework for compressing next headers. UDP header compression is
specified within this framework. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6282"/>
<seriesInfo name="DOI" value="10.17487/RFC6282"/>
</reference>
<reference anchor="RFC7039" target="https://www.rfc-editor.org/info/rfc7
039" quoteTitle="true" derivedAnchor="RFC7039">
<front>
<title>Source Address Validation Improvement (SAVI) Framework</title
>
<author initials="J." surname="Wu" fullname="J. Wu">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Bi" fullname="J. Bi">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Bagnulo" fullname="M. Bagnulo">
<organization showOnFrontPage="true"/>
</author>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Vogt" fullname="C. Vogt" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="October"/>
<abstract>
<t indent="0">Source Address Validation Improvement (SAVI) methods
were developed to prevent nodes attached to the same IP link from spoofing each
other's IP addresses, so as to complement ingress filtering with finer-grained,
standardized IP source address validation. This document is a framework docume
nt that describes and motivates the design of the SAVI methods. Particular SAVI
methods are described in other documents.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7039"/>
<seriesInfo name="DOI" value="10.17487/RFC7039"/>
</reference>
<reference anchor="RFC7217" target="https://www.rfc-editor.org/info/rfc7
217" quoteTitle="true" derivedAnchor="RFC7217">
<front>
<title>A Method for Generating Semantically Opaque Interface Identif
iers with IPv6 Stateless Address Autoconfiguration (SLAAC)</title>
<author initials="F." surname="Gont" fullname="F. Gont">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="April"/>
<abstract>
<t indent="0">This document specifies a method for generating IPv6
Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration
(SLAAC), such that an IPv6 address configured using this method is stable within
each subnet, but the corresponding Interface Identifier changes when the host m
oves from one network to another. This method is meant to be an alternative to
generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Med
ia Access Control (MAC) addresses), such that the benefits of stable addresses c
an be achieved without sacrificing the security and privacy of users. The metho
d specified in this document applies to all prefixes a host may be employing, in
cluding link-local, global, and unique-local prefixes (and their corresponding a
ddresses).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7217"/>
<seriesInfo name="DOI" value="10.17487/RFC7217"/>
</reference>
<reference anchor="RFC8064" target="https://www.rfc-editor.org/info/rfc8
064" quoteTitle="true" derivedAnchor="RFC8064">
<front>
<title>Recommendation on Stable IPv6 Interface Identifiers</title>
<author initials="F." surname="Gont" fullname="F. Gont">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Cooper" fullname="A. Cooper">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Thaler" fullname="D. Thaler">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Liu" fullname="W. Liu">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="February"/>
<abstract>
<t indent="0">This document changes the recommended default Interf
ace Identifier (IID) generation scheme for cases where Stateless Address Autocon
figuration (SLAAC) is used to generate a stable IPv6 address. It recommends usin
g the mechanism specified in RFC 7217 in such cases, and recommends against embe
dding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, R
FC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, R
FC 4291, RFC 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not cha
nge any existing recommendations concerning the use of temporary addresses as sp
ecified in RFC 4941.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8064"/>
<seriesInfo name="DOI" value="10.17487/RFC8064"/>
</reference>
<reference anchor="RFC8065" target="https://www.rfc-editor.org/info/rfc8
065" quoteTitle="true" derivedAnchor="RFC8065">
<front>
<title>Privacy Considerations for IPv6 Adaptation-Layer Mechanisms</
title>
<author initials="D." surname="Thaler" fullname="D. Thaler">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="February"/>
<abstract>
<t indent="0">This document discusses how a number of privacy thre
ats apply to technologies designed for IPv6 over various link-layer protocols, a
nd it provides advice to protocol designers on how to address such threats in ad
aptation-layer specifications for IPv6 over such links.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8065"/>
<seriesInfo name="DOI" value="10.17487/RFC8065"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="June"/>
<abstract>
<t indent="0">Many protocols make use of points of extensibility t
hat use constants to identify various protocol parameters. To ensure that the v
alues in these fields do not have conflicting uses and to promote interoperabili
ty, their allocations are often coordinated by a central record keeper. For IET
F protocols, that role is filled by the Internet Assigned Numbers Authority (IAN
A).</t>
<t indent="0">To make assignments in a given registry prudently, g
uidance describing the conditions under which new values should be assigned, as
well as when and how modifications to existing values can be made, is needed. T
his document defines a framework for the documentation of these guidelines by sp
ecification authors, in order to assure that the provided guidance for the IANA
Considerations is clear and addresses the various issues that are likely in the
operation of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8929" target="https://www.rfc-editor.org/info/rfc8
929" quoteTitle="true" derivedAnchor="RFC8929">
<front>
<title>IPv6 Backbone Router</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" rol
e="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C.E." surname="Perkins" fullname="Charles Perkins"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abe
gnoli">
<organization showOnFrontPage="true"/>
</author>
<date month="November" year="2020"/>
</front>
<seriesInfo name="RFC" value="8929"/>
<seriesInfo name="DOI" value="10.17487/RFC8929"/>
</reference>
</references>
</references>
<section anchor="ps" numbered="true" removeInRFC="false" toc="include" pn="s
ection-appendix.a">
<name slugifiedName="name-requirements-addressed-in-t">Requirements Addres
sed in This Document</name>
<t indent="0" pn="section-appendix.a-1">
In this section, the requirements of a secure Neighbor Discovery pro
tocol for LLNs are stated.
</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
endix.a-2">
<li pn="section-appendix.a-2.1">
The protocol <bcp14>MUST</bcp14> be based on the Neighbor Discovery
Optimization for the LLN protocol defined in <xref target="RFC6775" format="def
ault" sectionFormat="of" derivedContent="RFC6775"/>. RFC 6775 utilizes optimizat
ions such as host-initiated interactions for sleeping resource-constrained hosts
and the elimination of multicast address resolution.
</li> </li>
<li> <li pn="section-appendix.a-2.2">
New options to be added to Neighbor Solicitation messages MUST lea New options to be added to Neighbor Solicitation messages <bcp14>M
d to small packet sizes, especially compared with existing protocols such as SEc UST</bcp14> lead to small packet sizes, especially compared with existing protoc
ure Neighbor Discovery (SEND). Smaller packet sizes facilitate low-power transmi ols such as SEND. Smaller packet sizes facilitate low-power transmission by reso
ssion by resource-constrained nodes on lossy links. urce-constrained nodes on lossy links.
</li> </li>
<li> <li pn="section-appendix.a-2.3">
The support for this registration mechanism SHOULD be extensible t The registration mechanism <bcp14>SHOULD</bcp14> be extensible to
o more LLN links than IEEE 802.15.4 only. Support for at least the LLN links for other LLN links and not be limited to IEEE 802.15.4 only. LLN links for which a
which a 6lo "IPv6 over foo" specification exists, as well as Low-Power Wi-Fi SH 6lo "IPv6 over foo" specification exist, as well as low-power Wi-Fi, <bcp14>SHOU
OULD be possible. LD</bcp14> be supported.
</li> </li>
<li> <li pn="section-appendix.a-2.4">
As part of this extension, a mechanism to compute a unique Identif As part of this protocol, a mechanism to compute a unique identifi
ier should be provided with the capability to form a Link Local Address that SHO er should be provided with the capability to form a Link Local Address that <bcp
ULD be unique at least within the LLN connected to a 6LBR. 14>SHOULD</bcp14> be unique at least within the LLN connected to a 6LBR.
</li> </li>
<li> <li pn="section-appendix.a-2.5">
The Address Registration Option used in the ND registration SHOULD The Address Registration Option used in the ND registration <bcp14
be extended to carry the relevant forms of >SHOULD</bcp14> be extended to carry the relevant forms of the
Unique Interface Identifier. unique identifier.
</li> </li>
<li> <li pn="section-appendix.a-2.6">
The Neighbor Discovery should specify the formation of a site-loca The Neighbor Discovery should specify the formation of a site-loca
l address that follows the security recommendations from <xref target='RFC7217'/ l address that follows the security recommendations from <xref target="RFC7217"
>. format="default" sectionFormat="of" derivedContent="RFC7217"/>.
</li> </li>
</ul><t> </ul>
</t> </section>
</section> <section anchor="reprconv" numbered="true" removeInRFC="false" toc="include"
pn="section-appendix.b">
<section anchor='reprconv'><name>Representation Conventions</name> <name slugifiedName="name-representation-conventions">Representation Conve
ntions</name>
<section><name>Signature Schemes</name> <section numbered="true" removeInRFC="false" toc="include" pn="section-b.1
<t> The signature scheme ECDSA256 corresponding to Crypto-Type 0 is ECDSA ">
, as specified in <xref target='FIPS186-4'/>, instantiated with the NIST prime c <name slugifiedName="name-signature-schemes">Signature Schemes</name>
urve P-256, <t indent="0" pn="section-b.1-1"> The signature scheme ECDSA256 correspo
as specified in Appendix B of <xref target='FIPS186-4'/>, and the hash fu nding to Crypto-Type 0 is ECDSA, as specified in <xref target="FIPS186-4" format
nction SHA-256, as specified in <xref target='RFC6234'/>, where points of this N ="default" sectionFormat="of" derivedContent="FIPS186-4"/>, instantiated with th
IST curve are e NIST prime curve P-256,
represented as points of a short-Weierstrass curve (see <xref target='FIP as specified in Appendix D.1.2 of <xref target="FIPS186-4" format="defaul
S186-4'/>) and are encoded as octet strings in most-significant-bit first (msb) t" sectionFormat="of" derivedContent="FIPS186-4"/>, and the hash function SHA-25
and 6, as specified in <xref target="RFC6234" format="default" sectionFormat="of" de
most-significant-byte first (MSB) order. The signature itself consists of rivedContent="RFC6234"/>, where points of this NIST curve are
two integers (r and s), which are each encoded as fixed-size octet strings in m represented as points of a short-Weierstrass curve (see <xref target="FIP
ost-significant-bit S186-4" format="default" sectionFormat="of" derivedContent="FIPS186-4"/>) and ar
first and most-significant-byte first order. For details on ECDSA, see <x e encoded as octet strings in most-significant-bit first (msb) and
ref target='FIPS186-4'/>; for details on the encoding of public keys, see <xref most-significant-byte first (MSB) order. The signature itself consists of
target="weirepr"></xref>; two integers (r and s), which are each encoded as fixed-size octet strings in M
for details on the signature encoding, see <xref target='bitrepr'/>.</t> SB and msb order. For further details, see <xref target="FIPS186-4" format="defa
ult" sectionFormat="of" derivedContent="FIPS186-4"/> for ECDSA, see <xref target
<t> The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA, ="weirepr" format="default" sectionFormat="of" derivedContent="Appendix B.3"/> f
as specified in <xref target='RFC8032'/>, instantiated with the Montgomery curv or the encoding of public keys, and see
e Curve25519, as <xref target="bitrepr" format="default" sectionFormat="of" derivedConten
specified in <xref target='RFC7748'/>, and the hash function SHA-512, as t="Appendix B.2"/> for signature encoding.</t>
specified in <xref target='RFC6234'/>, where points of this Montgomery curve are <t indent="0" pn="section-b.1-2"> The signature scheme Ed25519 correspon
represented as points of the corresponding twisted Edwards curve Edwards2 ding to Crypto-Type 1 is EdDSA, as specified in <xref target="RFC8032" format="d
5519 (see <xref target='curves'/>) and are encoded as octet strings in least-sig efault" sectionFormat="of" derivedContent="RFC8032"/>, instantiated with the Mon
nificant-bit first (lsb) tgomery curve Curve25519, as
specified in <xref target="RFC7748" format="default" sectionFormat="of" d
erivedContent="RFC7748"/>, and the hash function SHA-512, as specified in <xref
target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/>,
where points of this Montgomery curve are
represented as points of the corresponding twisted Edwards
curve Edwards25519 (see <xref target="curves" format="default" sectionFor
mat="of" derivedContent="Appendix B.4"/>) and are
encoded as octet strings in least-significant-bit first (lsb)
and least-significant-byte first (LSB) order. The signature itself consis ts of a bit string that encodes a point of this twisted Edwards curve, in compre ssed format, and an and least-significant-byte first (LSB) order. The signature itself consis ts of a bit string that encodes a point of this twisted Edwards curve, in compre ssed format, and an
integer encoded in least-significant-bit first and least-significant-byte integer encoded in LSB and lsb order. For details on EdDSA and the encodi
first order. For details on EdDSA, the encoding of public keys and that of sign ng of public keys and signatures, see the
atures, see the specification of pure Ed25519 in <xref target="RFC8032" format="default"
specification of pure Ed25519 in <xref target='RFC8032'></xref>.</t> sectionFormat="of" derivedContent="RFC8032"/>.</t>
<t indent="0" pn="section-b.1-3"> The signature scheme ECDSA25519 corres
<t> The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is ECD ponding to Crypto-Type 2 is ECDSA, as specified in <xref target="FIPS186-4" form
SA, as specified in <xref target='FIPS186-4'/>, instantiated with the Montgomery at="default" sectionFormat="of" derivedContent="FIPS186-4"/>, instantiated with
curve the Montgomery curve
Curve25519, as specified in <xref target='RFC7748'/>, and the hash functi Curve25519, as specified in <xref target="RFC7748" format="default" secti
on SHA-256, as specified in <xref target='RFC6234'/>, where points of this Montg onFormat="of" derivedContent="RFC7748"/>, and the hash function SHA-256, as spec
omery ified in <xref target="RFC6234" format="default" sectionFormat="of" derivedConte
curve are represented as points of the corresponding short-Weierstrass cu nt="RFC6234"/>, where points of this Montgomery
rve Wei25519 (see <xref target='curves'/>) and are encoded as octet strings in curve are represented as points of the corresponding short-Weierstrass cu
most-significant-bit first and most-significant-byte first order. The sig rve Wei25519 (see <xref target="curves" format="default" sectionFormat="of" deri
nature itself consists of a bit string that encodes two integers, each encoded a vedContent="Appendix B.4"/>) and are encoded as octet strings in
s fixed-size MSB and msb order. The signature itself consists of a bit string that enc
octet strings in most-significant-bit first and most-significant-byte fir odes two integers (r and s), which are each encoded as fixed-size
st order. For details on ECDSA, see <xref target='FIPS186-4'/>; for details on t octet strings in MSB and msb order. For further details, see <xref target
he encoding of ="FIPS186-4" format="default" sectionFormat="of" derivedContent="FIPS186-4"/> fo
public keys, see <xref target="weirepr"></xref>; for details on the signa r ECDSA, see <xref target="weirepr" format="default" sectionFormat="of" derivedC
ture encoding, see <xref target='bitrepr'/></t> ontent="Appendix B.3"/> for the encoding of
</section> public keys, and see <xref target="bitrepr" format="default" sectionForma
t="of" derivedContent="Appendix B.2"/> for signature encoding.</t>
<section anchor='bitrepr'><name>Representation of ECDSA Signatures</name> </section>
<t> With ECDSA, each signature is an ordered pair (r, s) of integers <xre <section anchor="bitrepr" numbered="true" removeInRFC="false" toc="include
f target='FIPS186-4'/>, where each integer is represented as a 32-octet string a " pn="section-b.2">
ccording to the <name slugifiedName="name-representation-of-ecdsa-sig">Representation of
Field Element to Octet String conversion rules in <xref target='SEC1'/> a ECDSA Signatures</name>
nd where the ordered pair of integers is represented as the rightconcatenation o <t indent="0" pn="section-b.2-1"> With ECDSA, each signature is an order
f these representation ed pair (r, s) of integers <xref target="FIPS186-4" format="default" sectionForm
at="of" derivedContent="FIPS186-4"/>, where each integer is represented as a 32-
octet string according to the
FieldElement-to-OctetString conversion rules in <xref target="SEC1" forma
t="default" sectionFormat="of" derivedContent="SEC1"/> and where the ordered pai
r of integers is represented as the right concatenation of these representation
values (thereby resulting in a 64-octet string). The inverse operation ch ecks that the signature is a 64-octet string and represents the left-side and ri ght-side halves of this values (thereby resulting in a 64-octet string). The inverse operation ch ecks that the signature is a 64-octet string and represents the left-side and ri ght-side halves of this
string (each a 32-octet string) as the integers r and s, respectively, us string (each a 32-octet string) as the integers r and s, respectively, us
ing the Octet String to Field Element conversion rules in <xref target='SEC1'/>. ing the OctetString-to-FieldElement conversion rules in <xref target="SEC1" form
</t></section> at="default" sectionFormat="of" derivedContent="SEC1"/>. In both cases, the
field with these conversion rules is the set of integers modulo n, where
<section anchor='weirepr'><name>Representation of Public Keys Used with E n is the (prime) order of the base point of the curve in question. (For elliptic
CDSA</name> curve nomenclature, see
<t> ECDSA is specified to be used with elliptic curves in short-Weierstra <xref target="I-D.ietf-lwig-curve-representations" sectionFormat="of" sectio
ss form. Each point of such a curve is represented as an octet string using the n="B.1" format="default" derivedLink="https://tools.ietf.org/html/draft-ietf-lwi
Elliptic Curve Point to g-curve-representations-14#appendix-B.1" derivedContent="CURVE-REPR"/>.)
Octet String conversion rules in <xref target='SEC1'/>, where point compr </t>
ession may be enabled (which is indicated by the leftmost octet of this represen </section>
tation). The inverse <section anchor="weirepr" numbered="true" removeInRFC="false" toc="include
operation converts an octet string to a point of this curve using the Oct " pn="section-b.3">
et String to Elliptic Curve Point conversion rules in <xref target='SEC1'/>, whe <name slugifiedName="name-representation-of-public-ke">Representation of
reby the point is rejected Public Keys Used with ECDSA</name>
<t indent="0" pn="section-b.3-1"> ECDSA is specified to be used with ell
iptic curves in short-Weierstrass form. Each point of such a curve is represente
d as an octet string using the Elliptic-Curve-Point-to-Octet-String
conversion rules in <xref target="SEC1" format="default" sectionFormat="
of" derivedContent="SEC1"/>, where point compression may be enabled (which is in
dicated by the leftmost octet of this representation). The inverse
operation converts an octet string to a point of this curve using the Oct
et-String-to-Elliptic-Curve-Point conversion rules in <xref target="SEC1" format
="default" sectionFormat="of" derivedContent="SEC1"/>, whereby the point is reje
cted
if this is the so-called point at infinity. (This is the case if the inpu t to this inverse operation is an octet string of length 1.) </t> if this is the so-called point at infinity. (This is the case if the inpu t to this inverse operation is an octet string of length 1.) </t>
</section> </section>
<section anchor="curves" numbered="true" removeInRFC="false" toc="include"
<section anchor='curves'><name>Alternative Representations of Curve25519< pn="section-b.4">
/name> <name slugifiedName="name-alternative-representations">Alternative Repre
<t> The elliptic curve Curve25519, as specified in <xref target='RFC7748' sentations of Curve25519</name>
/>, is a so-called Montgomery curve. Each point of this curve can also be repres <t indent="0" pn="section-b.4-1"> The elliptic curve Curve25519, as spec
ented as a point ified in <xref target="RFC7748" format="default" sectionFormat="of" derivedConte
nt="RFC7748"/>, is a so-called Montgomery curve. Each point of this curve can al
so be represented as a point
of a twisted Edwards curve or as a point of an elliptic curve in short-We ierstrass form, via a coordinate transformation (a so-called isomorphic mapping) . The parameters of the of a twisted Edwards curve or as a point of an elliptic curve in short-We ierstrass form, via a coordinate transformation (a so-called isomorphic mapping) . The parameters of the
Montgomery curve and the corresponding isomorphic curves in twisted Edwar ds curve and short-Weierstrass form are as indicated below. Here, the domain par ameters of the Montgomery Montgomery curve and the corresponding isomorphic curves in twisted Edwar ds curve and short-Weierstrass form are as indicated below. Here, the domain par ameters of the Montgomery
curve Curve25519 and of the twisted Edwards curve Edwards25519 are as spe curve Curve25519 and of the twisted Edwards curve Edwards25519 are as spe
cified in <xref target='RFC7748'/>; the domain parameters of the elliptic curve cified in <xref target="RFC7748" format="default" sectionFormat="of" derivedCont
Wei25519 in ent="RFC7748"/>; the domain parameters of the elliptic curve Wei25519 in
short-Weierstrass curve comply with Section 6.1.1 of <xref target='FIPS18 short-Weierstrass form comply with Section 6.1.1 of <xref target="FIPS186
6-4'/>. For further details on these curves and on the coordinate transformation -4" format="default" sectionFormat="of" derivedContent="FIPS186-4"/>. For furthe
s referenced above, see r details on these curves and on the coordinate transformations referenced above
<xref target='I-D.ietf-lwig-curve-representations'/>. </t> , see
<xref target="I-D.ietf-lwig-curve-representations" format="default" secti
<t> General parameters (for all curve models): onFormat="of" derivedContent="CURVE-REPR"/>. </t>
</t><dl spacing='compact'> <t indent="0" pn="section-b.4-2"> General parameters (for all curve mode
<dt>p</dt><dd> 2^{255}-19 </dd> ls):</t>
<dt></dt><dd> (=0x7fffffff ffffffff ffffffff ffffffff fff <sourcecode markers="false" pn="section-b.4-3">
fffff ffffffff ffffffff ffffffed) </dd> p 2^{255}-19
<dt>h</dt><dd> 8 </dd> (=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
<dt>n</dt><dd> 723700557733226221397318656304299424085711 ffffffed)
6359379907606001950938285454250989 </dd> h 8
<dt></dt><dd> (=2^{252} + 0x14def9de a2f79cd6 5812631a 5 n
cf5d3ed) </dd> 723700557733226221397318656304299424085711635937990760600195093828
</dl><t> </t> 5454250989
<t> Montgomery curve-specific parameters (for Curve25519): (=2^{252} + 0x14def9de a2f79cd6 5812631a 5cf5d3ed)
</t><dl spacing='compact'> </sourcecode>
<dt>A</dt><dd> 486662 </dd> <t indent="0" pn="section-b.4-4"> Montgomery curve-specific parameters (
<dt>B</dt><dd> 1 </dd> for Curve25519):</t>
<dt>Gu</dt><dd> 9 (=0x9) </dd> <sourcecode markers="false" pn="section-b.4-5">
<dt>Gv</dt><dd> 14781619447589544791020593568409986887264 A 486662
606134616475288964881837755586237401 </dd> B 1
<dt></dt><dd> (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923 Gu 9 (=0x9)
d4d7e 6d7c61b2 29e9c5a2 7eced3d9) </dd> Gv
</dl><t> </t> 147816194475895447910205935684099868872646061346164752889648818377
<t> Twisted Edwards curve-specific parameters (for Edwards25519): 55586237401
</t><dl spacing='compact'> (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2
<dt>a</dt><dd> -1 (-0x01) </dd> 7eced3d9)
<dt>d</dt><dd> -121665/121666 </dd> </sourcecode>
<dt></dt><dd> (=37095705934669439343138083508754565189542 <t indent="0" pn="section-b.4-6"> Twisted Edwards curve-specific paramet
113879843219016388785533085940283555) </dd> ers (for Edwards25519):</t>
<dt></dt><dd> (=0x52036cee 2b6ffe73 8cc74079 7779e898 007 <sourcecode markers="false" pn="section-b.4-7">
00a4d 4141d8ab 75eb4dca 135978a3) </dd> a -1 (-0x01)
<dt>Gx</dt><dd> 15112221349535400772501151409588531511454 d -121665/121666
012693041857206046113283949847762202 </dd> (=3709570593466943934313808350875456518954211387984321901638878553
<dt></dt><dd> (=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692 3085940283555)
cc760 9525a7b2 c9562d60 8f25d51a) </dd> (=0x52036cee 2b6ffe73 8cc74079 7779e898 00700a4d 4141d8ab 75eb4dca
<dt>Gy</dt><dd> 4/5 </dd> 135978a3)
<dt></dt><dd> (=46316835694926478169428394003475163141307 Gx
993866256225615783033603165251855960) </dd> 151122213495354007725011514095885315114540126930418572060461132839
<dt></dt><dd>(=0x66666666 66666666 66666666 66666666 6666 49847762202
6666 66666666 66666666 66666658) </dd> (=0x216936d3 cd6e53fe c0a4e231 fdd6dc5c 692cc760 9525a7b2 c9562d60
</dl><t> </t> 8f25d51a)
<t> Weierstrass curve-specific parameters (for Wei25519): Gy 4/5
</t><dl spacing='compact'> (=4631683569492647816942839400347516314130799386625622561578303360
<dt>a</dt><dd> 192986815395526992372618308347813179755449 3165251855960)
97444273427339909597334573241639236 </dd> (=0x66666666 66666666 66666666 66666666 66666666 66666666 66666666
<dt></dt><dd> (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaa 66666658)
aaaaa aaaaaaaa aaaaaa98 4914a144) </dd> </sourcecode>
<dt>b</dt><dd> 557517466698189089076452890782571408182411 <t indent="0" pn="section-b.4-8"> Weierstrass curve-specific parameters
03727901012315294400837956729358436 </dd> (for Wei25519):</t>
<dt></dt><dd> (=0x7b425ed0 97b425ed 097b425e d097b425 ed0 <sourcecode markers="false" pn="section-b.4-9">
97b42 5ed097b4 260b5e9c 7710c864) </dd> a
<dt>GX</dt><dd> 19298681539552699237261830834781317975544 192986815395526992372618308347813179755449974442734273399095973345
997444273427339909597334652188435546 </dd> 73241639236
<dt></dt><dd> (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaa (=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaa98
aaaaa aaaaaaaa aaaaaaaa aaad245a) </dd> 4914a144)
<dt>GY</dt><dd> 14781619447589544791020593568409986887264 b
606134616475288964881837755586237401 </dd> 557517466698189089076452890782571408182411037279010123152944008379
<dt></dt><dd> (=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923 56729358436
d4d7e 6d7c61b2 29e9c5a2 7eced3d9) </dd> (=0x7b425ed0 97b425ed 097b425e d097b425 ed097b42 5ed097b4 260b5e9c
</dl><t> </t> 7710c864)
</section> GX
192986815395526992372618308347813179755449974442734273399095973346
</section> 52188435546
(=0x2aaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa
</back> aaad245a)
GY
147816194475895447910205935684099868872646061346164752889648818377
55586237401
(=0x20ae19a1 b8a086b4 e01edd2c 7748d14c 923d4d7e 6d7c61b2 29e9c5a2
7eced3d9)
</sourcecode>
</section>
<section numbered="false" removeInRFC="false" toc="include" pn="section-b.
5">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-b.5-1">
Many thanks to <contact fullname="Charlie Perkins"/> for his in-depth revie
w and constructive
suggestions. The authors are also especially grateful to <contact fullname=
"Robert Moskowitz"/>
and <contact fullname="Benjamin Kaduk"/> for their comments and discussions
that led to many improvements.
The authors wish to also thank <contact fullname="Shwetha Bhandari"/> for a
ctively shepherding this document and <contact fullname="Roman Danyliw"/>, <cont
act fullname="Alissa Cooper"/>, <contact fullname="Mirja Kühlewind"/>, <contact
fullname="Éric Vyncke"/>, <contact fullname="Vijay Gurbani"/>, <contact fullname
="Al Morton"/>, and <contact fullname="Adam Montville"/> for their constructive
reviews during the IESG process.
Finally, many thanks to our INT area ADs, <contact fullname="Suresh Krishna
n"/> and <contact fullname="Erik Kline"/>, who
supported us along the whole process.
</t>
</section>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="P." surname="Thubert" fullname="Pascal Thubert" role="ed
itor">
<organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.<
/organization>
<address>
<postal>
<street>Building D</street>
<street>45 Allee des Ormes - BP1200</street>
<city>MOUGINS - Sophia Antipolis</city>
<code>06254</code>
<country>France</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author initials="B." surname="Sarikaya" fullname="Behcet Sarikaya">
<organization showOnFrontPage="true"/>
<address>
<postal>
<street/>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>sarikaya@ieee.org</email>
</address>
</author>
<author initials="M." surname="Sethi" fullname="Mohit Sethi">
<organization showOnFrontPage="true">Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city>
<region/>
<code>02420</code>
<country>Finland</country>
</postal>
<email>mohit@piuha.net</email>
</address>
</author>
<author initials="R." surname="Struik" fullname="Rene Struik">
<organization showOnFrontPage="true">Struik Security Consultancy</organi
zation>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>rstruik.ext@gmail.com</email>
</address>
</author>
</section>
</back>
</rfc> </rfc>
<!-- CONVERT WARNING: wide character found at character 52617 of the output -->
 End of changes. 133 change blocks. 
1562 lines changed or deleted 2722 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/