rfc8994.original.xml   rfc8994.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc, <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
which is available here: http://xml.resource.org. --> nsus="true" docName="draft-ietf-anima-autonomic-control-plane-30" indexInclude="
true" ipr="trust200902" number="8994" prepTime="2021-05-20T23:09:56" scripts="Co
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [ mmon,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="5" to
<!-- Not needed, found better option how to do this cInclude="true" xml:lang="en">
<!ENTITY rfc8422 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/refer <link href="https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-contro
ence.RFC.8422.xml'> l-plane-30" rel="prev"/>
--> <link href="https://dx.doi.org/10.17487/rfc8994" rel="alternate"/>
]> <link href="urn:issn:2070-1721" rel="alternate"/>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
docName="draft-ietf-anima-autonomic-control-plane-30"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
tocInclude="true"
tocDepth="5"
symRefs="true"
sortRefs="true"
consensus="true"
version="3">
<!-- REMOVED in version 12: updates="4291,4193" -->
<!-- ***** FRONT MATTER ***** -->
<front> <front>
<title abbrev="An Autonomic Control Plane (ACP)">An Autonomic Control Plane (ACP)</title> <title abbrev="An Autonomic Control Plane (ACP)">An Autonomic Control Plane (ACP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-autonomic-control- plane-30"/> <seriesInfo name="RFC" value="8994" stream="IETF"/>
<author role="editor" fullname="Toerless Eckert" surname="Eckert"> <author role="editor" fullname="Toerless Eckert" surname="Eckert">
<organization abbrev="Futurewei USA"> <organization abbrev="Futurewei USA" showOnFrontPage="true">Futurewei Tech
Futurewei Technologies Inc. USA</organization> nologies Inc. USA</organization>
<address> <address>
<postal> <postal>
<street>2330 Central Expy</street> <street>2330 Central Expy</street>
<city>Santa Clara</city> <city>Santa Clara</city>
<region>CA</region>
<code>95050</code> <code>95050</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>tte+ietf@cs.fau.de</email> <email>tte+ietf@cs.fau.de</email>
</address> </address>
</author> </author>
<author role="editor" fullname="Michael H. Behringer" initials="M." surname= "Behringer"> <author role="editor" fullname="Michael H. Behringer" initials="M." surname= "Behringer">
<address> <address>
<email>michael.h.behringer@gmail.com</email> <email>michael.h.behringer@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Steinthor Bjarnason" initials="S." surname="Bjarnason"> <author fullname="Steinthor Bjarnason" initials="S." surname="Bjarnason">
<organization>Arbor Networks</organization> <organization showOnFrontPage="true">Arbor Networks</organization>
<address> <address>
<postal> <postal>
<street>2727 South State Street, Suite 200</street> <street>2727 South State Street, Suite 200</street>
<city>Ann Arbor</city> <city>Ann Arbor</city>
<code>MI 48104</code> <region>MI</region>
<country>United States</country> <code>48104</code>
<country>United States of America</country>
</postal> </postal>
<email>sbjarnason@arbor.net</email> <email>sbjarnason@arbor.net</email>
</address> </address>
</author> </author>
<date month="Oct" day="30" year="2020"/> <date month="05" year="2021"/>
<area>Operations and Management</area> <area>Operations and Management</area>
<workgroup>ANIMA WG</workgroup> <workgroup>ANIMA</workgroup>
<abstract> <keyword>addressing-scheme</keyword>
<t> <keyword>ANI</keyword>
Autonomic functions need a control plane to comm <keyword>autonomic networking</keyword>
unicate, which depends on some addressing and routing. This Autonomic Control P <keyword>autonomous operation</keyword>
lane should ideally be self-managing, and as independent as possible of configur <keyword>BRSKI</keyword>
ation. This document defines such a plane and calls it the "Autonomic Control P <keyword>certificate</keyword>
lane", with the primary use as a control plane for autonomic functions. It also <keyword>Data-Plane</keyword>
serves as a "virtual out-of-band channel" for Operations, Administration and Ma <keyword>domain</keyword>
nagement (OAM) communications over a network that provides automatically configu <keyword>DTLS</keyword>
red hop-by-hop authenticated and encrypted communications via automatically con <keyword>DULL</keyword>
figured IPv6 even when the network is not configured, or misconfigured. <keyword>EST</keyword>
</t> <keyword>GRASP</keyword>
<keyword>IDevID</keyword>
<keyword>inband</keyword>
<keyword>IPsec</keyword>
<keyword>IPv6</keyword>
<keyword>LDevID</keyword>
<keyword>loopback-interface</keyword>
<keyword>NOC</keyword>
<keyword>OAM</keyword>
<keyword>out-of-band</keyword>
<keyword>registrar</keyword>
<keyword>renewal</keyword>
<keyword>RPL</keyword>
<keyword>secure</keyword>
<keyword>self-management</keyword>
<keyword>ULA</keyword>
<keyword>VPN</keyword>
<keyword>VRF</keyword>
<keyword/>
<abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">
Autonomic functions need a control plane to comm
unicate, which depends on some addressing and routing. This Autonomic Control P
lane should ideally be self-managing and be as independent as possible of config
uration. This document defines such a plane and calls it the "Autonomic Control
Plane", with the primary use as a control plane for autonomic functions. It al
so serves as a "virtual out-of-band channel" for Operations, Administration, and
Management (OAM) communications over a network that provides automatically conf
igured, hop-by-hop authenticated and encrypted communications via automatically
configured IPv6 even when the network is not configured or is misconfigured.
</t>
</abstract> </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/rfc8994" 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) 2021 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-i
nformative">Introduction (Informative)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><
xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ap
plicability-and-scope">Applicability and Scope</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-acronyms-and-t
erminology-in">Acronyms and Terminology (Informative)</xref></t>
</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-use-cases-for-an-autonomic-">Use C
ases for an Autonomic Control Plane (Informative)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-an-infrastructure-for-
auton">An Infrastructure for Autonomic Functions</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-secure-bootstrap-over-
an-un">Secure Bootstrap over an Unconfigured Network</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
"3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-permanent-reachability
-inde">Permanent Reachability Independent of the Data Plane</xref></t>
</li>
</ul>
</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-requirements-informative">Requirem
ents (Informative)</xref></t>
</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-overview-informative">Overview (In
formative)</xref></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-self-creation-of-an-autonom">Self-
Creation of an Autonomic Control Plane (ACP) (Normative)</xref></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-requirements-for-the-u
se-of">Requirements for the Use of Transport Layer Security (TLS)</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-acp-domain-certificate
-and-">ACP Domain, Certificate, and Network</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.2.2">
<li pn="section-toc.1-1.6.2.2.2.1">
<t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derived
Content="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-acp-certif
icates">ACP Certificates</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.2.2.1"><xref derived
Content="6.2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-acp-certif
icate-acpnodename">ACP Certificate AcpNodeName</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.6.2.2.2.2.2">
<li pn="section-toc.1-1.6.2.2.2.2.2.1">
<t indent="0" pn="section-toc.1-1.6.2.2.2.2.2.1.1"><xref
derivedContent="6.2.2.1" format="counter" sectionFormat="of" target="section-6.
2.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-acpnodename-asn1-module">AcpNodeName ASN.1 Module</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.2.2.3">
<t indent="0" pn="section-toc.1-1.6.2.2.2.3.1"><xref derived
Content="6.2.3" format="counter" sectionFormat="of" target="section-6.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-acp-domain
-membership-check">ACP Domain Membership Check</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.6.2.2.2.3.2">
<li pn="section-toc.1-1.6.2.2.2.3.2.1">
<t indent="0" pn="section-toc.1-1.6.2.2.2.3.2.1.1"><xref
derivedContent="6.2.3.1" format="counter" sectionFormat="of" target="section-6.
2.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-realtime-clock-and-time-val">Realtime Clock and Time Validation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.2.2.4">
<t indent="0" pn="section-toc.1-1.6.2.2.2.4.1"><xref derived
Content="6.2.4" format="counter" sectionFormat="of" target="section-6.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-trust-anch
ors-ta">Trust Anchors (TA)</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.5">
<t indent="0" pn="section-toc.1-1.6.2.2.2.5.1"><xref derived
Content="6.2.5" format="counter" sectionFormat="of" target="section-6.2.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-certificat
e-and-trust-ancho">Certificate and Trust Anchor Maintenance</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.6.2.2.2.5.2">
<li pn="section-toc.1-1.6.2.2.2.5.2.1">
<t indent="0" pn="section-toc.1-1.6.2.2.2.5.2.1.1"><xref
derivedContent="6.2.5.1" format="counter" sectionFormat="of" target="section-6.
2.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-grasp-objective-for-est-ser">GRASP Objective for EST Server</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.5.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.2.5.2.2.1"><xref
derivedContent="6.2.5.2" format="counter" sectionFormat="of" target="section-6.
2.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-renewal">Renewal</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.5.2.3">
<t indent="0" pn="section-toc.1-1.6.2.2.2.5.2.3.1"><xref
derivedContent="6.2.5.3" format="counter" sectionFormat="of" target="section-6.
2.5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-certificate-revocation-list">Certificate Revocation Lists (CRLs)</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.5.2.4">
<t indent="0" pn="section-toc.1-1.6.2.2.2.5.2.4.1"><xref
derivedContent="6.2.5.4" format="counter" sectionFormat="of" target="section-6.
2.5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-lifetimes">Lifetimes</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.5.2.5">
<t indent="0" pn="section-toc.1-1.6.2.2.2.5.2.5.1"><xref
derivedContent="6.2.5.5" format="counter" sectionFormat="of" target="section-6.
2.5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-reenrollment">Reenrollment</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.5.2.6">
<t indent="0" pn="section-toc.1-1.6.2.2.2.5.2.6.1"><xref
derivedContent="6.2.5.6" format="counter" sectionFormat="of" target="section-6.
2.5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-failing-certificates">Failing Certificates</xref></t>
</li>
</ul>
</li>
</ul>
</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-acp-adjacency-table">A
CP Adjacency Table</xref></t>
</li>
<li pn="section-toc.1-1.6.2.4">
<t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent=
"6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-neighbor-discovery-wit
h-dul">Neighbor Discovery with DULL GRASP</xref></t>
</li>
<li pn="section-toc.1-1.6.2.5">
<t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent=
"6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-candidate-acp-neighbor
-sele">Candidate ACP Neighbor Selection</xref></t>
</li>
<li pn="section-toc.1-1.6.2.6">
<t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent=
"6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-channel-selection">Cha
nnel Selection</xref></t>
</li>
<li pn="section-toc.1-1.6.2.7">
<t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent=
"6.7" format="counter" sectionFormat="of" target="section-6.7"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-candidate-acp-neighbor
-veri">Candidate ACP Neighbor Verification</xref></t>
</li>
<li pn="section-toc.1-1.6.2.8">
<t indent="0" pn="section-toc.1-1.6.2.8.1"><xref derivedContent=
"6.8" format="counter" sectionFormat="of" target="section-6.8"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-security-association-s
ecure">Security Association (Secure Channel) Protocols</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.8.2">
<li pn="section-toc.1-1.6.2.8.2.1">
<t indent="0" pn="section-toc.1-1.6.2.8.2.1.1"><xref derived
Content="6.8.1" format="counter" sectionFormat="of" target="section-6.8.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-general-co
nsiderations">General Considerations</xref></t>
</li>
<li pn="section-toc.1-1.6.2.8.2.2">
<t indent="0" pn="section-toc.1-1.6.2.8.2.2.1"><xref derived
Content="6.8.2" format="counter" sectionFormat="of" target="section-6.8.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-common-req
uirements">Common Requirements</xref></t>
</li>
<li pn="section-toc.1-1.6.2.8.2.3">
<t indent="0" pn="section-toc.1-1.6.2.8.2.3.1"><xref derived
Content="6.8.3" format="counter" sectionFormat="of" target="section-6.8.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-acp-via-ip
sec">ACP via IPsec</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.6.2.8.2.3.2">
<li pn="section-toc.1-1.6.2.8.2.3.2.1">
<t indent="0" pn="section-toc.1-1.6.2.8.2.3.2.1.1"><xref
derivedContent="6.8.3.1" format="counter" sectionFormat="of" target="section-6.
8.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-native-ipsec">Native IPsec</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact
" pn="section-toc.1-1.6.2.8.2.3.2.1.2">
<li pn="section-toc.1-1.6.2.8.2.3.2.1.2.1">
<t indent="0" pn="section-toc.1-1.6.2.8.2.3.2.1.2.1.
1"><xref derivedContent="6.8.3.1.1" format="counter" sectionFormat="of" target="
section-6.8.3.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of"
target="name-rfc-8221-ipsec-esp">RFC 8221 (IPsec/ESP)</xref></t>
</li>
<li pn="section-toc.1-1.6.2.8.2.3.2.1.2.2">
<t indent="0" pn="section-toc.1-1.6.2.8.2.3.2.1.2.2.
1"><xref derivedContent="6.8.3.1.2" format="counter" sectionFormat="of" target="
section-6.8.3.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of"
target="name-rfc-8247-ikev2">RFC 8247 (IKEv2)</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.8.2.3.2.2">
<t indent="0" pn="section-toc.1-1.6.2.8.2.3.2.2.1"><xref
derivedContent="6.8.3.2" format="counter" sectionFormat="of" target="section-6.
8.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-ipsec-with-gre-encapsulatio">IPsec with GRE Encapsulation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.8.2.4">
<t indent="0" pn="section-toc.1-1.6.2.8.2.4.1"><xref derived
Content="6.8.4" format="counter" sectionFormat="of" target="section-6.8.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-acp-via-dt
ls">ACP via DTLS</xref></t>
</li>
<li pn="section-toc.1-1.6.2.8.2.5">
<t indent="0" pn="section-toc.1-1.6.2.8.2.5.1"><xref derived
Content="6.8.5" format="counter" sectionFormat="of" target="section-6.8.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-acp-secure
-channel-profiles">ACP Secure Channel Profiles</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.9">
<t indent="0" pn="section-toc.1-1.6.2.9.1"><xref derivedContent=
"6.9" format="counter" sectionFormat="of" target="section-6.9"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-grasp-in-the-acp">GRAS
P in the ACP</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.9.2">
<li pn="section-toc.1-1.6.2.9.2.1">
<t indent="0" pn="section-toc.1-1.6.2.9.2.1.1"><xref derived
Content="6.9.1" format="counter" sectionFormat="of" target="section-6.9.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-grasp-as-a
-core-service-of-">GRASP as a Core Service of the ACP</xref></t>
</li>
<li pn="section-toc.1-1.6.2.9.2.2">
<t indent="0" pn="section-toc.1-1.6.2.9.2.2.1"><xref derived
Content="6.9.2" format="counter" sectionFormat="of" target="section-6.9.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-acp-as-the
-security-and-tra">ACP as the Security and Transport Substrate for GRASP</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.6.2.9.2.2.2">
<li pn="section-toc.1-1.6.2.9.2.2.2.1">
<t indent="0" pn="section-toc.1-1.6.2.9.2.2.2.1.1"><xref
derivedContent="6.9.2.1" format="counter" sectionFormat="of" target="section-6.
9.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-discussion">Discussion</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.10">
<t indent="0" pn="section-toc.1-1.6.2.10.1"><xref derivedContent
="6.10" format="counter" sectionFormat="of" target="section-6.10"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-context-separation">
Context Separation</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11">
<t indent="0" pn="section-toc.1-1.6.2.11.1"><xref derivedContent
="6.11" format="counter" sectionFormat="of" target="section-6.11"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-addressing-inside-th
e-acp">Addressing inside the ACP</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.11.2">
<li pn="section-toc.1-1.6.2.11.2.1">
<t indent="0" pn="section-toc.1-1.6.2.11.2.1.1"><xref derive
dContent="6.11.1" format="counter" sectionFormat="of" target="section-6.11.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-fundame
ntal-concepts-of-aut">Fundamental Concepts of Autonomic Addressing</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.2">
<t indent="0" pn="section-toc.1-1.6.2.11.2.2.1"><xref derive
dContent="6.11.2" format="counter" sectionFormat="of" target="section-6.11.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-acp
-addressing-base-sch">The ACP Addressing Base Scheme</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.3">
<t indent="0" pn="section-toc.1-1.6.2.11.2.3.1"><xref derive
dContent="6.11.3" format="counter" sectionFormat="of" target="section-6.11.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-acp-zon
e-addressing-sub-sch">ACP Zone Addressing Sub-Scheme (ACP-Zone)</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.4">
<t indent="0" pn="section-toc.1-1.6.2.11.2.4.1"><xref derive
dContent="6.11.4" format="counter" sectionFormat="of" target="section-6.11.4"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-acp-man
ual-addressing-sub-s">ACP Manual Addressing Sub-Scheme (ACP-Manual)</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.5">
<t indent="0" pn="section-toc.1-1.6.2.11.2.5.1"><xref derive
dContent="6.11.5" format="counter" sectionFormat="of" target="section-6.11.5"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-acp-vlo
ng-addressing-sub-sc">ACP Vlong Addressing Sub-Scheme (ACP-Vlong-8/ACP-Vlong-16)
</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.6">
<t indent="0" pn="section-toc.1-1.6.2.11.2.6.1"><xref derive
dContent="6.11.6" format="counter" sectionFormat="of" target="section-6.11.6"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-other-a
cp-addressing-sub-sc">Other ACP Addressing Sub-Schemes</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.7">
<t indent="0" pn="section-toc.1-1.6.2.11.2.7.1"><xref derive
dContent="6.11.7" format="counter" sectionFormat="of" target="section-6.11.7"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-acp-reg
istrars">ACP Registrars</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.6.2.11.2.7.2">
<li pn="section-toc.1-1.6.2.11.2.7.2.1">
<t indent="0" pn="section-toc.1-1.6.2.11.2.7.2.1.1"><xre
f derivedContent="6.11.7.1" format="counter" sectionFormat="of" target="section-
6.11.7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-use-of-brski-or-other-mecha">Use of BRSKI or Other Mechanisms or Protocols<
/xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.7.2.2">
<t indent="0" pn="section-toc.1-1.6.2.11.2.7.2.2.1"><xre
f derivedContent="6.11.7.2" format="counter" sectionFormat="of" target="section-
6.11.7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-unique-address-prefix-alloc">Unique Address/Prefix Allocation</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.7.2.3">
<t indent="0" pn="section-toc.1-1.6.2.11.2.7.2.3.1"><xre
f derivedContent="6.11.7.3" format="counter" sectionFormat="of" target="section-
6.11.7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-addressing-sub-scheme-polic">Addressing Sub-Scheme Policies</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.7.2.4">
<t indent="0" pn="section-toc.1-1.6.2.11.2.7.2.4.1"><xre
f derivedContent="6.11.7.4" format="counter" sectionFormat="of" target="section-
6.11.7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-address-prefix-persistence">Address/Prefix Persistence</xref></t>
</li>
<li pn="section-toc.1-1.6.2.11.2.7.2.5">
<t indent="0" pn="section-toc.1-1.6.2.11.2.7.2.5.1"><xre
f derivedContent="6.11.7.5" format="counter" sectionFormat="of" target="section-
6.11.7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-further-details">Further Details</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.12">
<t indent="0" pn="section-toc.1-1.6.2.12.1"><xref derivedContent
="6.12" format="counter" sectionFormat="of" target="section-6.12"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-routing-in-the-acp">
Routing in the ACP</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.12.2">
<li pn="section-toc.1-1.6.2.12.2.1">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.1"><xref derive
dContent="6.12.1" format="counter" sectionFormat="of" target="section-6.12.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-acp-rpl
-profile">ACP RPL Profile</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.6.2.12.2.1.2">
<li pn="section-toc.1-1.6.2.12.2.1.2.1">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.1.1"><xre
f derivedContent="6.12.1.1" format="counter" sectionFormat="of" target="section-
6.12.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-overview">Overview</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact
" pn="section-toc.1-1.6.2.12.2.1.2.1.2">
<li pn="section-toc.1-1.6.2.12.2.1.2.1.2.1">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.1.2.1
.1"><xref derivedContent="6.12.1.1.1" format="counter" sectionFormat="of" target
="section-6.12.1.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="
of" target="name-single-instance">Single Instance</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.1.2.2">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.1.2.2
.1"><xref derivedContent="6.12.1.1.2" format="counter" sectionFormat="of" target
="section-6.12.1.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="
of" target="name-reconvergence">Reconvergence</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.2">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.2.1"><xre
f derivedContent="6.12.1.2" format="counter" sectionFormat="of" target="section-
6.12.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-rpl-instances">RPL Instances</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.3">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.3.1"><xre
f derivedContent="6.12.1.3" format="counter" sectionFormat="of" target="section-
6.12.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-storing-vs-non-storing-mode">Storing vs. Non-Storing Mode</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.4">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.4.1"><xre
f derivedContent="6.12.1.4" format="counter" sectionFormat="of" target="section-
6.12.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-dao-policy">DAO Policy</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.5">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.5.1"><xre
f derivedContent="6.12.1.5" format="counter" sectionFormat="of" target="section-
6.12.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-path-metrics">Path Metrics</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.6">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.6.1"><xre
f derivedContent="6.12.1.6" format="counter" sectionFormat="of" target="section-
6.12.1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-objective-function">Objective Function</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.7">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.7.1"><xre
f derivedContent="6.12.1.7" format="counter" sectionFormat="of" target="section-
6.12.1.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-dodag-repair">DODAG Repair</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.8">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.8.1"><xre
f derivedContent="6.12.1.8" format="counter" sectionFormat="of" target="section-
6.12.1.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-multicast">Multicast</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.9">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.9.1"><xre
f derivedContent="6.12.1.9" format="counter" sectionFormat="of" target="section-
6.12.1.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-security">Security</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.10">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.10.1"><xr
ef derivedContent="6.12.1.10" format="counter" sectionFormat="of" target="sectio
n-6.12.1.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target
="name-p2p-communications">P2P Communications</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.11">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.11.1"><xr
ef derivedContent="6.12.1.11" format="counter" sectionFormat="of" target="sectio
n-6.12.1.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target
="name-ipv6-address-configuration">IPv6 Address Configuration</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.12">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.12.1"><xr
ef derivedContent="6.12.1.12" format="counter" sectionFormat="of" target="sectio
n-6.12.1.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target
="name-administrative-parameters">Administrative Parameters</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.13">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.13.1"><xr
ef derivedContent="6.12.1.13" format="counter" sectionFormat="of" target="sectio
n-6.12.1.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target
="name-rpl-packet-information">RPL Packet Information</xref></t>
</li>
<li pn="section-toc.1-1.6.2.12.2.1.2.14">
<t indent="0" pn="section-toc.1-1.6.2.12.2.1.2.14.1"><xr
ef derivedContent="6.12.1.14" format="counter" sectionFormat="of" target="sectio
n-6.12.1.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target
="name-unknown-destinations">Unknown Destinations</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6.2.13">
<t indent="0" pn="section-toc.1-1.6.2.13.1"><xref derivedContent
="6.13" format="counter" sectionFormat="of" target="section-6.13"/>. <xref deriv
edContent="" format="title" sectionFormat="of" target="name-general-acp-consider
ations">General ACP Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.13.2">
<li pn="section-toc.1-1.6.2.13.2.1">
<t indent="0" pn="section-toc.1-1.6.2.13.2.1.1"><xref derive
dContent="6.13.1" format="counter" sectionFormat="of" target="section-6.13.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-perform
ance">Performance</xref></t>
</li>
<li pn="section-toc.1-1.6.2.13.2.2">
<t indent="0" pn="section-toc.1-1.6.2.13.2.2.1"><xref derive
dContent="6.13.2" format="counter" sectionFormat="of" target="section-6.13.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-address
ing-of-secure-channe">Addressing of Secure Channels</xref></t>
</li>
<li pn="section-toc.1-1.6.2.13.2.3">
<t indent="0" pn="section-toc.1-1.6.2.13.2.3.1"><xref derive
dContent="6.13.3" format="counter" sectionFormat="of" target="section-6.13.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-mtu">MT
U</xref></t>
</li>
<li pn="section-toc.1-1.6.2.13.2.4">
<t indent="0" pn="section-toc.1-1.6.2.13.2.4.1"><xref derive
dContent="6.13.4" format="counter" sectionFormat="of" target="section-6.13.4"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-multipl
e-links-between-node">Multiple Links between Nodes</xref></t>
</li>
<li pn="section-toc.1-1.6.2.13.2.5">
<t indent="0" pn="section-toc.1-1.6.2.13.2.5.1"><xref derive
dContent="6.13.5" format="counter" sectionFormat="of" target="section-6.13.5"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-acp-int
erfaces">ACP Interfaces</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.6.2.13.2.5.2">
<li pn="section-toc.1-1.6.2.13.2.5.2.1">
<t indent="0" pn="section-toc.1-1.6.2.13.2.5.2.1.1"><xre
f derivedContent="6.13.5.1" format="counter" sectionFormat="of" target="section-
6.13.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-acp-loopback-interfaces">ACP Loopback Interfaces</xref></t>
</li>
<li pn="section-toc.1-1.6.2.13.2.5.2.2">
<t indent="0" pn="section-toc.1-1.6.2.13.2.5.2.2.1"><xre
f derivedContent="6.13.5.2" format="counter" sectionFormat="of" target="section-
6.13.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="
name-acp-virtual-interfaces">ACP Virtual Interfaces</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact
" pn="section-toc.1-1.6.2.13.2.5.2.2.2">
<li pn="section-toc.1-1.6.2.13.2.5.2.2.2.1">
<t indent="0" pn="section-toc.1-1.6.2.13.2.5.2.2.2.1
.1"><xref derivedContent="6.13.5.2.1" format="counter" sectionFormat="of" target
="section-6.13.5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="
of" target="name-acp-point-to-point-virtual-">ACP Point-to-Point Virtual Interfa
ces</xref></t>
</li>
<li pn="section-toc.1-1.6.2.13.2.5.2.2.2.2">
<t indent="0" pn="section-toc.1-1.6.2.13.2.5.2.2.2.2
.1"><xref derivedContent="6.13.5.2.2" format="counter" sectionFormat="of" target
="section-6.13.5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="
of" target="name-acp-multi-access-virtual-in">ACP Multi-Access Virtual Interface
s</xref></t>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</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-acp-support-on-l2-switches-">ACP S
upport on L2 Switches/Ports (Normative)</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-why-benefits-of-acp-on
-l2-s">Why (Benefits of ACP on L2 Switches)</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-how-per-l2-port-dull-g
rasp">How (per L2 Port DULL GRASP)</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-support-for-non-acp-compone">Suppo
rt for Non-ACP Components (Normative)</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-acp-connect">ACP Conne
ct</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.1.2">
<li pn="section-toc.1-1.8.2.1.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.2.1.1"><xref derived
Content="8.1.1" format="counter" sectionFormat="of" target="section-8.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-non-acp-co
ntroller-and-or-n">Non-ACP Controller and/or Network Management System (NMS)</xr
ef></t>
</li>
<li pn="section-toc.1-1.8.2.1.2.2">
<t indent="0" pn="section-toc.1-1.8.2.1.2.2.1"><xref derived
Content="8.1.2" format="counter" sectionFormat="of" target="section-8.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-software-c
omponents">Software Components</xref></t>
</li>
<li pn="section-toc.1-1.8.2.1.2.3">
<t indent="0" pn="section-toc.1-1.8.2.1.2.3.1"><xref derived
Content="8.1.3" format="counter" sectionFormat="of" target="section-8.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-autoconfig
uration">Autoconfiguration</xref></t>
</li>
<li pn="section-toc.1-1.8.2.1.2.4">
<t indent="0" pn="section-toc.1-1.8.2.1.2.4.1"><xref derived
Content="8.1.4" format="counter" sectionFormat="of" target="section-8.1.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-combined-a
cp-and-data-plane">Combined ACP and Data Plane Interface (VRF Select)</xref></t>
</li>
<li pn="section-toc.1-1.8.2.1.2.5">
<t indent="0" pn="section-toc.1-1.8.2.1.2.5.1"><xref derived
Content="8.1.5" format="counter" sectionFormat="of" target="section-8.1.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-gra
sp">Use of GRASP</xref></t>
</li>
</ul>
</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-connecting-acp-islands
-over">Connecting ACP Islands over Non-ACP L3 Networks (Remote ACP Neighbors)</x
ref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.2.2">
<li pn="section-toc.1-1.8.2.2.2.1">
<t indent="0" pn="section-toc.1-1.8.2.2.2.1.1"><xref derived
Content="8.2.1" format="counter" sectionFormat="of" target="section-8.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-configured
-remote-acp-neigh">Configured Remote ACP Neighbor</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.2.2.1"><xref derived
Content="8.2.2" format="counter" sectionFormat="of" target="section-8.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-tunneled-r
emote-acp-neighbo">Tunneled Remote ACP Neighbor</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2.2.3">
<t indent="0" pn="section-toc.1-1.8.2.2.2.3.1"><xref derived
Content="8.2.3" format="counter" sectionFormat="of" target="section-8.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-summary">S
ummary</xref></t>
</li>
</ul>
</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-acp-operations-informative">ACP Op
erations (Informative)</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-acp-and-brski-diagnost
ics">ACP (and BRSKI) Diagnostics</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.9.2.1.2">
<li pn="section-toc.1-1.9.2.1.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.2.1.1"><xref derived
Content="9.1.1" format="counter" sectionFormat="of" target="section-9.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-secure-cha
nnel-peer-diagnos">Secure Channel Peer Diagnostics</xref></t>
</li>
</ul>
</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-acp-registrars-2">ACP
Registrars</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.9.2.2.2">
<li pn="section-toc.1-1.9.2.2.2.1">
<t indent="0" pn="section-toc.1-1.9.2.2.2.1.1"><xref derived
Content="9.2.1" format="counter" sectionFormat="of" target="section-9.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-registrar-
interactions">Registrar Interactions</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.2.2.1"><xref derived
Content="9.2.2" format="counter" sectionFormat="of" target="section-9.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-registrar-
parameters">Registrar Parameters</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2.2.3">
<t indent="0" pn="section-toc.1-1.9.2.2.2.3.1"><xref derived
Content="9.2.3" format="counter" sectionFormat="of" target="section-9.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-certificat
e-renewal-and-lim">Certificate Renewal and Limitations</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2.2.4">
<t indent="0" pn="section-toc.1-1.9.2.2.2.4.1"><xref derived
Content="9.2.4" format="counter" sectionFormat="of" target="section-9.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-acp-regist
rars-with-sub-ca">ACP Registrars with Sub-CA</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2.2.5">
<t indent="0" pn="section-toc.1-1.9.2.2.2.5.1"><xref derived
Content="9.2.5" format="counter" sectionFormat="of" target="section-9.2.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-centralize
d-policy-control">Centralized Policy Control</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9.2.3">
<t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent=
"9.3" format="counter" sectionFormat="of" target="section-9.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-enabling-and-disabling
-the-">Enabling and Disabling the ACP and/or the ANI</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.9.2.3.2">
<li pn="section-toc.1-1.9.2.3.2.1">
<t indent="0" pn="section-toc.1-1.9.2.3.2.1.1"><xref derived
Content="9.3.1" format="counter" sectionFormat="of" target="section-9.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-filtering-
for-non-acp-ani-p">Filtering for Non-ACP/ANI Packets</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.2">
<t indent="0" pn="section-toc.1-1.9.2.3.2.2.1"><xref derived
Content="9.3.2" format="counter" sectionFormat="of" target="section-9.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-admin-down
-state">"admin down" State</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.9.2.3.2.2.2">
<li pn="section-toc.1-1.9.2.3.2.2.2.1">
<t indent="0" pn="section-toc.1-1.9.2.3.2.2.2.1.1"><xref
derivedContent="9.3.2.1" format="counter" sectionFormat="of" target="section-9.
3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-security-2">Security</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.2.2.2">
<t indent="0" pn="section-toc.1-1.9.2.3.2.2.2.2.1"><xref
derivedContent="9.3.2.2" format="counter" sectionFormat="of" target="section-9.
3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-fast-state-propagation-and-">Fast State Propagation and Diagnostics</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.2.2.3">
<t indent="0" pn="section-toc.1-1.9.2.3.2.2.2.3.1"><xref
derivedContent="9.3.2.3" format="counter" sectionFormat="of" target="section-9.
3.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-low-level-link-diagnostics">Low-Level Link Diagnostics</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.2.2.4">
<t indent="0" pn="section-toc.1-1.9.2.3.2.2.2.4.1"><xref
derivedContent="9.3.2.4" format="counter" sectionFormat="of" target="section-9.
3.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-power-consumption-issues">Power Consumption Issues</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9.2.3.2.3">
<t indent="0" pn="section-toc.1-1.9.2.3.2.3.1"><xref derived
Content="9.3.3" format="counter" sectionFormat="of" target="section-9.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-enabling-i
nterface-level-ac">Enabling Interface-Level ACP and ANI</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.4">
<t indent="0" pn="section-toc.1-1.9.2.3.2.4.1"><xref derived
Content="9.3.4" format="counter" sectionFormat="of" target="section-9.3.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-which-inte
rfaces-to-auto-en">Which Interfaces to Auto-Enable?</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.5">
<t indent="0" pn="section-toc.1-1.9.2.3.2.5.1"><xref derived
Content="9.3.5" format="counter" sectionFormat="of" target="section-9.3.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-enabling-n
ode-level-acp-and">Enabling Node-Level ACP and ANI</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.9.2.3.2.5.2">
<li pn="section-toc.1-1.9.2.3.2.5.2.1">
<t indent="0" pn="section-toc.1-1.9.2.3.2.5.2.1.1"><xref
derivedContent="9.3.5.1" format="counter" sectionFormat="of" target="section-9.
3.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-brownfield-nodes">Brownfield Nodes</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.5.2.2">
<t indent="0" pn="section-toc.1-1.9.2.3.2.5.2.2.1"><xref
derivedContent="9.3.5.2" format="counter" sectionFormat="of" target="section-9.
3.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-greenfield-nodes">Greenfield Nodes</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9.2.3.2.6">
<t indent="0" pn="section-toc.1-1.9.2.3.2.6.1"><xref derived
Content="9.3.6" format="counter" sectionFormat="of" target="section-9.3.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-undoing-an
i-acp-enable">Undoing "ANI/ACP enable"</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3.2.7">
<t indent="0" pn="section-toc.1-1.9.2.3.2.7.1"><xref derived
Content="9.3.7" format="counter" sectionFormat="of" target="section-9.3.7"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-summary-2"
>Summary</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9.2.4">
<t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent=
"9.4" format="counter" sectionFormat="of" target="section-9.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-partial-or-incremental
-adop">Partial or Incremental Adoption</xref></t>
</li>
<li pn="section-toc.1-1.9.2.5">
<t indent="0" pn="section-toc.1-1.9.2.5.1"><xref derivedContent=
"9.5" format="counter" sectionFormat="of" target="section-9.5"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-configuration-and-the-
acp-s">Configuration and the ACP (Summary)</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-summary-benefits-informativ">Sum
mary: Benefits (Informative)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-self-healing-proper
ties">Self-Healing Properties</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent
="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-self-protection-pro
perties">Self-Protection Properties</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.10.2.2.2">
<li pn="section-toc.1-1.10.2.2.2.1">
<t indent="0" pn="section-toc.1-1.10.2.2.2.1.1"><xref derive
dContent="10.2.1" format="counter" sectionFormat="of" target="section-10.2.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-from-th
e-outside">From the Outside</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.2.2.1"><xref derive
dContent="10.2.2" format="counter" sectionFormat="of" target="section-10.2.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-from-th
e-inside">From the Inside</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10.2.3">
<t indent="0" pn="section-toc.1-1.10.2.3.1"><xref derivedContent
="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-the-administrator-v
iew">The Administrator View</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.13.2">
<li pn="section-toc.1-1.13.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent
="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.13.2.2">
<t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent
="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-background-and-
future-infor">Background and Future (Informative)</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.14.2">
<li pn="section-toc.1-1.14.2.1">
<t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent
="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-acp-address-space-sch
emes">ACP Address Space Schemes</xref></t>
</li>
<li pn="section-toc.1-1.14.2.2">
<t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent
="A.2" format="counter" sectionFormat="of" target="section-a.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-brski-bootstrap-ani">
BRSKI Bootstrap (ANI)</xref></t>
</li>
<li pn="section-toc.1-1.14.2.3">
<t indent="0" pn="section-toc.1-1.14.2.3.1"><xref derivedContent
="A.3" format="counter" sectionFormat="of" target="section-a.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-acp-neighbor-discover
y-prot">ACP Neighbor Discovery Protocol Selection</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.14.2.3.2">
<li pn="section-toc.1-1.14.2.3.2.1">
<t indent="0" pn="section-toc.1-1.14.2.3.2.1.1"><xref derive
dContent="A.3.1" format="counter" sectionFormat="of" target="section-a.3.1"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-lldp">LLD
P</xref></t>
</li>
<li pn="section-toc.1-1.14.2.3.2.2">
<t indent="0" pn="section-toc.1-1.14.2.3.2.2.1"><xref derive
dContent="A.3.2" format="counter" sectionFormat="of" target="section-a.3.2"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-mdns-and-
l2-support">mDNS and L2 Support</xref></t>
</li>
<li pn="section-toc.1-1.14.2.3.2.3">
<t indent="0" pn="section-toc.1-1.14.2.3.2.3.1"><xref derive
dContent="A.3.3" format="counter" sectionFormat="of" target="section-a.3.3"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-why-dull-
grasp">Why DULL GRASP?</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14.2.4">
<t indent="0" pn="section-toc.1-1.14.2.4.1"><xref derivedContent
="A.4" format="counter" sectionFormat="of" target="section-a.4"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-choice-of-routing-pro
tocol-">Choice of Routing Protocol (RPL)</xref></t>
</li>
<li pn="section-toc.1-1.14.2.5">
<t indent="0" pn="section-toc.1-1.14.2.5.1"><xref derivedContent
="A.5" format="counter" sectionFormat="of" target="section-a.5"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-acp-information-distr
ibutio">ACP Information Distribution and Multicast</xref></t>
</li>
<li pn="section-toc.1-1.14.2.6">
<t indent="0" pn="section-toc.1-1.14.2.6.1"><xref derivedContent
="A.6" format="counter" sectionFormat="of" target="section-a.6"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-cas-domains-and-routi
ng-sub">CAs, Domains, and Routing Subdomains</xref></t>
</li>
<li pn="section-toc.1-1.14.2.7">
<t indent="0" pn="section-toc.1-1.14.2.7.1"><xref derivedContent
="A.7" format="counter" sectionFormat="of" target="section-a.7"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-intent-for-the-acp">I
ntent for the ACP</xref></t>
</li>
<li pn="section-toc.1-1.14.2.8">
<t indent="0" pn="section-toc.1-1.14.2.8.1"><xref derivedContent
="A.8" format="counter" sectionFormat="of" target="section-a.8"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-adopting-acp-concepts
-for-o">Adopting ACP Concepts for Other Environments</xref></t>
</li>
<li pn="section-toc.1-1.14.2.9">
<t indent="0" pn="section-toc.1-1.14.2.9.1"><xref derivedContent
="A.9" format="counter" sectionFormat="of" target="section-a.9"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-further-future-option
s">Further (Future) Options</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.14.2.9.2">
<li pn="section-toc.1-1.14.2.9.2.1">
<t indent="0" pn="section-toc.1-1.14.2.9.2.1.1"><xref derive
dContent="A.9.1" format="counter" sectionFormat="of" target="section-a.9.1"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-auto-aggr
egation-of-routes">Auto-Aggregation of Routes</xref></t>
</li>
<li pn="section-toc.1-1.14.2.9.2.2">
<t indent="0" pn="section-toc.1-1.14.2.9.2.2.1"><xref derive
dContent="A.9.2" format="counter" sectionFormat="of" target="section-a.9.2"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-more-opti
ons-for-avoiding-i">More Options for Avoiding IPv6 Data Plane Dependencies</xref
></t>
</li>
<li pn="section-toc.1-1.14.2.9.2.3">
<t indent="0" pn="section-toc.1-1.14.2.9.2.3.1"><xref derive
dContent="A.9.3" format="counter" sectionFormat="of" target="section-a.9.3"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-acp-apis-
and-operational-mo">ACP APIs and Operational Models (YANG)</xref></t>
</li>
<li pn="section-toc.1-1.14.2.9.2.4">
<t indent="0" pn="section-toc.1-1.14.2.9.2.4.1"><xref derive
dContent="A.9.4" format="counter" sectionFormat="of" target="section-a.9.4"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-rpl-enhan
cements">RPL Enhancements</xref></t>
</li>
<li pn="section-toc.1-1.14.2.9.2.5">
<t indent="0" pn="section-toc.1-1.14.2.9.2.5.1"><xref derive
dContent="A.9.5" format="counter" sectionFormat="of" target="section-a.9.5"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-role-assi
gnments">Role Assignments</xref></t>
</li>
<li pn="section-toc.1-1.14.2.9.2.6">
<t indent="0" pn="section-toc.1-1.14.2.9.2.6.1"><xref derive
dContent="A.9.6" format="counter" sectionFormat="of" target="section-a.9.6"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-autonomic
-l3-transit">Autonomic L3 Transit</xref></t>
</li>
<li pn="section-toc.1-1.14.2.9.2.7">
<t indent="0" pn="section-toc.1-1.14.2.9.2.7.1"><xref derive
dContent="A.9.7" format="counter" sectionFormat="of" target="section-a.9.7"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-diagnosti
cs">Diagnostics</xref></t>
</li>
<li pn="section-toc.1-1.14.2.9.2.8">
<t indent="0" pn="section-toc.1-1.14.2.9.2.8.1"><xref derive
dContent="A.9.8" format="counter" sectionFormat="of" target="section-a.9.8"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-avoiding-
and-dealing-with-c">Avoiding and Dealing with Compromised ACP Nodes</xref></t>
</li>
<li pn="section-toc.1-1.14.2.9.2.9">
<t indent="0" pn="section-toc.1-1.14.2.9.2.9.1"><xref derive
dContent="A.9.9" format="counter" sectionFormat="of" target="section-a.9.9"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-detecting
-acp-secure-channe">Detecting ACP Secure Channel Downgrade Attacks</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
f></t>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
<name>Introduction (Informative)</name> ="section-1">
<t>Autonomic Networking is a concept of self-management: Autonomic functio <name slugifiedName="name-introduction-informative">Introduction (Informat
ns self-configure, and negotiate parameters and settings across the network. <xr ive)</name>
ef target="RFC7575" format="default"/> defines the fundamental ideas and design <t indent="0" pn="section-1-1">Autonomic Networking is a concept of self-m
goals of Autonomic Networking. A gap analysis of Autonomic Networking is given anagement: autonomic functions self-configure, and negotiate parameters and sett
in <xref target="RFC7576" format="default"/>. The reference architecture for Au ings across the network. "<xref target="RFC7575" format="title" sectionFormat="o
tonomic Networking in the IETF is specified in the document <xref target="I-D.ie f" derivedContent="Autonomic Networking: Definitions and Design Goals"/>" <xref
tf-anima-reference-model" format="default"/>.</t> target="RFC7575" format="default" sectionFormat="of" derivedContent="RFC7575"/>
<t>Autonomic functions need an autonomically built communications infrastr defines the fundamental ideas and design goals of Autonomic Networking. A gap a
ucture. This infrastructure needs to be secure, resilient and re-usable by all nalysis of Autonomic Networking is given in "<xref target="RFC7576" format="titl
autonomic functions. Section 5 of <xref target="RFC7575" format="default"/> int e" sectionFormat="of" derivedContent="General Gap Analysis for Autonomic Network
roduces that infrastructure and calls it the Autonomic Control Plane (ACP). Mor ing"/>" <xref target="RFC7576" format="default" sectionFormat="of" derivedConten
e descriptively it would be the "Autonomic communications infrastructure for OAM t="RFC7576"/>. The reference architecture for Autonomic Networking in the IETF
and Control". For naming consistency with that prior document, this document c is specified in the document "<xref target="RFC8993" format="title" sectionForma
ontinues to use the name ACP though.</t> t="of" derivedContent="A Reference Model for Autonomic Networking"/>" <xref targ
<t>Today, the OAM and control plane of IP networks is what is typically ca et="RFC8993" format="default" sectionFormat="of" derivedContent="RFC8993"/>.</t>
lled in-band management/signaling: Its management and control protocol traffic d <t indent="0" pn="section-1-2">Autonomic functions need an autonomically b
epends on the routing and forwarding tables, security, policy, QoS and potential uilt communications
ly other configuration that first has to be established through the very same ma infrastructure. This infrastructure needs to be secure, resilient, and
nagement and control protocols. Misconfigurations including unexpected side effe reusable by all autonomic functions. <xref target="RFC7575" sectionFormat
cts or mutual dependences can disrupt OAM and control operations and especially ="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc75
disrupt remote management access to the affected node itself and potentially a m 75#section-5" derivedContent="RFC7575"/> introduces that infrastructure and call
uch larger number of nodes for whom the affected node is on the network path.</t s it the Autonomic Control Plane (ACP). More descriptively, it could be called
> the "Autonomic communications infrastructure for OAM and control". For naming c
onsistency with that prior document, this document continues to use the name ACP
<t>For an example of inband management failing in the face of operator induced m .</t>
isconfiguration, see <xref target="FCC"/>, for example III.B.15 on page 8: "...e <t indent="0" pn="section-1-3">Today, the OAM and control plane of IP netw
ngineers almost immediately recognized that they had misdiagnosed the problem. orks is what is typically called in-band management and/or signaling: its manage
However, they were unable to resolve the issue by restoring the link because the ment and control protocol traffic depends on the routing and forwarding tables,
network management tools required to do so remotely relied on the same paths th security, policy, QoS, and potentially other configuration that first has to be
ey had just disabled".</t> established through the very same management and control protocols. Misconfigura
tions, including unexpected side effects or mutual dependencies, can disrupt OA
<t>Traditionally, physically separate, so-called out-of-band (management) networ M and control operations and especially disrupt remote management access to the
ks have been used to avoid these problems or at least to allow recovery from suc affected node itself and potentially disrupt access to a much larger number of n
h problems. Worst case, personnel are sent on site to access devices through out odes for which the affected node is on the network path.</t>
-of-band management ports (also called craft ports, serial console, management e <t indent="0" pn="section-1-4">For an example of in-band management failin
thernet port). However, both options are expensive.</t> g in the face of operator-induced misconfiguration, see <xref target="FCC" forma
<t>In increasingly automated networks either centralized management system t="default" sectionFormat="of" derivedContent="FCC"/>, for example, Section III.
s or distributed autonomic service agents in the network require a control plane B.15 on page 8:</t>
which is independent of the configuration of the network they manage, to avoid <blockquote pn="section-1-5">...engineers almost immediately recognized th
impacting their own operations through the configuration actions they take.</t> at they had misdiagnosed the problem. However, they were unable to resolve the
issue by restoring the link because the network management tools required to do
<t>This document describes a modular design for a self-forming, self-manag so remotely relied on the same paths they had just disabled.</blockquote>
ing and self-protecting ACP, which is a virtual out-of-band network designed to <t indent="0" pn="section-1-6">Traditionally, physically separate, so-call
be as independent as possible of configuration, addressing and routing to avoid ed out-of-band (management) networks have been used to avoid these problems or a
the self-dependency problems of current IP networks while still operating in-b t least to allow recovery from such problems. In the worst-case scenario, person
and on the same physical network that it is controlling and managing. The ACP de nel are sent on site to access devices through out-of-band management ports (als
sign is therefore intended to combine as well as possible the resilience of out- o called craft ports, serial consoles, or management Ethernet ports). However,
of-band management networks with the low-cost of traditional IP in-band network both options are expensive.</t>
management. The details how this is achieved are described in <xref target="sel <t indent="0" pn="section-1-7">In increasingly automated networks, both ce
f-creation" format="default"/>.</t> ntralized management systems
<t>In a fully autonomic network node without legacy control or management and distributed autonomic service agents in the network require a control plane
functions/protocols, the Data-Plane would be for example just a forwarding plane that is independent of the configuration of the network they manage, to avoid im
for "Data" IPv6 packets, aka: packets other than the control and management pl pacting their own operations through the configuration actions they take.</t>
ane packets that are forwarded by the ACP itself. In such networks/nodes, there <t indent="0" pn="section-1-8">This document describes a modular design fo
would be no non-autonomous control or non-autonomous management plane.</t> r a self-forming, self-managing, and self-protecting ACP, which is a virtual ou
<t>Routing protocols for example would be built inside the ACP as so-calle t-of-band network designed to be as independent as possible of configuration, ad
d autonomous functions via autonomous service agents, leveraging the ACP's funct dressing, and routing to avoid the self-dependency problems of current IP netwo
ions instead of implementing them separately for each protocol: discovery, autom rks while still operating in-band on the same physical network that it is contro
atically established authenticated and encrypted local and distant peer connecti lling and managing. The ACP design is therefore intended to combine as well as p
vity for control and management traffic, and common control/management protocol ossible the resilience of out-of-band management networks with the low cost of t
session and presentation functions.</t> raditional IP in-band network management. The details of how this is achieved a
<t>When ACP functionality is added to nodes that have non-autonomous manag re described in <xref target="self-creation" format="default" sectionFormat="of"
ement plane and/or control plane functions (henceforth called non-autonomous nod derivedContent="Section 6"/>.</t>
es), the ACP instead is best abstracted as a special Virtual Routing and Forward <t indent="0" pn="section-1-9">In a fully Autonomic Network without legacy
ing (VRF) instance (or virtual router) and the complete pre-existing non-autonom control or management functions and/or protocols, the data plane would be just
ous management and/or control plane is considered to be part of the Data-Plane t a forwarding plane for "data" IPv6 packets, which are packets other than those c
o avoid introduction of more complex, new terminology only for this case.</t> ontrol and management plane packets forwarded by the ACP itself. In such a net
<t>Like the forwarding plane for "Data" packets, the non-autonomous contro work, there would be no non-autonomous control of nodes nor a non-autonomous man
l and management plane functions can then be managed/used via the ACP. This term agement plane.</t>
inology is consistent with pre-existing documents such as <xref target="RFC8368" <t indent="0" pn="section-1-10">Routing protocols would be built inside th
format="default"/>.</t> e ACP as autonomous functions via autonomous service agents, leveraging the foll
<t>In both instances (autonomous and non-autonomous nodes), the ACP is bui owing ACP functions instead of implementing them separately for each protocol: d
lt such that it is operating in the absence of the Data-Plane, and in the case o iscovery; automatically established, authenticated, and encrypted local and dist
f existing non-autonomous (management, control) components in the Data-Plane als ant peer connectivity for control and management traffic; and common session and
o in the presence of any (mis-)configuration thereof.</t> presentation functions of the control and management protocol.</t>
<t>The Autonomic Control Plane serves several purposes at the same time: <t indent="0" pn="section-1-11">When ACP functionality is added to nodes t
</t> hat do not have autonomous management plane and/or control plane functions (henc
<ol type="1" spacing="compact"> eforth called non-autonomous nodes), the ACP instead is best abstracted as a spe
<li>Autonomic functions communicate over the ACP. The ACP therefore dir cial Virtual Routing and Forwarding (VRF) instance (or virtual router), and the
ectly supports Autonomic Networking functions, as described in <xref target="I-D complete, preexisting, non-autonomous management and/or control plane is conside
.ietf-anima-reference-model" format="default"/>. For example, Generic Autonomic red to be part of the data plane to avoid introducing more complex terminology o
Signaling Protocol (GRASP - <xref target="I-D.ietf-anima-grasp" format="default nly for this case.</t>
"/>) runs securely inside the ACP and depends on the ACP as its "security and tr <t indent="0" pn="section-1-12">Like the forwarding plane for "data" packe
ansport substrate".</li> ts, the non-autonomous control and management plane functions can then be manage
<li>A controller or network management system can use it to securely boo d and/or used via the ACP. This terminology is consistent with preexisting docum
tstrap network devices in remote locations, even if the (Data-Plane) network in ents such as "<xref target="RFC8368" format="title" sectionFormat="of" derivedCo
between is not yet configured; no Data-Plane dependent bootstrap configuration i ntent="Using an Autonomic Control Plane for Stable Connectivity of Network Opera
s required. An example of such a secure bootstrap process is described in <xref tions, Administration, and Maintenance (OAM)"/>" <xref target="RFC8368" format="
target="I-D.ietf-anima-bootstrapping-keyinfra" format="default"/>.</li> default" sectionFormat="of" derivedContent="RFC8368"/>.</t>
<li>An operator can use it to access remote devices using protocols such <t indent="0" pn="section-1-13">In both autonomous and non-autonomous inst
as Secure SHell (SSH) or Network Configuration Protocol (NETCONF) running acros ances, the ACP is built such that it operates in the absence of the data plane.
s the ACP, even if the network is misconfigured or not configured.</li> The ACP also operates in the presence of any (mis)configured non-autonomous mana
gement and/or control components in the data plane.</t>
<t indent="0" pn="section-1-14">The ACP serves several purposes simultaneo
usly:
</t>
<ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-1-15
">
<li pn="section-1-15.1" derivedCounter="1.">Autonomic functions communic
ate over the ACP. The ACP therefore directly supports Autonomic Networking func
tions, as described in <xref target="RFC8993" format="default" sectionFormat="of
" derivedContent="RFC8993"/>. For example, GRASP ("<xref target="RFC8990" forma
t="title" sectionFormat="of" derivedContent="GeneRic Autonomic Signaling Protoco
l (GRASP)"/>" <xref target="RFC8990" format="default" sectionFormat="of" derived
Content="RFC8990"/>) runs securely inside the ACP and depends on the ACP as its
"security and transport substrate".</li>
<li pn="section-1-15.2" derivedCounter="2.">A controller or network mana
gement system can use ACP to securely bootstrap network devices in remote locati
ons, even if the (data plane) network in between is not yet configured; no boots
trap configuration that is dependent on the data plane is required. An example
of such a secure bootstrap process is described in "<xref target="RFC8995" forma
t="title" sectionFormat="of" derivedContent="Bootstrapping Remote Secure Key Inf
rastructure (BRSKI)"/>" <xref target="RFC8995" format="default" sectionFormat="o
f" derivedContent="RFC8995"/>.</li>
<li pn="section-1-15.3" derivedCounter="3.">An operator can use ACP to a
ccess remote devices using protocols such as Secure SHell (SSH) or Network Confi
guration Protocol (NETCONF), even if the network is misconfigured or unconfigure
d.</li>
</ol> </ol>
<t>This document describes these purposes as use cases for the ACP in <xre <t indent="0" pn="section-1-16">This document describes these purposes as
f target="usage" format="default"/>, it defines the requirements in <xref target use cases for the ACP in <xref target="usage" format="default" sectionFormat="of
="requirements" format="default"/>. <xref target="overview" format="default"/> g " derivedContent="Section 3"/>, and it defines the requirements in <xref target=
ives an overview of how the ACP is constructed.</t> "requirements" format="default" sectionFormat="of" derivedContent="Section 4"/>.
<t>The normative part of this document starts with <xref target="self-crea <xref target="overview" format="default" sectionFormat="of" derivedContent="Sec
tion" format="default"/>, where the ACP is specified. <xref target="acp-l2-switc tion 5"/> gives an overview of how the ACP is constructed.</t>
hes" format="default"/> explains how to support ACP on L2 switches (normative). <t indent="0" pn="section-1-17">The normative part of this document starts
<xref target="workarounds" format="default"/> explains how non-ACP nodes and net with <xref target="self-creation" format="default" sectionFormat="of" derivedCo
works can be integrated (normative).</t> ntent="Section 6"/>, where the ACP is specified. <xref target="acp-l2-switches"
<t>The remaining sections are non-normative: <xref target="benefit" format format="default" sectionFormat="of" derivedContent="Section 7"/> explains how to
="default"/> reviews benefits of the ACP (after all the details have been define support ACP on Layer 2 (L2) switches (normative). <xref target="workarounds" fo
d), <xref target="operational" format="default"/> provides operational recommend rmat="default" sectionFormat="of" derivedContent="Section 8"/> explains how non-
ations, <xref target="further" format="default"/> provides additional explanatio ACP nodes and networks can be integrated (normative).</t>
ns and describes additional details or future standard or proprietary extensions <t indent="0" pn="section-1-18">The remaining sections are non-normative.
that were considered not to be appropriate for standardization in this document <xref target="benefit" format="default" sectionFormat="of" derivedContent="Secti
but were considered important to document. There are no dependencies against <x on 10"/> reviews the benefits of the ACP (after all the details have been define
ref target="further" format="default"/> to build a complete working and interope d). <xref target="operational" format="default" sectionFormat="of" derivedConten
rable t="Section 9"/> provides operational recommendations. <xref target="further" for
mat="default" sectionFormat="of" derivedContent="Appendix A"/>
provides additional background and describes possible
extensions that were not applicable for this specification but were
considered important to document.
There are no dependencies on <xref target="further" format="default" sectionForm
at="of" derivedContent="Appendix A"/> in order to build a complete working and i
nteroperable
ACP according to this document.</t> ACP according to this document.</t>
<t>The ACP provides secure IPv6 connectivity, therefore it can be used not <t indent="0" pn="section-1-19">The ACP provides secure IPv6 connectivity;
only as the secure connectivity for self-management as required for the ACP in therefore, it can be used for secure connectivity not only for self-management
<xref target="RFC7575" format="default"/>, but it can also be used as the secure as required for the ACP in <xref target="RFC7575" format="default" sectionFormat
connectivity for traditional (centralized) management. The ACP can be implement ="of" derivedContent="RFC7575"/> but also for traditional (centralized) manageme
ed and operated without any other components of autonomic networks, except for t nt. The ACP can be implemented and operated without any other components of Auto
he GRASP protocol. ACP relies on per-link DULL GRASP (see <xref target="discover nomic Networks, except for GRASP. ACP relies on per-link Discovery Unsolicited L
y-grasp" format="default"/>) to autodiscover ACP neighbors, and includes the ACP ink-Local (DULL) GRASP (see <xref target="discovery-grasp" format="default" sect
GRASP instance to provide service discovery for clients of the ACP (see <xref t ionFormat="of" derivedContent="Section 6.4"/>) to auto-discover ACP neighbors an
arget="GRASP" format="default"/>) including for its own maintenance of ACP certi d includes the ACP GRASP instance to provide service discovery for clients of th
ficates.</t> e ACP (see <xref target="GRASP" format="default" sectionFormat="of" derivedConte
<t>The document <xref target="RFC8368" format="default">"Using Autonomic C nt="Section 6.9"/>), including for its own maintenance of ACP certificates.</t>
ontrol Plane for Stable Connectivity of Network OAM"</xref> describes how the AC <t indent="0" pn="section-1-20">The document <xref target="RFC8368" format
P alone can be used to provide secure and stable connectivity for autonomic and ="default" sectionFormat="of" derivedContent="RFC8368"/> describes how the ACP c
non-autonomic OAM applications, specifically for the case of current non-autonom an be used alone to provide secure and stable connectivity for autonomic and non
ic networks/nodes. That document also explains how existing management solutions -autonomic OAM applications, specifically for the case of current non-autonomic
can leverage the ACP in parallel with traditional management models, when to us networks and/or nodes. That document also explains how existing management solut
e the ACP and how to integrate with potentially IPv4 only OAM backends.</t> ions can leverage the ACP in parallel with traditional management models, when t
<t>Combining ACP with Bootstrapping Remote Secure Key Infrastructures (BRS o use the ACP, and how to integrate with potentially IPv4-only OAM backends.</t>
KI), see <xref target="I-D.ietf-anima-bootstrapping-keyinfra" format="default"/> <t indent="0" pn="section-1-21">Combining ACP with Bootstrapping Remote Se
) results in the "Autonomic Network Infrastructure" (ANI) as defined in <xref ta cure Key Infrastructure (BRSKI) (see <xref target="RFC8995" format="default" sec
rget="I-D.ietf-anima-reference-model" format="default"/>, which provides autonom tionFormat="of" derivedContent="RFC8995"/>) results in the "Autonomic Network In
ic connectivity (from ACP) with secure zero-touch (automated) bootstrap from BRS frastructure" (ANI) as defined in <xref target="RFC8993" format="default" sectio
KI. The ANI itself does not constitute an Autonomic Network, but it allows the nFormat="of" derivedContent="RFC8993"/>, which provides autonomic connectivity (
building of more or less autonomic networks on top of it - using either centrali from ACP) with secure zero-touch (automated) bootstrap from BRSKI. The ANI itse
zed, Software Defined Networking- (SDN-)style (see <xref target="RFC7426" format lf does not constitute an Autonomic Network, but it allows the building of more
="default"/>) automation or distributed automation via Autonomic Service Agents or less Autonomic Networks on top of it, using either centralized automation in
(ASA) / Autonomic Functions (AF) - or a mixture of both. See <xref target="I-D. SDN style (see "<xref target="RFC7426" format="title" sectionFormat="of" derived
ietf-anima-reference-model" format="default"/> for more information.</t> Content="Software-Defined Networking (SDN): Layers and Architecture Terminology"
<section anchor="applicability" numbered="true" toc="default"> />" <xref target="RFC7426" format="default" sectionFormat="of" derivedContent="R
<name>Applicability and Scope</name> FC7426"/>) or distributed automation via Autonomic Service Agents (ASA) and/or A
<t>Please see the following Terminology section (<xref target="terminolo utonomic Functions (AF), or a mixture of both. See <xref target="RFC8993" forma
gy" format="default"/>) for explanations of terms used in this section.</t> t="default" sectionFormat="of" derivedContent="RFC8993"/> for more information.<
<t>The design of the ACP as defined in this document is considered to be /t>
applicable to all types of "professionally managed" networks: Service Provider, <section anchor="applicability" numbered="true" toc="include" removeInRFC=
Local Area Network (LAN), Metro(politan networks), Wide Area Network (WAN), Ent "false" pn="section-1.1">
erprise Information Technology (IT) and <xref target="ot" format="none">-&gt;"Op <name slugifiedName="name-applicability-and-scope">Applicability and Sco
erational Technology"</xref> (OT) networks. The ACP can operate equally on layer pe</name>
3 equipment and on layer 2 equipment such as bridges (see <xref target="acp-l2- <t indent="0" pn="section-1.1-1">Please see the following Terminology se
switches" format="default"/>). The hop-by-hop authentication, integrity-protecti ction (<xref target="terminology" format="default" sectionFormat="of" derivedCon
on and confidentiality mechanism used by the ACP is defined to be negotiable, th tent="Section 2"/>) for explanations of terms used in this section.</t>
erefore it can be extended to environments with different protocol preferences. <t indent="0" pn="section-1.1-2">The design of the ACP as defined in thi
The minimum implementation requirements in this document attempt to achieve max s document is considered to
imum interoperability by requiring support for multiple options depending on the be applicable to all types of "professionally managed" networks:
type of device: IPsec, see <xref target="RFC4301" format="default"/>, and Datag Service Provider, Local Area Network (LAN), Metropolitan Area Network (MA
ram Transport Layer Security (DTLS, see <xref target="DTLS" format="default"/>). N/Metro),
</t> Wide Area Network (WAN), Enterprise Information Technology (IT) and
<t>The implementation footprint of the ACP consists of Public Key Infras <xref target="ot" format="none" sectionFormat="of" derivedContent="">Oper
tructure (PKI) code for the ACP certificate including "Enrollment over Secure Tr ational Technology</xref> (OT) networks. The ACP can operate equally on Layer 3
ansport (EST, see <xref target="RFC7030" format="default"/>), the GRASP protocol (L3) equipment and on L2 equipment such as bridges (see <xref target="acp-l2-swi
, UDP, TCP and Transport Layer Security (TLS, see <xref target="tls" format="def tches" format="default" sectionFormat="of" derivedContent="Section 7"/>). The ho
ault"/>), for security and reliability of GRASP and for EST, the ACP secure chan p-by-hop authentication, integrity protection, and confidentiality mechanism use
nel protocol used (such as IPsec or DTLS), and an instance of IPv6 packet forwar d by the ACP is defined to be negotiable; therefore, it can be extended to envi
ding and routing via the Routing Protocol for Low-power and Lossy Networks (RPL) ronments with different protocol preferences. The minimum implementation require
, see <xref target="RFC6550" format="default"/>, that is separate from routing a ments in this document attempt to achieve maximum interoperability by requiring
nd forwarding for the Data-Plane (user traffic).</t> support for multiple options depending on the type of device: IPsec (see "<xref
<t>The ACP uses only IPv6 to avoid complexity of dual-stack ACP operatio target="RFC4301" format="title" sectionFormat="of" derivedContent="Security Arch
ns (IPv6/IPv4). Nevertheless, it can without any changes be integrated into even itecture for the Internet Protocol"/>" <xref target="RFC4301" format="default" s
otherwise IPv4-only network devices. The Data-Plane itself would not need to ch ectionFormat="of" derivedContent="RFC4301"/>) and Datagram Transport Layer Secur
ange and it could continue to be IPv4 only. For such IPv4-only devices, the IPv6 ity (DTLS, see <xref target="DTLS" format="default" sectionFormat="of" derivedCo
protocol itself would be additional implementation footprint that is only requi ntent="Section 6.8.4"/>).</t>
red for the ACP.</t> <t indent="0" pn="section-1.1-3">The implementation footprint of the ACP
<t>The protocol choices of the ACP are primarily based on wide use and s consists of Public Key Infrastructure (PKI) code for the ACP certificate includ
upport in networks and devices, well understood security properties and required ing EST (see "<xref target="RFC7030" format="title" sectionFormat="of" derivedCo
scalability. The ACP design is an attempt to produce the lowest risk combinatio ntent="Enrollment over Secure Transport"/>" <xref target="RFC7030" format="defau
n of existing technologies and protocols to build a widely applicable operationa lt" sectionFormat="of" derivedContent="RFC7030"/>), GRASP, UDP, TCP, and Transpo
l network management solution.</t> rt Layer Security (TLS, see <xref target="tls" format="default" sectionFormat="o
<t>RPL was chosen because it requires a smaller routing table footprint f" derivedContent="Section 6.1"/>). For more information regarding the security
in large networks compared to other routing protocols with an autonomically conf and reliability of GRASP and for EST, the ACP secure channel protocol used (such
igured single area. The deployment experience of large scale Internet of Things as IPsec or DTLS), and an instance of IPv6 packet forwarding and routing via RP
(IoT) networks serves as the basis for wide deployment experience with RPL. The L, see "<xref target="RFC6550" format="title" sectionFormat="of" derivedContent=
profile chosen for RPL in the ACP does not leverage any RPL specific forwarding "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"/>" <xref target="R
plane features (IPv6 extension headers), making its implementation a pure contro FC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/>, which is
l plane software requirement.</t> separate from routing and forwarding for the data plane (user traffic).</t>
<t>GRASP is the only completely novel protocol used in the ACP, and this <t indent="0" pn="section-1.1-4">The ACP uses only IPv6 to avoid the com
choice was necessary because there is no existing suitable protocol to provide plexity of dual-stack (both IPv6 and IPv4) ACP operations. Nevertheless, it can
the necessary functions to the ACP, so GRASP was developed to fill that gap.</t> be integrated without any changes to otherwise IPv4-only network devices. The da
<t>The ACP design can be applicable to devices constrained with respect ta plane itself would not need to change, and it could continue to be IPv4 only.
to cpu and memory, and to networks constrained with respect to bitrate and relia For such IPv4-only devices, IPv6 itself would be additional implementation foot
bility, print that is only required for the ACP.</t>
but this document does not attempt to define the most constrained type of device <t indent="0" pn="section-1.1-5">The protocol choices of the ACP are pri
s or networks to which the ACP is applicable. RPL and DTLS for ACP secure channe marily based on wide use and support in networks and devices, well-understood se
ls are two protocol choices already making ACP more applicable to constrained en curity properties, and required scalability. The ACP design is an attempt to pro
vironments. Support for constrained devices in this specification is opportunist duce the lowest risk combination of existing technologies and protocols to build
ic, but not complete, because the reliable transport for GRASP (see <xref target a widely applicable, operational network management solution.</t>
="GRASP-substrate" format="default"/>) only specifies TCP/TLS. See <xref target <t indent="0" pn="section-1.1-6">RPL was chosen because it requires a sm
="reuse-acp" format="default"/> for discussions about how future standards or pr aller routing table footprint in large networks compared to other routing protoc
oprietary extensions/variations of the ACP could better meet different expectati ols with an autonomically configured single area. The deployment experience of l
ons from those on which the current design is based including supporting constra arge-scale Internet of Things (IoT) networks serves as the basis for wide deploy
ined devices better.</t> ment experience with RPL. The profile chosen for RPL in the ACP does not leverag
e any RPL-specific forwarding plane features (IPv6 extension headers), making it
s implementation a pure control plane software requirement.</t>
<t indent="0" pn="section-1.1-7">GRASP is the only completely novel prot
ocol used in the ACP, and this choice was necessary because there is no existing
protocol suitable for providing the necessary functions to the ACP, so GRASP wa
s developed to fill that gap.</t>
<t indent="0" pn="section-1.1-8">The ACP design can be applicable to dev
ices constrained with respect to CPU and memory, and to networks constrained wit
h respect to bitrate and reliability,
but this document does not attempt to define the most constrained type of device
s or networks to which the ACP is applicable. RPL and DTLS for ACP secure channe
ls are two protocol choices already making ACP more applicable to constrained en
vironments. Support for constrained devices in this specification is opportunist
ic, but not complete, because the reliable transport for GRASP (see <xref target
="GRASP-substrate" format="default" sectionFormat="of" derivedContent="Section 6
.9.2"/>) only specifies TCP/TLS. See <xref target="reuse-acp" format="default"
sectionFormat="of" derivedContent="Appendix A.8"/> for discussions about how fut
ure standards or proprietary extensions and/or variations of the ACP could bette
r meet expectations that are different from those upon which the current design
is based, including supporting constrained devices better.</t>
</section> </section>
<!-- applicability -->
</section> </section>
<!-- intro --> <section anchor="terminology" numbered="true" toc="include" removeInRFC="fal
<section anchor="terminology" numbered="true" toc="default"> se" pn="section-2">
<name>Acronyms and Terminology (Informative)</name> <name slugifiedName="name-acronyms-and-terminology-in">Acronyms and Termin
<t>[RFC-Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc-edit ology (Informative)</name>
or.org/materials/abbrev.expansion.txt.]</t> <t indent="0" pn="section-2-1">This document serves both as a normative sp
<t>[RFC-Editor: What is the recommended way to reference a hanging text, e ecification for ACP
.g. to node behavior as well as an explanation of the context by providing desc
a definition in the list of definitions? Up to -28, this document was usi riptions of requirements, benefits,
ng XMLv2 architecture, and operational aspects.
and the only option I could find for RFC/XML to point to a hanging text w Normative sections are labeled "(Normative)" and use BCP 14 keywords.
as Other sections are labeled "(Informative)" and do not use those normativ
format="title", which leads to references such as '-&gt;"ACP certificate" e
()', aka:
redundant empty parenthesis. Many reviewers where concerned about this.
I created a ticket to ask for an xml2rfc enhancement to avoid this
in the future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.
When i
changed to XMLv3 in version -29, i could get rid of the unnecessary () by
using
format="none", but that format is declared to be deprecated in XMLv3. So
i am not
aware of any working AND "non-deprecated" option.]</t>
<t>[RFC-Editor: Question: Is it possible to change the first occurrences o
f
[RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC format doe
s
not seem to offer such a format, but I did not want to duplicate 50 firs
t
references - one reference for title mentioning and one
for RFC number.]</t>
<t>This document serves both as a normative specification for how ACP
nodes have to behave as well as describing requirements, benefits,
architecture and operational aspects to explain the context.
Normative sections are labelled "(Normative)" and use BCP 14 keywords.
Other sections are labelled "(Informative)" and do not use those normati
ve
keywords.</t> keywords.</t>
<t>In the rest of the document we will refer to systems using the ACP as " <t indent="0" pn="section-2-2">In the rest of the document, we will refer
nodes". Typically, such a node is a physical (network equipment) device, but it to systems that use the ACP as "nodes". Typically, such a node is a physical (n
can equally be some virtualized system. Therefore, we do not refer to them as etwork equipment) device, but it can equally be some virtualized system. Theref
devices unless the context specifically calls for a physical system.</t> ore, we do not refer to them as devices unless the context specifically calls fo
<t>This document introduces or uses the following terms (sorted alphabetic r a physical system.</t>
ally). Terms introduced are <t indent="0" pn="section-2-3">This document introduces or uses the follow
ing terms (sorted alphabetically). Introduced terms are
explained on first use, so this list is for reference only.</t> explained on first use, so this list is for reference only.</t>
<dl spacing="compact"> <dl spacing="normal" newline="false" indent="3" pn="section-2-4">
<dt>ACP:</dt> <dt pn="section-2-4.1">ACP:</dt>
<dd>"Autonomic Control Plane". The Autonomic Function as defined in thi <dd pn="section-2-4.2">Autonomic Control Plane. The <xref target="af-de
s document. f" format="none" sectionFormat="of" derivedContent="">autonomic function</xref>
It provides secure zero-touch (automated) transitive (network wide) as defined in this document.
IPv6 connectivity for all nodes in the same ACP domain as well as a GRASP instan It provides secure, zero-touch (automated) transitive (network-wide)
ce running across this ACP IPv6 connectivity. IPv6 connectivity for all nodes in the same ACP domain as well as a GRASP insta
The ACP is primarily meant to be used as a component of the ANI to e nce running across this ACP IPv6 connectivity.
nable Autonomic Networks The ACP is primarily meant to be used as a component of the <xref ta
but it can equally be used in simple ANI networks (with no other Aut rget="ani-def" format="none" sectionFormat="of" derivedContent="">ANI</xref> to
onomic Functions) or enable <xref target="an-def" format="none" sectionFormat="of" derivedContent="">
Autonomic Networks</xref>,
but it can equally be used in simple ANI networks (with no other aut
onomic functions) or
completely by itself. completely by itself.
</dd> </dd>
<dt>ACP address:</dt> <dt pn="section-2-4.3">ACP address:</dt>
<dd>An IPv6 address assigned to the ACP node. It is stored <dd pn="section-2-4.4">An IPv6 address assigned to the ACP node. It is
in the acp-node-name of the <xref target="domcert-def" format="none" stored
>-&gt;"ACP certificate"</xref>. in the <xref target="acp-node-name-def" format="none" sectionFormat=
</dd> "of" derivedContent="">acp-node-name</xref> of the <xref target="domcert-def" fo
<dt>ACP address range/set:</dt> rmat="none" sectionFormat="of" derivedContent="">ACP certificate</xref>.
<dd>The ACP address may imply a range or set of addresses that the node
can assign for different purposes. This address range/set is derived by the nod
e from the format of the ACP address called the "addressing sub-scheme".
</dd>
<dt>ACP connect interface:</dt>
<dd>An interface on an ACP node providing access to the ACP for non ACP
capable nodes without using an ACP secure channel. See <xref target="NMS" forma
t="default"/>.
</dd> </dd>
<dt>ACP domain:</dt> <dt pn="section-2-4.5">ACP address range or set:</dt>
<dd>The ACP domain is the set of nodes with <xref target="domcert-def" f <dd pn="section-2-4.6">The ACP address may imply a range or set of addre
ormat="none">-&gt;"ACP certificates"</xref> that allow them to authenticate each sses that the node can assign for different purposes. This address range or set
other as members of the ACP domain. See also <xref target="certcheck" format=" is derived by the node from the format of the ACP address called the addressing
default"/>.</dd> sub-scheme.
<dt>ACP (ANI/AN) certificate:</dt>
<dd anchor="domcert-def">A <xref target="RFC5280" format="default"/> cer
tificate (LDevID)
carrying the acp-node-name which is used by the ACP to learn its add
ress
in the ACP and to derive and cryptographically assert its membership
in the ACP domain.
</dd> </dd>
<dt>ACP acp-node-name field:</dt> <dt anchor="domcert-def" pn="section-2-4.7">ACP certificate:</dt>
<dd>An information field in the ACP certificate in <dd pn="section-2-4.8">A Local Device IDentity (<xref target="ldevid" fo
which the ACP relevant information is encoded: the ACP domain name, rmat="none" sectionFormat="of" derivedContent="">LDevID</xref>) certificate conf
the ACP IPv6 address of the node orming to "<xref target="RFC5280" format="title" sectionFormat="of" derivedConte
and optional additional role attributes about the node. nt="Internet X.509 Public Key Infrastructure Certificate and Certificate Revocat
ion List (CRL) Profile"/>" <xref target="RFC5280" format="default" sectionFormat
="of" derivedContent="RFC5280"/> that carries the <xref target="acp-node-name-de
f" format="none" sectionFormat="of" derivedContent="">acp-node-name</xref>, whic
h is used by the ACP to learn its address in the ACP and to derive and cryptogra
phically assert its membership in the ACP domain. In the context of the ANI, th
e ACP certificate is also called the ANI certificate.
In the context of AN, the ACP certificate is also called the AN certificate. </d
d>
<dt pn="section-2-4.9">ACP connect interface:</dt>
<dd pn="section-2-4.10">An interface on an ACP node that provides access
to the ACP for non-ACP-capable nodes without using an ACP secure channel. See
<xref target="NMS" format="default" sectionFormat="of" derivedContent="Section 8
.1.1"/>.
</dd> </dd>
<dt>ACP Loopback interface:</dt> <dt pn="section-2-4.11">ACP domain:</dt>
<dd anchor="acp-loopback-def">The Loopback interface in the ACP Virtual <dd pn="section-2-4.12">The ACP domain is the set of nodes with <xref ta
Routing and Forwarding (VRF) that has the ACP address assigned to it. See <xref rget="domcert-def" format="none" sectionFormat="of" derivedContent="">ACP certif
target="ACP-loopback" format="default"/>. icates</xref> that allow them to authenticate each other as members of the ACP d
omain. See also <xref target="certcheck" format="default" sectionFormat="of" de
rivedContent="Section 6.2.3"/>.</dd>
<dt anchor="acp-loopback-def" pn="section-2-4.13">ACP loopback interface
:</dt>
<dd pn="section-2-4.14">The loopback interface in the ACP <xref target="
vrf-def" format="none" sectionFormat="of" derivedContent="">VRF</xref> that has
the ACP address assigned to it. See <xref target="ACP-loopback" format="default"
sectionFormat="of" derivedContent="Section 6.13.5.1"/>.
</dd> </dd>
<dt>ACP network:</dt> <dt pn="section-2-4.15">ACP network:</dt>
<dd>The ACP network constitutes all the nodes that have access to the AC <dd pn="section-2-4.16">The ACP network comprises all the nodes that hav
P. e access to the ACP.
It is the set of active and transitively connected nodes of an ACP d omain plus all nodes that get access to It is the set of active and transitively connected nodes of an ACP d omain plus all nodes that get access to
the ACP of that domain via ACP edge nodes. the ACP of that domain via ACP edge nodes.
</dd> </dd>
<dt>ACP (ULA) prefix(es):</dt> <dt pn="section-2-4.17">ACP (ULA) prefix(es):</dt>
<dd>The /48 IPv6 address prefixes used across the ACP. In the normal/si <dd pn="section-2-4.18">The /48 IPv6 address prefixes used across the AC
mple case, the ACP has one ULA prefix, see <xref target="addressing" format="def P. In the normal or simple case, the ACP has one <xref target="ula-def" format=
ault"/>. The ACP routing table may include multiple ULA prefixes if the "rsub" "none" sectionFormat="of" derivedContent="">Unique Local Address (ULA)</xref> pr
option is used to create addresses from more than one ULA prefix. See <xref tar efix, see <xref target="addressing" format="default" sectionFormat="of" derivedC
get="domcert-acpinfo" format="default"/>. The ACP may also include non-ULA pref ontent="Section 6.11"/>. The ACP routing table may include multiple ULA prefixe
ixes if those are configured on ACP connect interfaces. See <xref target="NMS" s if the rsub option is used to create addresses from more than one ULA prefix.
format="default"/>. See <xref target="domcert-acpinfo" format="default" sectionFormat="of" derivedC
ontent="Section 6.2.2"/>. The ACP may also include non-ULA prefixes if those ar
e configured on ACP connect interfaces. See <xref target="NMS" format="default"
sectionFormat="of" derivedContent="Section 8.1.1"/>.
</dd> </dd>
<dt>ACP secure channel:</dt> <dt pn="section-2-4.19">ACP secure channel:</dt>
<dd>A channel authenticated via <xref target="domcert-def" format="none" <dd pn="section-2-4.20">A channel authenticated via <xref target="domcer
>-&gt;"ACP certificates"</xref> providing integrity protection and confidentiali t-def" format="none" sectionFormat="of" derivedContent="">ACP certificates</xref
ty through encryption. These are established between (normally) adjacent ACP nod > providing integrity protection and confidentiality through encryption. These c
es to carry traffic of the ACP VRF securely and isolated from Data-Plane traffic hannels are established between (normally) adjacent ACP nodes to carry ACP <xref
in-band over the same link/path as the Data-Plane. target="vrf-def" format="none" sectionFormat="of" derivedContent="">VRF</xref>
traffic in-band over the same links and paths as data plane traffic but isolate
it from the data plane traffic and secure it.
</dd> </dd>
<dt>ACP secure channel protocol:</dt> <dt pn="section-2-4.21">ACP secure channel protocol:</dt>
<dd>The protocol used to build an ACP secure channel, <dd pn="section-2-4.22">The protocol used to build an ACP secure channel
e.g., Internet Key Exchange Protocol version 2 (IKEv2) with IPsec or ,
Datagram Transport Layer Security (DTLS). e.g., Internet Key Exchange Protocol version 2 (IKEv2) with IPsec or
DTLS.
</dd> </dd>
<dt>ACP virtual interface:</dt> <dt pn="section-2-4.23">ACP virtual interface:</dt>
<dd>An interface in the ACP VRF mapped to one or more <dd pn="section-2-4.24">An interface in the ACP <xref target="vrf-def" f
ACP secure channels. See <xref target="ACP_interfaces" format="defa ormat="none" sectionFormat="of" derivedContent="">VRF</xref> mapped to one or mo
ult"/>. re
ACP secure channels. See <xref target="ACP_interfaces" format="defa
ult" sectionFormat="of" derivedContent="Section 6.13.5"/>.
</dd> </dd>
<dt>AN</dt> <dt anchor="acp-node-name-def" pn="section-2-4.25">acp-node-name field:<
<dd>"Autonomic Network": A network according to <xref target="I-D.ietf-a /dt>
nima-reference-model" format="default"/>. <dd pn="section-2-4.26">An information field in the <xref target="domcer
Its main components are ANI, Autonomic Functions and Intent. t-def" format="none" sectionFormat="of" derivedContent="">ACP certificate</xref>
in which the following ACP-relevant information is encoded: the ACP domain name
, the ACP IPv6 address of the node, and optional additional role attributes abou
t the node. </dd>
<dt anchor="an-def" pn="section-2-4.27">AN:</dt>
<dd pn="section-2-4.28">Autonomic Network. A network according to <xref
target="RFC8993" format="default" sectionFormat="of" derivedContent="RFC8993"/>.
Its main components are <xref target="ani-def" format="none" section
Format="of" derivedContent="">ANI</xref>, <xref target="af-def" format="none" se
ctionFormat="of" derivedContent="">autonomic functions</xref>, and <xref target=
"intent-def" format="none" sectionFormat="of" derivedContent="">Intent</xref>.
</dd> </dd>
<dt>(AN) Domain Name:</dt> <dt pn="section-2-4.29">(AN) Domain Name:</dt>
<dd>An FQDN (Fully Qualified Domain Name) in the acp-node-name of the Do <dd pn="section-2-4.30">An FQDN (Fully Qualified Domain Name) in the acp
main Certificate. See <xref target="domcert-acpinfo" format="default"/>. -node-name of the domain certificate. See <xref target="domcert-acpinfo" format
="default" sectionFormat="of" derivedContent="Section 6.2.2"/>.
</dd> </dd>
<dt>ANI (nodes/network):</dt> <dt anchor="ani-def" pn="section-2-4.31">ANI (nodes/network):</dt>
<dd>"Autonomic Network Infrastructure". <dd pn="section-2-4.32">Autonomic Network Infrastructure.
The ANI is the infrastructure to enable Autonomic Networks. It incl The ANI is the infrastructure to enable <xref target="an-def" format
udes ACP, BRSKI and GRASP. ="none" sectionFormat="of" derivedContent="">Autonomic Networks</xref>. It incl
Every Autonomic Network includes the ANI, but not every ANI network udes ACP, BRSKI, and GRASP.
needs to include autonomic functions beyond the ANI (nor Intent). An ANI networ Every Autonomic Network includes the ANI, but not every ANI network
k without further autonomic functions can for example support secure zero-touch needs to include <xref target="af-def" format="none" sectionFormat="of" derivedC
(automated) bootstrap ontent="">autonomic functions</xref> beyond the ANI (nor <xref target="intent-de
and stable connectivity for SDN networks - see <xref target="RFC8368 f" format="none" sectionFormat="of" derivedContent="">Intent</xref>). An ANI ne
" format="default"/>. twork without further autonomic functions can, for example, support secure zero-
touch (automated) bootstrap
and stable connectivity for SDN networks, see <xref target="RFC8368"
format="default" sectionFormat="of" derivedContent="RFC8368"/>.
</dd> </dd>
<dt>ANIMA:</dt> <dt pn="section-2-4.33">ANIMA:</dt>
<dd>"Autonomic Networking Integrated Model and Approach". <dd pn="section-2-4.34">Autonomic Networking Integrated Model and Approa
ACP, BRSKI and GRASP are specifications of the IETF ANIMA working gr ch.
oup. ACP, BRSKI, and GRASP are specifications of the IETF ANIMA Working G
roup.
</dd> </dd>
<dt>ASA:</dt> <dt pn="section-2-4.35">ASA:</dt>
<dd>"Autonomic Service Agent". Autonomic software modules running on <dd pn="section-2-4.36">Autonomic Service Agent. Autonomic software mod
an ANI device. The components making up the ANI (BRSKI, ACP, GRASP) ules running on
are also described as ASAs. an <xref target="ani-def" format="none" sectionFormat="of" derivedCo
ntent="">ANI</xref> device. The components making up the ANI (BRSKI, ACP, and G
RASP) are also described as ASAs.
</dd> </dd>
<dt>Autonomic Function:</dt> <dt anchor="af-def" pn="section-2-4.37">autonomic function:</dt>
<dd>A function/service in an Autonomic Network (AN) <dd pn="section-2-4.38">A function and/or service in an Autonomic Networ
composed of one or more ASA across one or more ANI nodes. k (AN)
composed of one or more ASAs across one or more ANI nodes.
</dd> </dd>
<dt>BRSKI:</dt> <dt pn="section-2-4.39">BRSKI:</dt>
<dd>"Bootstrapping Remote Secure Key Infrastructures" <dd pn="section-2-4.40">Bootstrapping Remote Secure Key Infrastructure
(<xref target="I-D.ietf-anima-bootstrapping-keyinfra" format="defaul <xref target="RFC8995" format="default" sectionFormat="of" derivedCo
t"/>. A protocol extending EST to ntent="RFC8995"/>. A protocol extending <xref target="est-def" format="none" se
enable secure zero-touch bootstrap in conjunction with ACP. ANI nod ctionFormat="of" derivedContent="">EST</xref> to
es use ACP, BRSKI and GRASP. enable secure zero-touch bootstrap in conjunction with ACP. ANI nod
es use ACP, BRSKI, and GRASP.
</dd> </dd>
<dt>CA:</dt> <dt anchor="ca-def" pn="section-2-4.41">CA:</dt>
<dd anchor="ca-def">"Certification Authority". An entity that issues dig <dd pn="section-2-4.42">Certification Authority. An entity that issues d
ital certificates. A CA uses its private key to sign the certificates it issues. igital certificates. A CA uses its private key to sign the certificates it issue
Relying parties use the public key in the CA certificate to validate the signat s. Relying parties use the public key in the CA certificate to validate the sign
ure.</dd> ature.</dd>
<dt>CRL:</dt> <dt pn="section-2-4.43">CRL:</dt>
<dd>"Certificate Revocation List". A list of revoked certificates. Requi <dd pn="section-2-4.44">Certificate Revocation List. A list of revoked c
red to revoke certificates before their lifetime expires. ertificates is required to revoke certificates before their lifetime expires.
</dd> </dd>
<dt>Data-Plane:</dt> <dt pn="section-2-4.45">data plane:</dt>
<dd>The counterpoint to the ACP VRF in an ACP node: forwarding of user t <dd pn="section-2-4.46">The counterpoint to the ACP <xref target="vrf-de
raffic and f" format="none" sectionFormat="of" derivedContent="">VRF</xref> in an ACP node:
in non-autonomous nodes/networks also any non-autonomous control and the forwarding of user traffic
/or management plane functions. in non-autonomous nodes and/or networks and also any non-autonomous
In a fully Autonomic Network node, the Data-Plane is managed autonom control and/or management plane functions.
ically via Autonomic In a fully <xref target="an-def" format="none" sectionFormat="of" de
Functions and Intent. See <xref target="intro" format="default"/> fo rivedContent="">Autonomic Network</xref> node, the data plane is managed autonom
r more detailed explanations. ically via <xref target="af-def" format="none" sectionFormat="of" derivedContent
="">autonomic
functions</xref> and <xref target="intent-def" format="none" section
Format="of" derivedContent="">Intent</xref>. See <xref target="intro" format="de
fault" sectionFormat="of" derivedContent="Section 1"/> for more details.
</dd> </dd>
<dt>device:</dt> <dt pn="section-2-4.47">device:</dt>
<dd>A physical system, or physical node.</dd> <dd pn="section-2-4.48">A physical system or physical node.</dd>
<dt>Enrollment:</dt> <dt anchor="enrollment-def" pn="section-2-4.49">enrollment:</dt>
<dd>The process through which a node authenticates itself to a <dd pn="section-2-4.50">The process by which a node authenticates itself
network with an initial identity, which is often called IDevID certi to a
ficate, and acquires from the network network with an initial identity, which is often called an <xref tar
a network specific identity, which is often called LDevID certificat get="idevid-def" format="none" sectionFormat="of" derivedContent="">Initial Devi
e, and certificates of one or more Trust Anchor(s). ce IDentity (IDevID)</xref> certificate, and acquires from the network
In the ACP, the LDevID certificate is called the ACP certificate. a network-specific identity, which is often called an <xref target="
ldevid" format="none" sectionFormat="of" derivedContent="">LDevID</xref> certifi
cate, and certificates of one or more <xref target="ta-def" format="none" sectio
nFormat="of" derivedContent="">trust anchor(s)</xref>.
In the ACP, the LDevID certificate is called the <xref target="domce
rt-def" format="none" sectionFormat="of" derivedContent="">ACP certificate</xref
>.
</dd> </dd>
<dt>EST:</dt> <dt anchor="est-def" pn="section-2-4.51">EST:</dt>
<dd>"Enrollment over Secure Transport" (<xref target="RFC7030" format="d <dd pn="section-2-4.52">Enrollment over Secure Transport <xref target="R
efault"/>). IETF FC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/>. IETF
standard-track protocol for enrollment of a node with an LDevID cert Standards Track protocol for enrollment of a node with an <xref targ
ificate. BRSKI is based on EST. et="ldevid" format="none" sectionFormat="of" derivedContent="">LDevID</xref> cer
tificate. BRSKI is based on EST.
</dd> </dd>
<dt>GRASP:</dt> <dt pn="section-2-4.53">GRASP:</dt>
<dd>"Generic Autonomic Signaling Protocol". An extensible signaling <dd pn="section-2-4.54">GeneRic Autonomic Signaling Protocol. An extens
ible signaling
protocol required by the ACP for ACP neighbor discovery.</dd> protocol required by the ACP for ACP neighbor discovery.</dd>
<dt/> <dt pn="section-2-4.55"/>
<dd>The ACP also provides the <dd pn="section-2-4.56">The ACP also provides the
"security and transport substrate" for the "ACP instance of GRASP". This instance "security and transport substrate" for the "ACP instance of GRASP". This instance
of GRASP runs across the ACP secure channels to support BRSKI and ot of GRASP runs across the ACP secure channels to support BRSKI and ot
her NOC/OAM or her NOC and/or OAM or
Autonomic Functions. See <xref target="I-D.ietf-anima-grasp" format <xref target="af-def" format="none" sectionFormat="of" derivedConten
="default"/>. t="">autonomic functions</xref>. See <xref target="RFC8990" format="default" se
ctionFormat="of" derivedContent="RFC8990"/>.
</dd> </dd>
<dt>IDevID:</dt> <dt anchor="idevid-def" pn="section-2-4.57">IDevID:</dt>
<dd>An "Initial Device IDentity" X.509 certificate installed by <dd pn="section-2-4.58">An Initial Device IDentity X.509 certificate ins
the vendor on new equipment. Contains information that establishes talled by
the identity of the the vendor on new equipment. The IDevID certificate contains inform
node in the context of its vendor/manufacturer such as device model/ ation that establishes the identity of the
type node in the context of its vendor and/or manufacturer such as device
and serial number. See <xref target="AR8021" format="default"/>. Th model and/or type
e IDevID certificate cannot be used as a node identifier for the and serial number. See <xref target="AR8021" format="default" secti
onFormat="of" derivedContent="AR8021"/>. The IDevID certificate cannot be used a
s a node identifier for the
ACP because they are not provisioned by the owner of the network, so they can ACP because they are not provisioned by the owner of the network, so they can
not directly indicate an ACP domain they belong to. not directly indicate an ACP domain they belong to.
</dd> </dd>
<dt>in-band (management/signaling):</dt> <dt anchor="in-band-def" pn="section-2-4.59">in-band (as in management o
<dd anchor="in-band-def"> r signaling):</dt>
<dd pn="section-2-4.60">
In-band management traffic and/or control plane signaling uses the s ame network In-band management traffic and/or control plane signaling uses the s ame network
resources such as routers/switches and network links that it manages /controls. resources such as routers and/or switches and network links that it manages and/or controls.
In-band is the standard management and signaling mechanism in IP net works. In-band is the standard management and signaling mechanism in IP net works.
Compared to <xref target="out-of-band-def" format="none">-&gt;"out-o Compared to <xref target="out-of-band-def" format="none" sectionForm
f-band"</xref> it at="of" derivedContent="">out-of-band</xref>, the in-band mechanism
requires no additional physical resources, but introduces potentiall requires no additional physical resources, but it introduces potenti
y circular ally circular
dependencies for its correct operations. dependencies for its correct operations.
See <xref target="intro" format="none">-&gt;"introduction"</xref>. See <xref target="intro" format="default" sectionFormat="of" derived Content="Section 1"/>.
</dd> </dd>
<dt>Intent:</dt> <dt anchor="intent-def" pn="section-2-4.61">Intent:</dt>
<dd>Policy language of an autonomic network according to <xref target="I <dd pn="section-2-4.62">The policy language of an Autonomic Network acco
-D.ietf-anima-reference-model" format="default"/>. rding to <xref target="RFC8993" format="default" sectionFormat="of" derivedConte
nt="RFC8993"/>.
</dd> </dd>
<dt>Loopback interface:</dt> <dt pn="section-2-4.63">Loopback interface:</dt>
<dd>See <dd pn="section-2-4.64">See
<xref target="acp-loopback-def" format="none">-&gt;"ACP Loopback int <xref target="acp-loopback-def" format="none" sectionFormat="of" der
erface"</xref>. ivedContent="">ACP loopback interface</xref>.
</dd> </dd>
<dt>LDevID:</dt> <dt anchor="ldevid" pn="section-2-4.65">LDevID:</dt>
<dd>A "Local Device IDentity" is an X.509 certificate installed during <dd pn="section-2-4.66">A Local Device IDentity is an X.509 certificate
"enrollment". The Domain Certificate used by the ACP is an LDevID c installed during
ertificate. See <xref target="AR8021" format="default"/>. <xref target="enrollment-def" format="none" sectionFormat="of" deriv
edContent="">enrollment</xref>. The <xref target="domcert-def" format="none" se
ctionFormat="of" derivedContent="">domain certificate</xref> used by the ACP is
an LDevID certificate. See <xref target="AR8021" format="default" sectionFormat
="of" derivedContent="AR8021"/>.
</dd> </dd>
<dt>Management:</dt> <dt pn="section-2-4.67">management:</dt>
<dd>Used in this document as another word for <xref target="OAM" format= <dd pn="section-2-4.68">Used in this document as another word for <xref
"none">-&gt;"OAM"</xref>. target="OAM" format="none" sectionFormat="of" derivedContent="">OAM</xref>.
</dd> </dd>
<dt>MASA (service):</dt> <dt pn="section-2-4.69">MASA (service):</dt>
<dd>"Manufacturer Authorized Signing Authority". A vendor/manufacturer <dd pn="section-2-4.70">Manufacturer Authorized Signing Authority. A ve
ndor and/or manufacturer
or delegated cloud service on the Internet used as part of the BRSKI protocol. or delegated cloud service on the Internet used as part of the BRSKI protocol.
</dd> </dd>
<dt>MIC:</dt> <dt pn="section-2-4.71">MIC:</dt>
<dd>"Manufacturer Installed Certificate". This is another word to descr <dd pn="section-2-4.72">Manufacturer Installed Certificate. A synonym f
ibe an IDevID in referenced materials. This term is not used in this document. or an <xref target="idevid-def" format="none" sectionFormat="of" derivedContent=
"">IDevID</xref> in referenced materials. This term is not used in this document
.
</dd> </dd>
<dt>native interface:</dt> <dt pn="section-2-4.73">native interface:</dt>
<dd>Interfaces existing on a node without configuration of the already r <dd pn="section-2-4.74">Interfaces existing on a node without configurat
unning node. On physical nodes these are usually physical interfaces; on virtua ion of the already running node. On physical nodes, these are usually physical
l nodes their equivalent. interfaces; on virtual nodes, their equivalent.
</dd> </dd>
<dt>NOC:</dt> <dt pn="section-2-4.75">NOC:</dt>
<dd>Network Operations Center. <dd pn="section-2-4.76">Network Operations Center.
</dd> </dd>
<dt>node:</dt> <dt pn="section-2-4.77">node:</dt>
<dd>A system supporting the ACP according to this document. Can be virt <dd pn="section-2-4.78">A system supporting the ACP according to this do
ual or physical. Physical nodes are called devices. cument. A node can be virtual or physical. Physical nodes are called devices.
</dd> </dd>
<dt>Node-ID:</dt> <dt anchor="node-id" pn="section-2-4.79">Node-ID:</dt>
<dd anchor="node-id"> <dd pn="section-2-4.80">
The identifier of an ACP node inside that ACP. It is the last 64 (se The identifier of an ACP node inside that ACP. It is either the last
e <xref target="zone-scheme" format="default"/>) or 78-bits (see <xref target="V 64 bits (see <xref target="zone-scheme" format="default" sectionFormat="of" der
long" format="default"/>) of the ACP address. ivedContent="Section 6.11.3"/>) or 78 bits (see <xref target="Vlong" format="def
ault" sectionFormat="of" derivedContent="Section 6.11.5"/>) of the ACP address.
</dd> </dd>
<dt>OAM:</dt> <dt anchor="OAM" pn="section-2-4.81">OAM:</dt>
<dd anchor="OAM">Operations, Administration and Management. Includes Net <dd pn="section-2-4.82">Operations, Administration, and Management. Incl
work Monitoring. udes network monitoring.
</dd> </dd>
<dt>Operational Technology (OT):</dt> <dt anchor="ot" pn="section-2-4.83">Operational Technology (OT):</dt>
<dd anchor="ot"><eref target="https://en.wikipedia.org/wiki/Operational_ <dd pn="section-2-4.84">
Technology"/>:
"The hardware and software dedicated to detecting or causing change s "The hardware and software dedicated to detecting or causing change s
in physical processes through direct monitoring and/or control of physical in physical processes through direct monitoring and/or control of physical
devices such as valves, pumps, etc.". OT networks are today in mos t cases devices such as valves, pumps, etc." <xref target="OP-TECH" format ="default" sectionFormat="of" derivedContent="OP-TECH"/>. In most cases today, O T networks are
well separated from Information Technology (IT) networks. well separated from Information Technology (IT) networks.
</dd> </dd>
<dt>out-of-band (management) network:</dt> <dt anchor="out-of-band-def" pn="section-2-4.85">out-of-band (management
<dd anchor="out-of-band-def"> ) network:</dt>
<dd pn="section-2-4.86">
An out-of-band network is a secondary network An out-of-band network is a secondary network
used to manage a primary network. The equipment of the primary netw ork is connected to used to manage a primary network. The equipment of the primary netw ork is connected to
the out-of-band network via dedicated management ports on the prima ry network equipment. the out-of-band network via dedicated management ports on the prima ry network equipment.
Serial (console) management ports were historically most common, hi Serial (console) management ports were historically most common; ho
gher end network equipment wever, higher-end network equipment
now also has ethernet ports dedicated only for management. An out-o now also has Ethernet ports dedicated only to management. An out-of
f-band network provides -band network provides
management access to the primary network independent of the configu ration state of the primary management access to the primary network independent of the configu ration state of the primary
network. See <xref target="intro" format="none">-&gt;"Introduction network. See <xref target="intro" format="default" sectionFormat="
"</xref></dd> of" derivedContent="Section 1"/>.</dd>
<dt>(virtual) out-of-band network:</dt> <dt anchor="virtual-out-of-band-def" pn="section-2-4.87">out-of-band net
<dd anchor="virtual-out-of-band-def"> work, virtual:</dt>
<dd pn="section-2-4.88">
The ACP can be called a virtual out-of-band network for management and control The ACP can be called a virtual out-of-band network for management and control
because it attempts to provide the benefits of a (physical) because it attempts to provide the benefits of a (physical)
<xref target="out-of-band-def" format="none">-&gt;"out-of-band netw <xref target="out-of-band-def" format="none" sectionFormat="of" der
ork"</xref> ivedContent="">out-of-band network</xref>
even though it is physically carried <xref target="in-band-def" for even though it is physically carried <xref target="in-band-def" for
mat="none">-&gt;"in-band"</xref>. mat="none" sectionFormat="of" derivedContent="">in-band</xref>.
See <xref target="intro" format="none">-&gt;"introduction"</xref>. See <xref target="intro" format="default" sectionFormat="of" derive
dContent="Section 1"/>.
</dd> </dd>
<dt>root CA:</dt> <dt pn="section-2-4.89">root CA:</dt>
<dd>"root Certification Authority". A <xref target="ca-def" format="none <dd pn="section-2-4.90">root Certification Authority. A <xref target="ca
">-&gt;"CA"</xref> for which the root CA Key update procedures of <xref target=" -def" format="none" sectionFormat="of" derivedContent="">CA</xref> for which the
RFC7030" format="default"/>, Section 4.4 can be applied. root CA key update
procedures of <xref target="RFC7030" sectionFormat="comma" section="4.4"
format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-4.4" de
rivedContent="RFC7030"/>, can be applied.
</dd> </dd>
<dt>RPL:</dt> <dt pn="section-2-4.91">RPL:</dt>
<dd>"IPv6 Routing Protocol for Low-Power and Lossy Networks". The routi <dd pn="section-2-4.92">IPv6 Routing Protocol for Low-Power and Lossy Ne
ng protocol used in the ACP. See <xref target="RFC6550" format="default"/>. tworks. The routing protocol used in the ACP. See <xref target="RFC6550" format
="default" sectionFormat="of" derivedContent="RFC6550"/>.
</dd> </dd>
<dt>(ACP/ANI/BRSKI) Registrar:</dt> <dt pn="section-2-4.93">registrar (ACP, ANI/BRSKI):</dt>
<dd> <dd pn="section-2-4.94">
An ACP registrar is an entity (software and/or person) that is orche An ACP registrar is an entity (software and/or person) that orchestr
strating ates
the enrollment of ACP nodes with the ACP certificate. ANI nodes use the <xref target="enrollment-def" format="none" sectionFormat="of" d
erivedContent="">enrollment</xref> of ACP nodes with the <xref target="domcert-d
ef" format="none" sectionFormat="of" derivedContent="">ACP certificate</xref>. A
NI nodes use
BRSKI, so ANI registrars are also called BRSKI registrars. For non-A NI ACP nodes, BRSKI, so ANI registrars are also called BRSKI registrars. For non-A NI ACP nodes,
the registrar mechanisms are undefined by this document. See <xref t arget="acp-registrars" format="default"/>. the registrar mechanisms are not defined in this document. See <xref target="acp-registrars" format="default" sectionFormat="of" derivedContent="Sec tion 6.11.7"/>.
Renewal and other maintenance (such as revocation) of ACP certificat es Renewal and other maintenance (such as revocation) of ACP certificat es
may be performed by other entities than registrars. EST must be supp may be performed by entities other than registrars. EST must be supp
orted for orted for
ACP certificate renewal (see <xref target="domcert-maint" format="de ACP certificate renewal (see <xref target="domcert-maint" format="de
fault"/>). BRSKI fault" sectionFormat="of" derivedContent="Section 6.2.5"/>). BRSKI
is an extension of EST, so ANI/BRSKI registrars can easily support A CP domain is an extension of EST, so ANI/BRSKI registrars can easily support A CP domain
certificate renewal in addition to initial enrollment. certificate renewal in addition to initial enrollment.
</dd> </dd>
<dt>RPI:</dt> <dt pn="section-2-4.95">RPI:</dt>
<dd>"RPL Packet Information". Network extension headers for use with the <dd pn="section-2-4.96">RPL Packet Information. Network extension header
<xref target="rpl-def" format="none">-&gt;"RPL"</xref> routing proto s for use with
cols. <xref target="rpl-def" format="none" sectionFormat="of" derivedConte
Not used with RPL in the ACP. See <xref target="rpl-Data-Plane" form nt="">RPL</xref>.
at="default"/>. Not used with RPL in the ACP. See <xref target="rpl-Data-Plane" form
at="default" sectionFormat="of" derivedContent="Section 6.12.1.13"/>.
</dd> </dd>
<dt>RPL:</dt> <dt anchor="rpl-def" pn="section-2-4.97">RPL:</dt>
<dd anchor="rpl-def">"Routing Protocol for Low-Power and Lossy Networks" <dd pn="section-2-4.98">Routing Protocol for Low-Power and Lossy Network
. The routing protocol used in the ACP. See <xref target="routing" format="defa s. The routing protocol used in the ACP. See <xref target="routing" format="def
ult"/>. ault" sectionFormat="of" derivedContent="Section 6.12"/>.
</dd> </dd>
<dt>sUDI:</dt> <dt anchor="sudi" pn="section-2-4.99">sUDI:</dt>
<dd>"secured Unique Device Identifier". This is another word to describ <dd pn="section-2-4.100">secured Unique Device Identifier. This is a sy
e an IDevID in referenced material. This term is not used in this document. nonym of IDevID in referenced material. This term is not used in this document.
</dd> </dd>
<dt>TA:</dt> <dt anchor="ta-def" pn="section-2-4.101">TA:</dt>
<dd anchor="ta-def">"Trust Anchor". A Trust Anchor is an entity that is <dd pn="section-2-4.102">Trust Anchor. A TA is an entity that
trusted for the purpose of certificate validation. Trust Anchor Information such is trusted for the purpose of certificate validation. TA
as self-signed certificate(s) of the Trust Anchor is configured into the ACP no information such as self-signed certificate(s) of the TA is
de as part of Enrollment. See <xref target="RFC5280" format="default"/>, Section configured into the ACP node as part of <xref target="enrollment-def" for
6.1.1. mat="none" sectionFormat="of" derivedContent="">enrollment</xref>. See <xref tar
get="RFC5280" sectionFormat="comma" section="6.1.1" format="default" derivedLink
="https://rfc-editor.org/rfc/rfc5280#section-6.1.1" derivedContent="RFC5280"/>.
</dd> </dd>
<dt>UDI:</dt> <dt pn="section-2-4.103">UDI:</dt>
<dd>"Unique Device Identifier". In the context of this document unsecur <dd pn="section-2-4.104">Unique Device Identifier. In the context of th
ed is document, unsecured
identity information of a node typically consisting of at least devi identity information of a node typically consists of at least a devi
ce model/type and ce model and/or type and a
serial number, often in a vendor specific format. See sUDI and LDev serial number, often in a vendor-specific format. See <xref target=
ID. "sudi" format="none" sectionFormat="of" derivedContent="">sUDI</xref> and <xref
target="ldevid" format="none" sectionFormat="of" derivedContent="">LDevID</xref>
.
</dd> </dd>
<dt>ULA: (Global ID prefix)</dt> <dt anchor="ula-def" pn="section-2-4.105">ULA (Global ID prefix):</dt>
<dd> <dd pn="section-2-4.106">
A "Unique Local Address" (ULA) is an IPv6 A Unique Local Address is an IPv6
address in the block fc00::/7, defined in [RFC4193]. ULA is the address in the block fc00::/7, defined in "<xref target="RFC4193" fo
IPv6 successor of the IPv4 private address space (<xref target="RFC1 rmat="title" sectionFormat="of" derivedContent="Unique Local IPv6 Unicast Addres
918" format="default"/>). ses"/>" <xref target="RFC4193" format="default" sectionFormat="of" derivedConten
ULA have important differences over IPv4 private addresses that t="RFC4193"/>. ULA is the
are beneficial for and exploited by the ACP, such as the Locally IPv6 successor of the IPv4 private address space ("<xref target="RFC
Assigned Global ID prefix, which are the first 48-bits of a ULA 1918" format="title" sectionFormat="of" derivedContent="Address Allocation for P
address <xref target="RFC4193" format="default"/>, section 3.2.1. rivate Internets"/>" <xref target="RFC1918" format="default" sectionFormat="of"
In this document this prefix is abbreviated as "ULA prefix". derivedContent="RFC1918"/>).
ULAs have important differences over IPv4 private addresses that
are beneficial for and exploited by the ACP, such as the locally
assigned Global ID prefix, which is the first 48 bits of a ULA
address <xref target="RFC4193" sectionFormat="comma" section="3.2.1"
format="default" derivedLink="https://rfc-editor.org/rfc/rfc4193#section-3.2.1"
derivedContent="RFC4193"/>.
In this document, this prefix is abbreviated as "ULA prefix".
</dd> </dd>
<dt>(ACP) VRF:</dt> <dt anchor="vrf-def" pn="section-2-4.107">(ACP) VRF:</dt>
<dd>The ACP is modeled in this document as a "Virtual Routing and Forwar <dd pn="section-2-4.108">The ACP is modeled in this document as a Virtua
ding" instance (VRF). This means that it is based on a "virtual router" consisti l Routing and Forwarding instance. This means that it is based on a "virtual rou
ng of a separate IPv6 forwarding table to which the ACP virtual interfaces are a ter" consisting of a separate IPv6 forwarding table to which the ACP virtual int
ttached and an associated IPv6 routing table separate from the Data-Plane. Unlik erfaces are attached and an associated IPv6 routing table separate from the data
e the VRFs on MPLS/VPN-PE (<xref target="RFC4364" format="default"/>) or LISP XT plane. Unlike the VRFs on MPLS/VPN Provider Edge ("<xref target="RFC4364" forma
R (<xref target="RFC6830" format="default"/>), the ACP VRF does not have any spe t="title" sectionFormat="of" derivedContent="BGP/MPLS IP Virtual Private Network
cial "core facing" functionality or routing/mapping protocols shared across mult s (VPNs)"/>" <xref target="RFC4364" format="default" sectionFormat="of" derivedC
iple VRFs. In vendor products a VRF such as the ACP-VRF may also be referred to ontent="RFC4364"/>) or LISP xTR ("<xref target="RFC6830" format="title" sectionF
as a so called VRF-lite. ormat="of" derivedContent="The Locator/ID Separation Protocol (LISP)"/>" <xref t
arget="RFC6830" format="default" sectionFormat="of" derivedContent="RFC6830"/>),
the ACP VRF does not have any special "core facing" functionality or routing an
d/or mapping protocols shared across multiple VRFs. In vendor products, a VRF su
ch as the ACP VRF may also be referred to as a VRF-lite.
</dd> </dd>
<dt>(ACP) Zone:</dt> <dt pn="section-2-4.109">(ACP) Zone:</dt>
<dd>An ACP zone is a set of ACP nodes using the same zone field value in <dd pn="section-2-4.110">An ACP zone is a set of ACP nodes using the sam
their ACP address according to <xref target="zone-scheme" format="default"/>. Z e zone field value in their ACP address according to <xref target="zone-scheme"
ones are a mechanism to support structured addressing of ACP addresses within th format="default" sectionFormat="of" derivedContent="Section 6.11.3"/>. Zones are
e same /48-bit ULA prefix. a mechanism to support structured addressing of ACP addresses within the same /
48 ULA prefix.
</dd> </dd>
</dl> </dl>
<t> <t indent="0" pn="section-2-5">
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
" D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
in this document are to be interpreted as described in BCP 14 [RFC2119],[RFC817 OT RECOMMENDED</bcp14>",
4] "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
when, and only when, they appear in all capitals, as shown here. be interpreted as
</t> 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>
<section anchor="usage" numbered="true" toc="default"> <section anchor="usage" numbered="true" toc="include" removeInRFC="false" pn
<name>Use Cases for an Autonomic Control Plane (Informative)</name> ="section-3">
<t>This section summarizes the use cases that are intended to be supported <name slugifiedName="name-use-cases-for-an-autonomic-">Use Cases for an Au
by an ACP. To understand how these are derived from and relate to the larger se tonomic Control Plane (Informative)</name>
t of use cases for autonomic networks, please refer to <xref target="RFC8316" fo <t indent="0" pn="section-3-1">This section summarizes the use cases that
rmat="default"/>.</t> are intended to be supported by an ACP. To understand how these are derived from
<section anchor="infrastructure" numbered="true" toc="default"> and relate to the larger set of use cases for Autonomic Networks, please refer
<name>An Infrastructure for Autonomic Functions</name> to "<xref target="RFC8316" format="title" sectionFormat="of" derivedContent="Aut
<t>Autonomic Functions need a stable infrastructure to run on, and all a onomic Networking Use Case for Distributed Detection of Service Level Agreement
utonomic functions should use the same infrastructure to minimize the complexity (SLA) Violations"/>" <xref target="RFC8316" format="default" sectionFormat="of"
of the network. In this way, there is only need for a single discovery mechani derivedContent="RFC8316"/>.</t>
sm, a single security mechanism, and single instances of other processes that di <section anchor="infrastructure" numbered="true" toc="include" removeInRFC
stributed functions require.</t> ="false" pn="section-3.1">
<name slugifiedName="name-an-infrastructure-for-auton">An Infrastructure
for Autonomic Functions</name>
<t indent="0" pn="section-3.1-1">Autonomic functions need a stable infra
structure to run on, and all autonomic functions should use the same infrastruct
ure to minimize the complexity of the network. In this way, there is only need
for a single discovery mechanism, a single security mechanism, and single instan
ces of other processes that distributed functions require.</t>
</section> </section>
<!-- infrastructure --> <section anchor="secure-bootstrap" numbered="true" toc="include" removeInR
<section anchor="secure-bootstrap" numbered="true" toc="default"> FC="false" pn="section-3.2">
<name>Secure Bootstrap over a not configured Network</name> <name slugifiedName="name-secure-bootstrap-over-an-un">Secure Bootstrap
<t>Today, bootstrapping a new node typically requires all nodes between over an Unconfigured Network</name>
a controlling node such as an SDN controller ("Software Defined Networking", see <t indent="0" pn="section-3.2-1">Today, bootstrapping a new node typical
<xref target="RFC7426" format="default"/>) and the new node to be completely an ly requires all nodes between a controlling node such as an SDN controller (see
d correctly addressed, configured and secured. Bootstrapping and configuration <xref target="RFC7426" format="default" sectionFormat="of" derivedContent="RFC74
of a network happens in rings around the controller - configuring each ring of d 26"/>) and the new node to be completely and correctly addressed, configured, an
evices before the next one can be bootstrapped. Without console access (for exa d secured. Bootstrapping and configuration of a network happens in rings around
mple through an out-of-band network) it is not possible today to make devices se the controller -- configuring each ring of devices before the next one can be b
curely reachable before having configured the entire network leading up to them. ootstrapped. Without console access (for example, through an out-of-band networ
</t> k), it is not possible today to make devices securely reachable before having co
<t>With the ACP, secure bootstrap of new devices and whole new networks nfigured the entire network leading up to them.</t>
can happen without requiring any configuration of unconfigured devices along the <t indent="0" pn="section-3.2-2">With the ACP, secure bootstrap of new d
path: As long as all devices along the path support ACP and a zero-touch bootst evices and whole new networks can happen without requiring any configuration of
rap mechanism such as BRSKI, the ACP across a whole network of unconfigured devi unconfigured devices along the path. As long as all devices along the path suppo
ces can be brought up without operator/provisioning intervention. The ACP also p rt ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP across a whol
rovides additional security for any bootstrap mechanism, because it can provide e network of unconfigured devices can be brought up without operator and/or prov
encrypted discovery (via ACP GRASP) of registrars or other bootstrap servers by isioning intervention. The ACP also offers additional security for any bootstrap
bootstrap proxies connecting to nodes that are to be bootstrapped and the ACP en mechanism because it can provide the encrypted discovery (via ACP GRASP) of reg
cryption hides the identities of the communicating entities (pledge and registra istrars or other bootstrap servers by bootstrap proxies connecting to nodes that
r), making it more difficult to learn which network node might be attackable. Th are to be bootstrapped. The ACP encryption hides the identities of the communic
e ACP certificate can also be used to end-to-end encrypt the bootstrap communica ating entities (pledge and registrar), making it more difficult to learn which n
tion between such proxies and server. Note that bootstrapping here includes not etwork node might be attackable. The ACP certificate can also be used to end-to-
only the first step that can be provided by BRSKI (secure keys), but also later end encrypt the bootstrap communication between such proxies and server. Note th
stages where configuration is bootstrapped.</t> at bootstrapping here includes not only the first step that can be provided by B
RSKI (secure keys), but also later stages where configuration is bootstrapped.</
t>
</section> </section>
<!-- bootstrap --> <section anchor="reachability" numbered="true" toc="include" removeInRFC="
<section anchor="reachability" numbered="true" toc="default"> false" pn="section-3.3">
<name>Data-Plane Independent Permanent Reachability</name> <name slugifiedName="name-permanent-reachability-inde">Permanent Reachab
<t>Today, most critical control plane protocols and OAM protocols are us ility Independent of the Data Plane</name>
ing the Data-Plane of the network. This leads to often undesirable dependencies <t indent="0" pn="section-3.3-1">Today, most critical control plane prot
between control and OAM plane on one side and the Data-Plane on the other: Only ocols and OAM protocols use the data plane of the network. This leads to often
if the forwarding and control plane of the Data-Plane are configured correctly, undesirable dependencies between the control and OAM plane on one side and the d
will the Data-Plane and the OAM/control plane work as expected.</t> ata plane on the other: only if the forwarding and control plane of the data pla
<t>Data-Plane connectivity can be affected by errors and faults, for exa ne are configured correctly, will the data plane and the OAM and/or control plan
mple misconfigurations that make AAA (Authentication, Authorization and Accounti e work as expected.</t>
ng) servers unreachable or can lock an administrator out of a device; routing or <t indent="0" pn="section-3.3-2">Data plane connectivity can be affected
addressing issues can make a device unreachable; shutting down interfaces over by errors and faults. Examples include misconfigurations that make AAA (Authent
which a current management session is running can lock an admin irreversibly out ication, Authorization, and Accounting) servers unreachable or that can lock an
of the device. Traditionally only out-of-band access can help recover from suc administrator out of a device; routing or addressing issues can make a device un
h issues (such as serial console or ethernet management port).</t> reachable; and shutting down interfaces over which a current management session
<t>Data-Plane dependencies also affect applications in a Network Operati is running can lock an administrator irreversibly out of the device. Traditiona
ons Center (NOC) such as SDN controller applications: Certain network changes ar lly only out-of-band access via a serial console or Ethernet management port can
e today hard to implement, because the change itself may affect reachability of help recover from such issues.</t>
the devices. Examples are address or mask changes, routing changes, or security <t indent="0" pn="section-3.3-3">Data plane dependencies also affect app
policies. Today such changes require precise hop-by-hop planning.</t> lications in a NOC such as SDN controller applications: certain network changes
<t>Note that specific control plane functions for the Data-Plane often w are hard to implement today because the change itself may affect reachability of
ant to depend on forwarding of their packets via the Data-Plane: Aliveness and r the devices. Examples include address or mask changes, routing changes, or sec
outing protocol signaling packets across the Data-Plane to verify reachability a urity policies. Today such changes require precise, hop-by-hop planning.</t>
cross the Data-Plane, using IPv4 signaling packets for IPv4 routing vs. IPv6 sig <t indent="0" pn="section-3.3-4">Note that specific control plane functi
naling packets for IPv6 routing.</t> ons for the data plane often depend on the ability to forward their packets via
<t>Assuming appropriate implementation (see <xref target="general_addres the data plane: sending aliveness and routing protocol signaling packets across
sing" format="default"/> for more details), the ACP provides reachability that i the data plane to verify reachability, using IPv4 signaling packets for IPv4 rou
s independent of the Data-Plane. This allows the control plane and OAM plane to ting and IPv6 signaling packets for IPv6 routing.</t>
operate more robustly: <t indent="0" pn="section-3.3-5">Assuming appropriate implementation (se
</t> e <xref target="general_addressing" format="default" sectionFormat="of" derivedC
<ul spacing="compact"> ontent="Section 6.13.2"/> for more details), the ACP provides reachability that
<li>For management plane protocols, the ACP provides the functionality is independent of the data plane. This allows the control plane and OAM plane t
of a Virtual out-of-band (VooB) channel, by providing connectivity to all nodes o operate more robustly:
regardless of their Data-Plane configuration, routing and forwarding tables.</l </t>
i> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<li>For control plane protocols, the ACP allows their operation even w .3-6">
hen the Data-Plane is temporarily faulty, or during transitional events, such as <li pn="section-3.3-6.1">For management plane protocols, the ACP provi
routing changes, which may affect the control plane at least temporarily. This des the functionality of a Virtual out-of-Band (VooB) channel, by providing conn
is specifically important for autonomic service agents, which could affect Data ectivity to all nodes regardless of their data plane configuration, and routing
-Plane connectivity.</li> and forwarding tables.</li>
<li pn="section-3.3-6.2">For control plane protocols, the ACP allows t
heir operation even when the data plane is temporarily faulty, or during transit
ional events, such as routing changes, which may affect the control plane at lea
st temporarily. This is specifically important for autonomic service agents, wh
ich could affect data plane connectivity.</li>
</ul> </ul>
<t>The document <xref target="RFC8368" format="default">"Using Autonomic Control Plane for Stable Connectivity of Network OAM"</xref> explains this use case for the ACP in significantly more detail and explains how the ACP can be us ed in practical network operations.</t> <t indent="0" pn="section-3.3-7">The document <xref target="RFC8368" for mat="default" sectionFormat="of" derivedContent="RFC8368">"Using Autonomic Contr ol Plane for Stable Connectivity of Network OAM"</xref> explains this use case f or the ACP in significantly more detail and explains how the ACP can be used in practical network operations.</t>
</section> </section>
<!-- reachability -->
</section> </section>
<!-- usage --> <section anchor="requirements" numbered="true" toc="include" removeInRFC="fa
<section anchor="requirements" numbered="true" toc="default"> lse" pn="section-4">
<name>Requirements (Informative)</name> <name slugifiedName="name-requirements-informative">Requirements (Informat
<t>The following requirements were identified for the design of the ACP ba ive)</name>
sed on the above use-cases (<xref target="usage" format="default"/>). These requ <t indent="0" pn="section-4-1">The following requirements were identified
irements are informative. The ACP as specified in the normative parts of this do for the design of the ACP based on the above use cases (<xref target="usage" for
cument is meeting or exceeding these use-case requirements:</t> mat="default" sectionFormat="of" derivedContent="Section 3"/>). These requiremen
<ol type="ACP%d:" spacing="compact"> ts are informative. The ACP as specified in the normative parts of this document
<li>The ACP should provide robust connectivity: As far as possible, it s is meeting or exceeding these use case requirements:</t>
hould be independent of configured addressing, configuration and routing. Requi <ol type="ACP%d:" spacing="normal" indent="10" start="1" pn="section-4-2">
rements 2 and 3 build on this requirement, but also have value on their own.</li <li anchor="acp1" pn="section-4-2.1" derivedCounter="ACP1:">The ACP shou
> ld provide robust connectivity: as far as possible, it should be independent of
<li>The ACP must have a separate address space from the Data-Plane. Rea configured addressing, configuration, and routing. Requirements 2 and 3 build o
son: traceability, debug-ability, separation from Data-Plane, infrastructure sec n this requirement, but they also have value on their own.</li>
urity (filtering based on known address space).</li> <li pn="section-4-2.2" derivedCounter="ACP2:">The ACP must have a separa
<li>The ACP must use autonomically managed address space. Reason: easy te address space from the data plane. This separate address space provides trac
bootstrap and setup ("autonomic"); robustness (admin cannot break network easily eability, ease of debugging, separation from data plane, and infrastructure secu
). This document uses Unique Local Addresses (ULA) for this purpose, see <xref rity (filtering based on known address space).</li>
target="RFC4193" format="default"/>.</li> <li pn="section-4-2.3" derivedCounter="ACP3:">The ACP must use an autono
<li>The ACP must be generic, that is it must be usable by all the functi mically managed address space. An autonomically managed address space provides
ons and protocols of the ANI. Clients of the ACP must not be tied to a particul ease of bootstrap and setup ("autonomic"), and robustness (the administrator can
ar application or transport protocol.</li> not break network easily). This document uses ULA for this purpose, see <xref t
<li>The ACP must provide security: Messages coming through the ACP must arget="RFC4193" format="default" sectionFormat="of" derivedContent="RFC4193"/>.<
be authenticated to be from a trusted node, and it is very strongly > recommende /li>
d that they be encrypted.</li> <li anchor="acp4" pn="section-4-2.4" derivedCounter="ACP4:">The ACP must
be generic, that is, it must be usable by all the functions and protocols of th
e ANI. Clients of the ACP must not be tied to a particular application or trans
port protocol.</li>
<li pn="section-4-2.5" derivedCounter="ACP5:">The ACP must provide secur
ity: messages coming through the ACP must be authenticated to be from a trusted
node, and it is very strongly recommended that they be encrypted.</li>
</ol> </ol>
<t>Explanation for ACP4: In a fully autonomic network (AN), newly written <t indent="0" pn="section-4-3">The explanation for <xref target="acp4" for
ASAs could potentially all communicate exclusively via GRASP with each other, an mat="none" sectionFormat="of" derivedContent="">ACP4</xref> is as follows: in a
d if that was assumed to be the only requirement against the ACP, it would not n fully Autonomic Network (AN), all newly written ASAs could potentially communica
eed to provide IPv6 layer connectivity between nodes, but only GRASP connectivit te with each other exclusively via GRASP, and if that were the only requirement
y. Nevertheless, because ACP also intends to support non-AN networks, it is cruc for the ACP, it would not need to provide IPv6-layer connectivity between nodes,
ial to support IPv6 layer connectivity across the ACP to support any transport a but only GRASP connectivity. Nevertheless, because ACP also intends to support
nd application layer protocols.</t> non-autonomous networks, it is crucial to support IPv6-layer connectivity across
<t>The ACP operates hop-by-hop, because this interaction can be built on I the ACP to support any transport-layer and application-layer protocols.</t>
Pv6 link local addressing, which is autonomic, and has no dependency on configur <t indent="0" pn="section-4-4">The ACP operates hop-by-hop because this in
ation (requirement 1). It may be necessary to have ACP connectivity across non- teraction can be built on IPv6 link-local addressing, which is autonomic, and ha
ACP nodes, for example to link ACP nodes over the general Internet. This is pos s no dependency on configuration (requirement <xref target="acp1" format="none"
sible, but introduces a dependency against stable/resilient routing over the non sectionFormat="of" derivedContent="">ACP1</xref>). It may be necessary to have
-ACP hops (see <xref target="remote-acp-neighbors" format="default"/>).</t> ACP connectivity across non-ACP nodes, for example, to link ACP nodes over the g
eneral Internet. This is possible, but it introduces a dependency on stable and
/or resilient routing over the non-ACP hops (see <xref target="remote-acp-neighb
ors" format="default" sectionFormat="of" derivedContent="Section 8.2"/>).</t>
</section> </section>
<!-- requirements --> <section anchor="overview" numbered="true" toc="include" removeInRFC="false"
<section anchor="overview" numbered="true" toc="default"> pn="section-5">
<name>Overview (Informative)</name> <name slugifiedName="name-overview-informative">Overview (Informative)</na
<t>When a node has an ACP certificate (see <xref target="acp-certificates" me>
format="default"/>) and is enabled to bring up the ACP (see <xref target="node- <t indent="0" pn="section-5-1">When a node has an ACP certificate (see <xr
enable" format="default"/>), it will create its ACP without any configuration as ef target="acp-certificates" format="default" sectionFormat="of" derivedContent=
follows. For details, see <xref target="self-creation" format="default"/> and f "Section 6.2.1"/>) and is enabled to bring up the ACP (see <xref target="node-en
urther sections: able" format="default" sectionFormat="of" derivedContent="Section 9.3.5"/>), it
</t> will create its ACP without any configuration as follows. For details, see <xref
<ol type="1" spacing="compact"> target="self-creation" format="default" sectionFormat="of" derivedContent="Sect
<li>The node creates a VRF instance, or a similar virtual context for th ion 6"/> and following sections:
e ACP.</li> </t>
<li>The node assigns its ULA IPv6 address (prefix) (see <xref target="ad <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-5-2"
dressing" format="default"/> which is learned from the acp-node-name (see <xref >
target="domcert-acpinfo" format="default"/>) of its ACP certificate (see <xref t <li pn="section-5-2.1" derivedCounter="1.">The node creates a VRF instan
arget="acp-certificates" format="default"/>) to an ACP loopback interface (see < ce or a similar virtual context for the ACP.</li>
xref target="addressing" format="default"/>) and connects this interface into th <li pn="section-5-2.2" derivedCounter="2.">The node assigns its ULA IPv6
e ACP VRF.</li> address (prefix) (see <xref target="addressing" format="default" sectionFormat=
<li>The node establishes a list of candidate peer adjacencies and candid "of" derivedContent="Section 6.11"/>), which is learned from the acp-node-name (
ate channel types to try for the adjacency. This is automatic for all candidate see <xref target="domcert-acpinfo" format="default" sectionFormat="of" derivedCo
link-local adjacencies, see <xref target="discovery-grasp" format="default"/> ac ntent="Section 6.2.2"/>) of its ACP certificate (see <xref target="acp-certifica
ross all native interfaces (see <xref target="if-enable-auto" format="default"/> tes" format="default" sectionFormat="of" derivedContent="Section 6.2.1"/>), to a
). If a candidate peer is discovered via multiple interfaces, this will result i n ACP loopback interface (see <xref target="addressing" format="default" section
n one adjacency per interface. If the ACP node has multiple interfaces connectin Format="of" derivedContent="Section 6.11"/>) and connects this interface to the
g to the same subnet across which it is also operating as an L2 switch in the Da ACP VRF.</li>
ta-Plane, it employs methods for ACP with L2 switching, see <xref target="acp-l2 <li pn="section-5-2.3" derivedCounter="3.">The node establishes a list o
-switches" format="default"/>.</li> f candidate peer adjacencies and candidate channel types to try for the adjacenc
y. This is automatic for all candidate link-local adjacencies (see <xref target=
<li>For each entry in the candidate adjacency list, the node negotiates "discovery-grasp" format="default" sectionFormat="of" derivedContent="Section 6.
a secure tunnel using the candidate channel types. See <xref target="channel-se 4"/>) across all native interfaces (see <xref target="if-enable-auto" format="de
lection" format="default"/>.</li> fault" sectionFormat="of" derivedContent="Section 9.3.4"/>). If a candidate peer
is discovered via multiple interfaces, this will result in one adjacency per in
<li>The node authenticates the peer node during secure channel setup and terface. If the ACP node has multiple interfaces connecting to the same subnet a
authorizes it to become part of the ACP according to <xref target="certcheck" f cross which it is also operating as an L2 switch in the data plane, it employs m
ormat="default"/>.</li> ethods for ACP with L2 switching, see <xref target="acp-l2-switches" format="def
ault" sectionFormat="of" derivedContent="Section 7"/>.</li>
<li>Unsuccessful authentication of a candidate peer results in throttled <li pn="section-5-2.4" derivedCounter="4.">For each entry in the candida
connection retries for as long as the candidate peer is discoverable. See <xref te adjacency list, the node negotiates a secure tunnel using the candidate chann
target="neighbor_verification" format="default"/>.</li> el types. See <xref target="channel-selection" format="default" sectionFormat="
of" derivedContent="Section 6.6"/>.</li>
<li>Each successfully established secure channel is mapped into an ACP v <li pn="section-5-2.5" derivedCounter="5.">The node authenticates the pe
irtual interface, which is placed into the ACP VRF. See <xref target="ACP-virtu er node during secure channel setup and authorizes it to become part of the ACP
al-interfaces" format="default"/>.</li> according to <xref target="certcheck" format="default" sectionFormat="of" derive
dContent="Section 6.2.3"/>.</li>
<li>Each node runs a lightweight routing protocol, see <xref target="rou <li pn="section-5-2.6" derivedCounter="6.">Unsuccessful authentication o
ting" format="default"/>, to announce reachability of the ACP loopback address ( f a candidate peer results in throttled connection retries for as long as the ca
or prefix) across the ACP.</li> ndidate peer is discoverable. See <xref target="neighbor_verification" format="d
efault" sectionFormat="of" derivedContent="Section 6.7"/>.</li>
<li>This completes the creation of the ACP with hop-by-hop secure tunnel <li pn="section-5-2.7" derivedCounter="7.">Each successfully established
s, auto-addressing and auto-routing. The node is now an ACP node with a running secure channel is mapped to an ACP virtual interface, which is placed into the
ACP.</li> ACP VRF. See <xref target="ACP-virtual-interfaces" format="default" sectionForm
at="of" derivedContent="Section 6.13.5.2"/>.</li>
<li pn="section-5-2.8" derivedCounter="8.">Each node runs a lightweight
routing protocol (see <xref target="routing" format="default" sectionFormat="of"
derivedContent="Section 6.12"/>) to announce reachability of the ACP loopback a
ddress (or prefix) across the ACP.</li>
<li pn="section-5-2.9" derivedCounter="9.">This completes the creation o
f the ACP with hop-by-hop secure tunnels, auto-addressing, and auto-routing. The
node is now an ACP node with a running ACP.</li>
</ol> </ol>
<t>Note: <t indent="0" pn="section-5-3">Note:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-4
<li>None of the above operations (except the following explicit configur ">
ed ones) are reflected in the configuration of the node.</li> <li pn="section-5-4.1">None of the above operations (except the followin
<li>Non-ACP NMS ("Network Management Systems") or SDN controllers have t g explicitly configured ones) are reflected in the configuration of the node.</l
o be explicitly configured for connection into the ACP.</li> i>
<li>Additional candidate peer adjacencies for ACP connections across non <li anchor="sec5bt2" pn="section-5-4.2">Non-ACP network management syste
-ACP Layer-3 clouds requires explicit configuration. See <xref target="remote-ac ms (NMS) or SDN controllers have to be explicitly configured for connection to t
p-neighbors" format="default"/>.</li> he ACP.</li>
<li pn="section-5-4.3">Additional candidate peer adjacencies for ACP con
nections across non-ACP Layer 3 clouds requires explicit configuration. See <xre
f target="remote-acp-neighbors" format="default" sectionFormat="of" derivedConte
nt="Section 8.2"/>.</li>
</ul> </ul>
<t>The following figure illustrates the ACP.</t> <t indent="0" pn="section-5-5"><xref target="acp" format="default" section
<figure anchor="acp"> Format="of" derivedContent="Figure 1"/> illustrates the ACP.</t>
<name>ACP VRF and secure channels</name> <figure anchor="acp" align="left" suppress-title="false" pn="figure-1">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-acp-vrf-and-secure-channels">ACP VRF and Secur
ACP node 1 ACP node 2 e Channels</name>
<artwork name="" type="" align="left" alt="" pn="section-5-6.1">
ACP Node 1 ACP Node 2
................... ................... ................... ...................
secure . . secure . . secure secure . . secure . . secure
channel: +-----------+ : channel : +-----------+ : channel channel: +-----------+ : channel : +-----------+ : channel
..--------| ACP VRF |---------------------| ACP VRF |---------.. ..--------| ACP VRF |---------------------| ACP VRF |---------..
: / \ / \ <--routing--&gt; / \ / \ : : / \ / \ <--routing--&gt; / \ / \ :
: \ / \ / \ / \ / : : \ / \ / \ / \ / :
..--------| Loopback |---------------------| Loopback |---------.. ..--------| loopback |---------------------| loopback |---------..
: | interface | : : | interface | : : | interface | : : | interface | :
: +-----------+ : : +-----------+ : : +-----------+ : : +-----------+ :
: : : : : : : :
: Data-Plane :...............: Data-Plane : : Data Plane :...............: Data Plane :
: : link : : : : link : :
:.................: :.................: :.................: :.................:
]]></artwork> </artwork>
</figure> </figure>
<t>The resulting overlay network is normally based exclusively on hop-by-h op tunnels. This is because addressing used on links is IPv6 link local address ing, which does not require any prior set-up. In this way the ACP can be built even if there is no configuration on the node, or if the Data-Plane has issues s uch as addressing or routing problems.</t> <t indent="0" pn="section-5-7">The resulting overlay network is normally b ased exclusively on hop-by-hop tunnels. This is because addressing used on link s is IPv6 link-local addressing, which does not require any prior setup. In thi s way, the ACP can be built even if there is no configuration on the node, or if the data plane has issues such as addressing or routing problems.</t>
</section> </section>
<!-- overview --> <section anchor="self-creation" numbered="true" toc="include" removeInRFC="f
<section anchor="self-creation" numbered="true" toc="default"> alse" pn="section-6">
<name>Self-Creation of an Autonomic Control Plane (ACP) (Normative)</name> <name slugifiedName="name-self-creation-of-an-autonom">Self-Creation of an
<t>This section specifies the components and steps to set up an ACP. The A Autonomic Control Plane (ACP) (Normative)</name>
CP is automatically "self-creating", which makes it "indestructible" against mos <t indent="0" pn="section-6-1">This section specifies the components and s
t changes to the Data-Plane, including misconfigurations of routing, addressing, teps to set up an ACP. The ACP is automatically self-creating, which makes it "i
NAT, firewall or any other traffic policy filters that inadvertently or otherwi ndestructible" against most changes to the data plane, including misconfiguratio
se unavoidably would also impact the management plane traffic, such as the actua ns of routing, addressing, NAT, firewall, or any other traffic policy filters th
l operator CLI session or controller NETCONF session through which the configura at would inadvertently or otherwise unavoidably also impact the management plane
tion changes to the Data-Plane are executed.</t> traffic, such as the actual operator command-line interface (CLI) session or co
<t>Physical misconfiguration of wiring between ACP nodes will also not bre ntroller NETCONF session through which the configuration changes to the data pla
ak the ACP: As long as there is a transitive physical path between ACP nodes, th ne are executed.</t>
e ACP should be able to recover given that it automatically operates across all <t indent="0" pn="section-6-2">Physical misconfiguration of wiring between
interfaces of the ACP nodes and automatically determines paths between them.</t> ACP nodes will also not break the ACP. As long as there is a transitive physica
<t>Attacks against the network via incorrect routing or addressing informa l path between ACP nodes, the ACP should be able to recover given that it automa
tion for the Data-Plane will not impact the ACP. Even impaired ACP nodes will ha tically operates across all interfaces of the ACP nodes and automatically determ
ve a significantly reduced attack surface against malicious misconfiguration bec ines paths between them.</t>
ause only very limited ACP or interface up/down configuration can affect the ACP <t indent="0" pn="section-6-3">Attacks against the network via incorrect r
, and pending on their specific designs these type of attacks could also be elim outing or addressing information for the data plane will not impact the ACP. Eve
inated. See more in <xref target="enabling-acp" format="default"/> and <xref tar n impaired ACP nodes will have a significantly reduced attack surface against ma
get="security" format="default"/>.</t> licious misconfiguration because only very limited ACP or interface up/down conf
<t>An ACP node can be a router, switch, controller, NMS host, or any other iguration can affect the ACP, and depending on their specific designs, these typ
IPv6 capable node. Initially, it MUST have its ACP certificate, as well as an es of attacks could also be eliminated. See more in <xref target="enabling-acp"
(empty) ACP Adjacency Table (described in <xref target="adj-table" format="defau format="default" sectionFormat="of" derivedContent="Section 9.3"/> and <xref tar
lt"/>). It then can start to discover ACP neighbors and build the ACP. This is get="security" format="default" sectionFormat="of" derivedContent="Section 11"/>
described step by step in the following sections:</t> .</t>
<t indent="0" pn="section-6-4">An ACP node can be a router, switch, contro
<section anchor="tls" numbered="true" toc="default"> ller, NMS host, or any other IPv6-capable node. Initially, it <bcp14>MUST</bcp1
<name>Requirements for use of Transport Layer Security (TLS)</name> 4> have its ACP certificate, as well as an (empty) ACP adjacency table (describe
<t>The following requirements apply to TLS required or used by ACP com d in <xref target="adj-table" format="default" sectionFormat="of" derivedContent
ponents. Applicable ACP components include ACP certificate maintenance via EST, ="Section 6.3"/>). It then can start to discover ACP neighbors and build the AC
see <xref target="domcert-maint" format="default"/>, TLS connections for Certifi P. This is described step by step in the following sections.</t>
cate Revocation List (CRL) Distribution Point (CRLDP) or Online Certificate Stat <section anchor="tls" numbered="true" toc="include" removeInRFC="false" pn
us Protocol (OCSP) responder (if used, see <xref target="certcheck" format="defa ="section-6.1">
ult"/>) and ACP GRASP (see <xref target="GRASP-substrate" format="default"/>). O <name slugifiedName="name-requirements-for-the-use-of">Requirements for
n ANI nodes these requirements also apply to BRSKI.</t> the Use of Transport Layer Security (TLS)</name>
<t indent="0" pn="section-6.1-1">The following requirements apply to TLS
<t>TLS MUST comply with <xref target="RFC7525" format="default"/> exce that is required or used by ACP components. Applicable ACP components include A
pt that TLS 1.2 (<xref target="RFC5246" format="default"/>) is REQUIRED and that CP certificate maintenance via EST (see <xref target="domcert-maint" format="def
older versions of TLS MUST NOT be used. TLS 1.3 (<xref target="RFC8446" format ault" sectionFormat="of" derivedContent="Section 6.2.5"/>), TLS connections for
="default"/>) SHOULD be supported. The choice for TLS 1.2 as the lowest common d CRL Distribution Point (CRLDP) or Online Certificate Status Protocol (OCSP) resp
enominator for the ACP is based on current expected most likely availability acr onder (if used, see <xref target="certcheck" format="default" sectionFormat="of"
oss the wide range of candidate ACP node types, potentially with non-agile opera derivedContent="Section 6.2.3"/>), and ACP GRASP (see <xref target="GRASP-subst
ting system TCP/IP stacks.</t> rate" format="default" sectionFormat="of" derivedContent="Section 6.9.2"/>). On
ANI nodes, these requirements also apply to BRSKI.</t>
<t>TLS MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ <t indent="0" pn="section-6.1-2">TLS <bcp14>MUST</bcp14> comply with "<x
ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options with less than 256-bit ref target="RFC7525" format="title" sectionFormat="of" derivedContent="Recommend
symmetric key strength or hash strength of less than 384 bits. When TLS 1.3 is ations for Secure Use of Transport Layer Security (TLS) and Datagram Transport L
supported, TLS_AES_256_GCM_SHA384 MUST be offered and TLS_CHACHA20_POLY1305_SHA ayer Security (DTLS)"/>" <xref target="RFC7525" format="default" sectionFormat="
256 MAY be offered.</t> of" derivedContent="RFC7525"/> except that TLS 1.2 ("<xref target="RFC5246" form
at="title" sectionFormat="of" derivedContent="The Transport Layer Security (TLS)
<t>TLS MUST also include the "Supported Elliptic Curves" extension, it Protocol Version 1.2"/>" <xref target="RFC5246" format="default" sectionFormat=
MUST support the NIST P-256 (secp256r1(22)) and P-384 (secp384r1(24)) curves <x "of" derivedContent="RFC5246"/>) is <bcp14>REQUIRED</bcp14> and that older versi
ref target="RFC8422" format="default"/>. In addition, TLS 1.2 clients SHOULD se ons of TLS <bcp14>MUST NOT</bcp14> be used. TLS 1.3 ("<xref target="RFC8446" fo
nd an ec_point_format extension with a single element, "uncompressed".</t> rmat="title" sectionFormat="of" derivedContent="The Transport Layer Security (TL
S) Protocol Version 1.3"/>" <xref target="RFC8446" format="default" sectionForma
t="of" derivedContent="RFC8446"/>) <bcp14>SHOULD</bcp14> be supported. The choic
e for TLS 1.2 as the lowest common denominator for the ACP is based on the curre
ntly expected and most likely availability across the wide range of candidate AC
P node types, potentially with non-agile operating system TCP/IP stacks.</t>
<t indent="0" pn="section-6.1-3">TLS <bcp14>MUST</bcp14> offer TLS_ECDHE
_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and <bc
p14>MUST NOT</bcp14> offer options with less than 256-bit symmetric key strength
or hash strength of less than 384 bits. When TLS 1.3 is supported, TLS_AES_25
6_GCM_SHA384 <bcp14>MUST</bcp14> be offered and TLS_CHACHA20_POLY1305_SHA256 <bc
p14>MAY</bcp14> be offered.</t>
<t indent="0" pn="section-6.1-4">TLS <bcp14>MUST</bcp14> also include th
e "Supported Elliptic Curves" extension, and it <bcp14>MUST</bcp14> support the
NIST P-256 (secp256r1(22)) and P-384 (secp384r1(24)) curves "<xref target="RFC84
22" format="title" sectionFormat="of" derivedContent="Elliptic Curve Cryptograph
y (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlie
r"/>" <xref target="RFC8422" format="default" sectionFormat="of" derivedContent=
"RFC8422"/>. In addition, TLS 1.2 clients <bcp14>SHOULD</bcp14> send an ec_poin
t_format extension with a single element, "uncompressed".</t>
</section> </section>
<section anchor="domcert" numbered="true" toc="include" removeInRFC="false
<section anchor="domcert" numbered="true" toc="default"> " pn="section-6.2">
<name>ACP Domain, Certificate and Network</name> <name slugifiedName="name-acp-domain-certificate-and-">ACP Domain, Certi
<t>The ACP relies on group security. An ACP domain is a group of nodes ficate, and Network</name>
that trust <t indent="0" pn="section-6.2-1">The ACP relies on group security. An A
CP domain is a group of nodes that trust
each other to participate in ACP operations such as creating ACP secure channels each other to participate in ACP operations such as creating ACP secure channels
in an autonomous peer-to-peer fashion between ACP domain members via protocols s in an autonomous, peer-to-peer fashion between ACP domain members via protocols
uch as IPsec. such as IPsec.
To authenticate and authorize another ACP member node with access to the ACP Dom To authenticate and authorize another ACP member node with access to the ACP dom
ain, each ACP member requires ain, each ACP member requires
keying material: An ACP node MUST have a Local Device IDentity (LDevID) certific keying material: an ACP node <bcp14>MUST</bcp14> have an LDevID certificate
ate, and information about one or more TAs
henceforth called the ACP certificate and information about one or more Trust An as required for the ACP domain membership check (<xref target="certcheck" format
chor (TA) ="default" sectionFormat="of" derivedContent="Section 6.2.3"/>).</t>
as required for the ACP domain membership check (<xref target="certcheck" format <t indent="0" pn="section-6.2-2">Manual keying via shared secrets is not
="default"/>).</t> usable for an ACP domain because it would require a single shared secret across
<t>Manual keying via shared secrets is not usable for an ACP domain beca all current and future ACP domain members to meet the expectation of autonomous
use it would require a single shared secret across all current and future ACP do , peer-to-peer establishment of ACP secure channels between any ACP domain membe
main members to meet the expectation of autonomous, peer-to-peer establishment o rs. Such a single shared secret would be an unacceptable security weakness. Asym
f ACP secure channels between any ACP domain members. Such a single shared secre metric keying material (public keys) without certificates does not provide the m
t would be an inacceptable security weakness. Asymmetric keying material (public echanism to authenticate ACP domain membership in an autonomous, peer-to-peer fa
keys) without certificates does not provide the mechanisms to authenticate ACP shion for current and future ACP domain members.</t>
domain membership in an autonomous, peer-to-peer fashion for current and future <t indent="0" pn="section-6.2-3">The LDevID certificate is henceforth ca
ACP domain members.</t> lled the ACP certificate. The TA is the CA root certificate of the ACP domain.</
<t>The LDevID certificate is called the ACP certificate. The TA is the C t>
ertification Authority (CA) root certificate of the ACP domain.</t> <t indent="0" pn="section-6.2-4">The ACP does not mandate specific mecha
<t>The ACP does not mandate specific mechanisms by which this keying mat nisms by which this keying material is provisioned into the ACP node. It only re
erial is provisioned into the ACP node. It only requires the certificate to comp quires that the certificate comply with <xref target="acp-certificates" format="
ly with <xref target="acp-certificates" format="default"/>, specifically to have default" sectionFormat="of" derivedContent="Section 6.2.1"/>, specifically that
the acp-node-name as specified in <xref target="domcert-acpinfo" format="defaul it have the acp-node-name as specified in <xref target="domcert-acpinfo" format=
t"/> in its domain certificate as well as those of candidate ACP peers. See <xr "default" sectionFormat="of" derivedContent="Section 6.2.2"/> in its domain cert
ef target="bootstrap" format="default"/> for more information about enrollment o ificate as well as those of candidate ACP peers. See <xref target="bootstrap" f
r provisioning options.</t> ormat="default" sectionFormat="of" derivedContent="Appendix A.2"/> for more info
rmation about enrollment or provisioning options.</t>
<t>This document uses the term ACP in many places where the Autonomic Ne <t indent="0" pn="section-6.2-5">This document uses the term ACP in many
tworking reference documents <xref target="RFC7575" format="default"/> and <xref places where the Autonomic Networking reference documents <xref target="RFC7575
target="I-D.ietf-anima-reference-model" format="default"/> use the word autonom " format="default" sectionFormat="of" derivedContent="RFC7575"/> and <xref targe
ic. This is done because those reference documents consider (only) fully autono t="RFC8993" format="default" sectionFormat="of" derivedContent="RFC8993"/> use t
mic networks and nodes, but support of ACP does not require support for other co he word autonomic. This is done because those reference documents consider (onl
mponents of autonomic networks except for relying on GRASP and providing securit y) fully Autonomic Networks and nodes, but the support of ACP does not require t
y and transport for GRASP. Therefore, the word autonomic might be misleading to he support for other components of Autonomic Networks except for the reliance on
operators interested in only the ACP.</t> GRASP and the providing of security and transport for GRASP. Therefore, the wo
<t><xref target="RFC7575" format="default"/> defines the term "Autonomic rd autonomic might be misleading to operators interested in only the ACP.</t>
Domain" as a collection of autonomic nodes. ACP nodes do not need to be fully <t indent="0" pn="section-6.2-6"><xref target="RFC7575" format="default"
autonomic, but when they are, then the ACP domain is an autonomic domain. Likew sectionFormat="of" derivedContent="RFC7575"/> defines the term "autonomic domai
ise, <xref target="I-D.ietf-anima-reference-model" format="default"/> defines th n" as a collection of autonomic nodes. ACP nodes do not need to be fully autono
e term "Domain Certificate" as the certificate used in an autonomic domain. The mic, but when they are, then the ACP domain is an autonomic domain. Likewise, <
ACP certificate is that domain certificate when ACP nodes are (fully) autonomic xref target="RFC8993" format="default" sectionFormat="of" derivedContent="RFC899
nodes. Finally, this document uses the term ACP network to refer to the networ 3"/> defines the term "domain certificate" as the certificate used in an autonom
k created by active ACP nodes in an ACP domain. The ACP network itself can exte ic domain. The ACP certificate is that domain certificate when ACP nodes are (f
nd beyond ACP nodes through the mechanisms described in <xref target="ACPconnect ully) autonomic nodes. Finally, this document uses the term ACP network to refe
" format="default"/>.</t> r to the network created by active ACP nodes in an ACP domain. The ACP network
<section anchor="acp-certificates" numbered="true" toc="default"> itself can extend beyond ACP nodes through the mechanisms described in <xref tar
<name>ACP Certificates</name> get="ACPconnect" format="default" sectionFormat="of" derivedContent="Section 8.1
<t>ACP certificates MUST be <xref target="RFC5280" format="default"/> "/>.</t>
compliant X.509 v3 (<xref target="X.509" format="default"/>) certificates.</t> <section anchor="acp-certificates" numbered="true" toc="include" removeI
<t>ACP nodes MUST support handling ACP certificates, TA certificates a nRFC="false" pn="section-6.2.1">
nd certificate chain certificates (henceforth just called certificates in this s <name slugifiedName="name-acp-certificates">ACP Certificates</name>
ection) with RSA public keys and certificates with Elliptic Curve (ECC) public k <t indent="0" pn="section-6.2.1-1">ACP certificates <bcp14>MUST</bcp14
eys.</t> > be <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="
RFC5280"/> compliant X.509 v3 <xref target="X.509" format="default" sectionForma
<t>ACP nodes MUST NOT support certificates with RSA public keys of les t="of" derivedContent="X.509"/> certificates.</t>
s than 2048-bit modulus or curves with group order of less than 256-bit. They MU <t indent="0" pn="section-6.2.1-2">ACP nodes <bcp14>MUST</bcp14> suppo
ST support certificates with RSA public keys with 2048-bit modulus and MAY suppo rt handling ACP certificates, TA certificates, and certificate chain certificate
rt longer RSA keys. They MUST support certificates with ECC public keys using NI s (henceforth just called certificates in this section) with RSA public keys and
ST P-256 curves and SHOULD support P-384 and P-521 curves.</t> certificates with Elliptic Curve Cryptography (ECC) public keys.</t>
<t indent="0" pn="section-6.2.1-3">ACP nodes <bcp14>MUST NOT</bcp14> s
<t>ACP nodes MUST NOT support certificates with RSA public keys whose upport certificates with RSA public keys of less than a 2048-bit modulus or curv
es with group order of less than 256 bits. They <bcp14>MUST</bcp14> support cert
ificates with RSA public keys with 2048-bit modulus and <bcp14>MAY</bcp14> suppo
rt longer RSA keys. They <bcp14>MUST</bcp14> support certificates with ECC publi
c keys using NIST P-256 curves and <bcp14>SHOULD</bcp14> support P-384 and P-521
curves.</t>
<t indent="0" pn="section-6.2.1-4">ACP nodes <bcp14>MUST NOT</bcp14> s
upport certificates with RSA public keys whose
modulus is less than 2048 bits, or certificates whose ECC public keys modulus is less than 2048 bits, or certificates whose ECC public keys
are in groups whose order is less than 256-bits. RSA signing are in groups whose order is less than 256 bits. RSA signing
certificates with 2048-bit public keys MUST be supported, and such certificates with 2048-bit public keys <bcp14>MUST</bcp14> be supporte
certificates with longer public keys MAY be supported. ECDSA d, and such
certificates using the NIST P-256 curve MUST be supported, and such certificates with longer public keys <bcp14>MAY</bcp14> be supported.
certificates using the P-384 and P-521 curves SHOULD be supported.</t> ECDSA
certificates using the NIST P-256 curve <bcp14>MUST</bcp14> be support
<t>ACP nodes MUST support RSA certificates that are signed by RSA ed, and such
signatures over the SHA-256 digest of the contents, and SHOULD certificates using the P-384 and P-521 curves <bcp14>SHOULD</bcp14> be
supported.</t>
<t indent="0" pn="section-6.2.1-5">ACP nodes <bcp14>MUST</bcp14> suppo
rt RSA certificates that are signed by RSA
signatures over the SHA-256 digest of the contents and <bcp14>SHOULD</
bcp14>
additionally support SHA-384 and SHA-512 digests in such signatures. additionally support SHA-384 and SHA-512 digests in such signatures.
The same requirements for digest usage in certificate signatures apply The same requirements for digest usage in certificate signatures apply
to ECDSA to Elliptic Curve Digital Signature Algorithm (ECDSA)
certificates, and additionally, ACP nodes MUST support ECDSA certificates, and additionally, ACP nodes <bcp14>MUST</bcp14> support
ECDSA
signatures on ECDSA certificates.</t> signatures on ECDSA certificates.</t>
<t indent="0" pn="section-6.2.1-6">The ACP certificate <bcp14>SHOULD</
<t>The ACP certificate SHOULD use an RSA key and an RSA signature when bcp14> use an RSA key and an RSA signature when the ACP certificate is intended
the ACP certificate is intended to be used not only for ACP authentication but to be used not only for ACP authentication but also for other purposes. The ACP
also for other purposes. The ACP certificate MAY use an ECC key and an ECDSA sig certificate <bcp14>MAY</bcp14> use an ECC key and an ECDSA signature if the ACP
nature if the ACP certificate is only used for ACP and ANI authentication and au certificate is only used for ACP and ANI authentication and authorization.</t>
thorization.</t> <t indent="0" pn="section-6.2.1-7">Any secure channel protocols used f
or the ACP as specified in this document or extensions of this document <bcp14>M
<t>Any secure channel protocols used for the ACP as specified in this UST</bcp14> therefore support authentication (e.g., signing), starting with thes
document or extensions of this document MUST therefore support authentication (e e types of certificates. See <xref target="RFC8422" format="default" sectionForm
.g. signing) starting with these type of certificates. See <xref target="RFC8422 at="of" derivedContent="RFC8422"/> for more information.</t>
" format="default"/> for more information.</t> <t indent="0" pn="section-6.2.1-8">The reason for these choices are as
follows: as of 2020, RSA is still more widely used than ECC, therefore the <bcp
<t>The reason for these choices are as follows: As of 2020, RSA is sti 14>MUST</bcp14>-level requirements for RSA. ECC offers equivalent security at (l
ll more widely used than ECC, therefore the MUST for RSA. ECC offers equivalent ogarithmically) shorter key lengths (see <xref target="RFC8422" format="default"
security at (logarithmically) shorter key lengths (see <xref target="RFC8422" fo sectionFormat="of" derivedContent="RFC8422"/>). This can be beneficial especial
rmat="default"/>). This can be beneficial especially in the presence of constrai ly in the presence of constrained bandwidth or constrained nodes in an ACP/ANI n
ned bandwidth or constrained nodes in an ACP/ANI network. Some ACP functions suc etwork. Some ACP functions such as GRASP peer-to-peer across the ACP require end
h as GRASP peer-2-peer across the ACP require end-to-end/any-to-any authenticati -to-end/any-to-any authentication and authorization, therefore ECC can only reli
on/authorization, therefore ECC can only reliably be used in the ACP when it MUS ably be used in the ACP when it <bcp14>MUST</bcp14> be supported on all ACP node
T be supported on all ACP nodes. RSA signatures are mandatory to be supported al s. RSA signatures are mandatory to be supported also for ECC certificates becaus
so for ECC certificates because CAs themselves may not support ECC yet.</t> e the CAs themselves may not support ECC yet.</t>
<t indent="0" pn="section-6.2.1-9">The ACP certificate <bcp14>SHOULD</
<t>The ACP certificate SHOULD be used for any authentication between n bcp14> be used for any authentication between nodes with ACP
odes with ACP
domain certificates (ACP nodes and NOC nodes) where a required authorization con dition is ACP domain membership, such as ACP node to NOC/OAM end-to-end security and ASA to ASA end-to-end security. domain certificates (ACP nodes and NOC nodes) where a required authorization con dition is ACP domain membership, such as ACP node to NOC/OAM end-to-end security and ASA to ASA end-to-end security.
<xref target="certcheck" format="default"/> defines this "ACP domain membership check". <xref target="certcheck" format="default" sectionFormat="of" derivedContent="Sec tion 6.2.3"/> defines this "ACP domain membership check".
The uses of this check that are standardized in this document are for the establ ishment of The uses of this check that are standardized in this document are for the establ ishment of
hop-by-hop ACP secure channels (<xref target="neighbor_verification" format="def hop-by-hop ACP secure channels (<xref target="associations" format="default" sec
ault"/>) and for ACP GRASP (<xref target="GRASP-substrate" format="default"/>) e tionFormat="of" derivedContent="Section 6.8"/>) and for ACP GRASP (<xref target=
nd-to-end via TLS.</t> "GRASP-substrate" format="default" sectionFormat="of" derivedContent="Section 6.
9.2"/>) end to end via TLS.</t>
<t>The ACP domain membership check requires a minimum amount of elemen <t indent="0" pn="section-6.2.1-10">The ACP domain membership check re
ts in a certificate as described in <xref target="certcheck" format="default"/>. quires a minimum number of elements in a certificate as described in <xref targe
The identity of a node in the ACP is carried via the acp-node-name as defined i t="certcheck" format="default" sectionFormat="of" derivedContent="Section 6.2.3"
n <xref target="domcert-acpinfo" format="default"/>.</t> />. The identity of a node in the ACP is carried via the acp-node-name as define
d in <xref target="domcert-acpinfo" format="default" sectionFormat="of" derivedC
<t>To support ECDH directly with the key in the ACP certificate, ontent="Section 6.2.2"/>.</t>
ACP certificates with ECC keys need to indicate to be Elliptic Curve Diffie-Hell <t indent="0" pn="section-6.2.1-11">To support Elliptic Curve Diffie-H
man ellman (ECDH) directly with the key in the ACP certificate,
capable (ECDH): If the X.509v3 keyUsage extension is present, the keyAgreement b ACP certificates with ECC keys need to indicate that they are ECDH
it capable: if the X.509 v3 keyUsage extension is present, the keyAgreement bit
must then be set. Note that this option is not required for any of the must then be set. Note that this option is not required for any of the
required ciphersuites in this document and may not be supported by all CA.</t> required ciphersuites in this document and may not be supported by all CAs.</t>
<t indent="0" pn="section-6.2.1-12">Any other fields of the ACP certif
<t>Any other fields of the ACP certificate are to be populated as requ icate are to be populated as required by <xref target="RFC5280" format="default"
ired by <xref target="RFC5280" format="default"/>: As long as they are compliant sectionFormat="of" derivedContent="RFC5280"/>. As long as they are compliant wi
with <xref target="RFC5280" format="default"/>, any other field of an ACP certi th <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RF
ficate can be set as desired by the operator of the ACP domain through appropria C5280"/>, any other field of an ACP certificate can be set as desired by the ope
te ACP registrar/ACP CA procedures. For example, other fields may be required fo rator of the ACP domain through the appropriate ACP registrar and/or ACP CA proc
r other purposes that the ACP certificate is intended to be used for (such as el edures. For example, other fields may be required for purposes other than those
ements of a SubjectName).</t> that the ACP certificate is intended to be used for (such as elements of a Subje
ctName).</t>
<t>For further certificate details, ACP certificates may follow the re <t indent="0" pn="section-6.2.1-13">For further certificate details, A
commendations from <xref target="CABFORUM" format="default"/>.</t> CP certificates may follow the recommendations from <xref target="CABFORUM" form
at="default" sectionFormat="of" derivedContent="CABFORUM"/>.</t>
<t>For diagnostic and other operational purposes, it is beneficial to <t indent="0" pn="section-6.2.1-14">For diagnostic and other operation
copy the device identifying fields of the node's IDevID certificate into the ACP al purposes, it is beneficial
certificate, such as the <xref target="X.520" format="default"/>, section 6.2.9 to copy the device-identifying fields of the node's IDevID
"serialNumber" attribute in the subject field distinguished name encoding. Note certificate into the ACP certificate, such as the
that this is not the certificate serial number. See also <xref target="I-D.iet "serialNumber" attribute
f-anima-bootstrapping-keyinfra" format="default"/> section 2.3.1. This can be do (<xref target="X.520" format="default" sectionFormat="of" derivedContent="X.520"
ne for example if it would be acceptable for the device's "serialNumber" to be s />, Section 6.2.9)
ignaled via the Link Layer Discovery Protocol (LLDP, <xref target="LLDP" format= in the subject field distinguished name encoding. Note
"default"/>) because like LLDP signaled information, the ACP certificate informa that this is not the certificate serial-number. See also <xref target=
tion can be retrieved by neighboring nodes without further authentication and be "RFC8995" sectionFormat="comma" section="2.3.1" format="default" derivedLink="ht
used either for beneficial diagnostics or for malicious attacks. Retrieval of t tps://rfc-editor.org/rfc/rfc8995#section-2.3.1" derivedContent="RFC8995"/>. This
he ACP certificate is possible via a (failing) attempt to set up an ACP secure c can be done, for example, if it would be acceptable for the device's "serialNum
hannel, and the "serialNumber" usually contains device type information that may ber" to be signaled via the Link Layer Discovery Protocol <xref target="LLDP" fo
help to faster determine working exploits/attacks against the device.</t> rmat="default" sectionFormat="of" derivedContent="LLDP"/> because, like LLDP-sig
naled information, the ACP certificate information can be retrieved by neighbori
<t>Note that there is no intention to constrain authorization within t ng nodes without further authentication and can be used either for beneficial di
he ACP or autonomic networks using the ACP to just the ACP domain membership che agnostics or for malicious attacks. Retrieval of the ACP certificate is possible
ck as defined in this document. It can be extended or modified with additional r via a (failing) attempt to set up an ACP secure channel, and the "serialNumber"
equirements. Such future authorizations can use and require additional elements usually contains device type information that may help to more quickly determin
in certificates or policies or even additional certificates. See the additional e working exploits/attacks against the device.</t>
check against the id-kp-cmcRA <xref target="RFC6402" format="default"/> extended <t indent="0" pn="section-6.2.1-15">Note that there is no intention to
key usage attribute (<xref target="domcert-maint" format="default"/>) and for p constrain authorization within the ACP or Autonomic Networks using the ACP to j
ossible future extensions, see <xref target="role-assignments" format="default"/ ust the ACP domain membership check as defined in this document. It can be exten
>.</t> ded or modified with additional requirements. Such future authorizations can use
and require additional elements in certificates or policies or even additional
certificates. See <xref target="domcert-maint" format="default" sectionFormat="o
f" derivedContent="Section 6.2.5"/> for the additional check against the id-kp-c
mcRA extended key usage attribute ("<xref target="RFC6402" format="title" sectio
nFormat="of" derivedContent="Certificate Management over CMS (CMC) Updates"/>" <
xref target="RFC6402" format="default" sectionFormat="of" derivedContent="RFC640
2"/>), and see <xref target="role-assignments" format="default" sectionFormat="
of" derivedContent="Appendix A.9.5"/> for possible future extensions.</t>
</section> </section>
<section anchor="domcert-acpinfo" numbered="true" toc="default"> <section anchor="domcert-acpinfo" numbered="true" toc="include" removeIn
<name>ACP Certificate AcpNodeName</name> RFC="false" pn="section-6.2.2">
<?rfc needLines="20" ?> <name slugifiedName="name-acp-certificate-acpnodename">ACP Certificate
<figure anchor="acp-dominfo-abnf"> AcpNodeName</name>
<name>ACP Node Name ABNF</name> <figure anchor="acp-dominfo-abnf" align="left" suppress-title="false"
<artwork name="" type="" align="left" alt=""><![CDATA[ pn="figure-2">
<name slugifiedName="name-acp-node-name-abnf">ACP Node Name ABNF</na
me>
<sourcecode name="" type="abnf" markers="false" pn="section-6.2.2-1.
1">
acp-node-name = local-part "@" acp-domain-name acp-node-name = local-part "@" acp-domain-name
local-part = [ acp-address ] [ "+" rsub extensions ] local-part = [ acp-address ] [ "+" rsub extensions ]
acp-address = 32HEXDIG | "0" ; HEXDIG as of RFC5234 section B.1 acp-address = 32HEXDIG / "0" ; HEXDIG as of [RFC5234], Appendix B.1
rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5 rsub = [ &lt;subdomain&gt; ] ; &lt;subdomain&gt; as of [RFC1034], Section 3.5
acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5 acp-domain-name = &lt;domain&gt; ; as of [RFC1034], Section 3.5
extensions = *( "+" extension ) extensions = *( "+" extension )
extension = 1*etext ; future standard definition. extension = 1*etext ; future standard definition.
etext = ALPHA / DIGIT / ; Printable US-ASCII etext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / "$" / "%" / "&" / "'" / "!" / "#" / "$" / "%" / "&amp;" / "'" /
"*" / "-" / "/" / "=" / "?" / "^" / "*" / "-" / "/" / "=" / "?" / "^" /
"_" / "`" / "{" / "|" / "}" / "~" "_" / "`" / "{" / "|" / "}" / "~"
routing-subdomain = [ rsub "." ] acp-domain-name routing-subdomain = [ rsub "." ] acp-domain-name
</sourcecode>
Example: </figure>
given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 <t indent="0" pn="section-6.2.2-2">Example:</t>
and an ACP domain-name of acp.example.com <t indent="0" pn="section-6.2.2-3">Given an ACP address of fd89:b714:f
and an rsub extenstion of area51.research 3db:0:200:0:6400:0000,
an ACP domain name of acp.example.com,
then this results in: and an rsub extension of area51.research, then this results in the following
:</t>
<artwork align="left" pn="section-6.2.2-4">
acp-node-name = fd89b714f3db00000200000064000000 acp-node-name = fd89b714f3db00000200000064000000
+area51.research@acp.example.com +area51.research@acp.example.com
acp-domain-name = acp.example.com acp-domain-name = acp.example.com
routing-subdomain = area51.research.acp.example.com routing-subdomain = area51.research.acp.example.com
]]></artwork> </artwork>
</figure> <t indent="0" pn="section-6.2.2-5">The acp-node-name in <xref target="
<t>acp-node-name in above <xref target="acp-dominfo-abnf" format="defa acp-dominfo-abnf" format="default" sectionFormat="of" derivedContent="Figure 2"/
ult"/> is the ABNF (<xref target="RFC5234" format="default"/>) definition of the > is the ABNF definition ("<xref target="RFC5234" format="title" sectionFormat="
ACP Node Name. An ACP certificate MUST carry this information. It MUST be encod of" derivedContent="Augmented BNF for Syntax Specifications: ABNF"/>" <xref targ
ed as a subjectAltName / otherName / AcpNodeName as described in <xref target="a et="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/>) of
sn1" format="default"/>.</t> the ACP Node Name. An ACP certificate <bcp14>MUST</bcp14> carry this information
<t>Nodes complying with this specification MUST be able to receive the . It <bcp14>MUST</bcp14> contain an otherName field in the X.509 Subject Alterna
ir ACP address through the domain certificate, in which case their own ACP certi tive Name extension, and the otherName <bcp14>MUST</bcp14> contain an AcpNodeNam
ficate MUST have a 32HEXDIG acp-address field. Acp-address is case insensitive b e as described in <xref target="domcert-acpinfo" format="default" sectionFormat=
ecause ABNF HEXDIG is. It is recommended to encode acp-address with lower case l "of" derivedContent="Section 6.2.2"/>.</t>
etters. Nodes complying with this specification MUST also be able to authenticat <t indent="0" pn="section-6.2.2-6">Nodes complying with this specifica
e nodes as ACP domain members or ACP secure channel peers when they have a 0-val tion <bcp14>MUST</bcp14> be able to receive their ACP address through the domain
ue acp-address field and as ACP domain members (but not as ACP secure channel pe certificate, in which case their own ACP certificate <bcp14>MUST</bcp14> have a
ers) when the acp-address field is omitted from their AcpNodeName. See <xref ta 32HEXDIG acp-address field. The acp-address field is case insensitive because A
rget="certcheck" format="default"/>.</t> BNF HEXDIG is. It is recommended to encode acp-address with lowercase letters. N
<t>acp-domain-name is used to indicate the ACP Domain across which ACP odes complying with this specification <bcp14>MUST</bcp14> also be able to authe
nodes authenticate and authorize each other, for example to build ACP secure ch nticate nodes as ACP domain members or ACP secure channel peers when they have a
annels to each other, see <xref target="certcheck" format="default"/>. acp-doma zero-value acp-address field and as ACP domain members (but not as ACP secure c
in-name SHOULD be the FQDN of an Internet domain owned by the network administra hannel peers) when the acp-address field is omitted from their AcpNodeName. See
tion of the ACP and ideally reserved to only be used for the ACP. In this specif <xref target="certcheck" format="default" sectionFormat="of" derivedContent="Se
ication it serves to be a name for the ACP that ideally is globally unique. Whe ction 6.2.3"/>.</t>
n acp-domain-name is a globally unique name, collision of ACP addresses across d <t indent="0" pn="section-6.2.2-7">The acp-domain-name is used to indi
ifferent ACP domains can only happen due to ULA hash collisions (see <xref targe cate the ACP domain across which ACP nodes authenticate and authorize each other
t="scheme" format="default"/>). Using different acp-domain-names, operators can , for example, to build ACP secure channels to each other, see <xref target="cer
distinguish multiple ACP even when using the same TA.</t> tcheck" format="default" sectionFormat="of" derivedContent="Section 6.2.3"/>. Th
<t>To keep the encoding simple, there is no consideration for internat e acp-domain-name <bcp14>SHOULD</bcp14> be the FQDN of an Internet domain owned
ionalized acp-domain-names. The acp-node-name is not intended for end user consu by the network administration of the ACP and ideally reserved to only be used fo
mption. There is no protection against an operator to pick any domain name for a r the ACP. In this specification, it serves as a name for the ACP that ideally i
n ACP whether or not the operator can claim to own the domain name. Instead, the s globally unique. When acp-domain-name is a globally unique name, collision of
domain name only serves as a hash seed for the ULA and for diagnostics to the o ACP addresses across different ACP domains can only happen due to ULA hash coll
perator. Therefore, any operator owning only an internationalized domain name sh isions (see <xref target="scheme" format="default" sectionFormat="of" derivedCon
ould be able to pick an equivalently unique 7-bit ASCII acp-domain-name string r tent="Section 6.11.2"/>). Using different acp-domain-names, operators can distin
epresenting the internationalized domain name.</t> guish multiple ACPs even when using the same TA.</t>
<t>"routing-subdomain" is a string that can be constructed from the ac <t indent="0" pn="section-6.2.2-8">To keep the encoding simple, there
p-node-name, and it is used in the hash-creation of the ULA (see below). The pr is no consideration for internationalized acp-domain-names. The acp-node-name is
esence of the "rsub" component allows a single ACP domain to employ multiple /48 not intended for end-user consumption. There is no protection against an operat
ULA prefixes. See <xref target="domain-usage" format="default"/> for example u or picking any domain name for an ACP whether or not the operator can claim to o
se-cases.</t> wn the domain name. Instead, the domain name only serves as a hash seed for the
<t>The optional "extensions" field is used for future standardized ext ULA and for diagnostics for the operator. Therefore, any operator owning only an
ensions to this specification. It MUST be ignored if present and not understood internationalized domain name should be able to pick an equivalently unique 7-b
.</t> it ASCII acp-domain-name string representing the internationalized domain name.<
<t>The following points explain and justify the encoding choices descr /t>
ibed: <t indent="0" pn="section-6.2.2-9">The routing-subdomain is a string t
</t> hat can be constructed from the acp-node-name, and it is used in the hash creati
<ol type="1" spacing="compact"> on of the ULA (see <xref target="scheme" format="default" sectionFormat="of" der
<li> ivedContent="Section 6.11.2"/>). The presence of the rsub component allows a si
<t>Formatting notes: ngle ACP domain to employ multiple /48 ULA prefixes. See <xref target="domain-u
</t> sage" format="default" sectionFormat="of" derivedContent="Appendix A.6"/> for ex
<ol type="1.%d" spacing="compact"> ample use cases.</t>
<li>"rsub" needs to be in the "local-part": If the format just h <t indent="0" pn="section-6.2.2-10">The optional extensions field is u
ad routing-subdomain as the domain part of the acp-node-name, rsub and acp-domai sed for future standardized extensions to this specification. It <bcp14>MUST</b
n-name could not be separated from each other to determine in the ACP domain mem cp14> be ignored if present and not understood.</t>
bership check which part is the acp-domain-name and which is solely for creating <t indent="0" pn="section-6.2.2-11">The following points explain and j
a different ULA prefix.</li> ustify the encoding choices described:
<li>If both "acp-address" and "rsub" are omitted from AcpNodeNam </t>
e, the "local-part" will have the format "++extension(s)". The two plus characte <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-
rs are necessary so the node can unambiguously parse that both "acp-address" and 6.2.2-12">
"rsub" are omitted.</li> <li pn="section-6.2.2-12.1" derivedCounter="1.">
<t indent="0" pn="section-6.2.2-12.1.1">Formatting notes:
</t>
<ol type="1.%d" spacing="normal" indent="adaptive" start="1" pn="s
ection-6.2.2-12.1.2">
<li pn="section-6.2.2-12.1.2.1" derivedCounter="1.1">The rsub co
mponent needs to be in the local-part: if the format just had routing-subdomain
as the domain part of the acp-node-name, rsub and acp-domain-name could not be s
eparated from each other to determine in the ACP domain membership check which p
art is the acp-domain-name and which is solely for creating a different ULA pref
ix.</li>
<li pn="section-6.2.2-12.1.2.2" derivedCounter="1.2">If both acp
-address and rsub are omitted from AcpNodeName, the local-part will have the for
mat "++extension(s)". The two plus characters are necessary so the node can unam
biguously parse that both acp-address and rsub are omitted.</li>
</ol> </ol>
</li> </li>
<li> <li pn="section-6.2.2-12.2" derivedCounter="2.">
<t>The encoding of the ACP domain name and ACP address as describe <t indent="0" pn="section-6.2.2-12.2.1">The encoding of the ACP do
d in this section is used for the following reasons: main name and ACP address as described in this section is used for the following
reasons:
</t> </t>
<ol type="2.%d" spacing="compact"> <ol type="2.%d" spacing="normal" indent="adaptive" start="1" pn="s
<li>The acp-node-name is the identifier of a node's ACP. It incl ection-6.2.2-12.2.2">
udes the necessary components to identify a node's ACP both from within the ACP <li pn="section-6.2.2-12.2.2.1" derivedCounter="2.1">The acp-nod
as well as from the outside of the ACP.</li> e-name is the identifier of a node's ACP. It includes the necessary components t
<li>For manual and/or automated diagnostics and backend manageme o identify a node's ACP both from within the ACP as well as from the outside of
nt of devices and ACPs, it is necessary to have an easily human readable and sof the ACP.</li>
tware parsed standard, single string representation of the information in the ac <li pn="section-6.2.2-12.2.2.2" derivedCounter="2.2">For manual
p-node-name. For example, inventory or other backend systems can always identify and/or automated diagnostics and backend management of devices and ACPs, it is n
an entity by one unique string field but not by a combination of multiple field ecessary to have an easily human-readable and software-parsable standard, single
s, which would be necessary if there was no single string representation.</li> string representation of the information in the acp-node-name. For example, inv
<li>If the encoding was not that of such a string, it would be n entory or other backend systems can always identify an entity by one unique stri
ecessary to define a second standard encoding to provide this format (standard s ng field but not by a combination of multiple fields, which would be necessary i
tring encoding) for operator consumption.</li> f there were no single string representation.</li>
<li>Addresses of the form &lt;local&gt;@&lt;domain&gt; have beco <li pn="section-6.2.2-12.2.2.3" derivedCounter="2.3">If the enco
me the preferred format for identifiers of entities in many systems, including t ding was not such a string, it would be necessary to define a second standard en
he majority of user identification in web or mobile applications such as multi-d coding to provide this format (standard string encoding) for operator consumptio
omain single-sign-on systems.</li> n.</li>
<li pn="section-6.2.2-12.2.2.4" derivedCounter="2.4">Addresses o
f the form &lt;local&gt;@&lt;domain&gt; have become the preferred format for ide
ntifiers of entities in many systems, including the majority of user identifiers
in web or mobile applications such as multi-domain single-sign-on systems.</li>
</ol> </ol>
</li> </li>
<li> <li pn="section-6.2.2-12.3" derivedCounter="3.">
<t>Compatibilities: <t indent="0" pn="section-6.2.2-12.3.1">Compatibilities:
</t> </t>
<ol type="3.%d" spacing="compact"> <ol type="3.%d" spacing="normal" indent="adaptive" start="1" pn="s
<li>It should be possible to use the ACP certificate as an LDevI ection-6.2.2-12.3.2">
D certificate on the system for other uses beside the ACP. Therefore, the infor <li pn="section-6.2.2-12.3.2.1" derivedCounter="3.1">It should b
mation element required for the ACP should be encoded so that it minimizes the p e possible to use the ACP certificate as an LDevID certificate on the system for
ossibility of creating incompatibilities with such other uses. The attributes of uses besides the ACP. Therefore, the information element required for the ACP
the subject field for example are often used in non-ACP applications and should should be encoded so that it minimizes the possibility of creating incompatibili
therefore not be occupied by new ACP values.</li> ties with other such uses. The attributes of the subject field, for example, are
<li>The element should not require additional ASN.1 en/decoding, often used in non-ACP applications and therefore should not be occupied by new
because libraries to access certificate information especially for embedded dev ACP values.</li>
ices may not support extended ASN.1 decoding beyond predefined, mandatory fields <li pn="section-6.2.2-12.3.2.2" derivedCounter="3.2">The element
. subjectAltName / otherName is already used with a single string parameter for should not require additional ASN.1 encoding and/or decoding because libraries
several otherNames (see <xref target="RFC3920" format="default"/>, <xref target= for accessing certificate information, especially for embedded devices, may not
"RFC7585" format="default"/>, <xref target="RFC4985" format="default"/>, <xref t support extended ASN.1 decoding beyond predefined, mandatory fields. subjectAltN
arget="RFC8398" format="default"/>).</li> ame / otherName is already used with a single string parameter for several other
<li>The element required for the ACP should minimize the risk of Names (see "<xref target="RFC6120" format="title" sectionFormat="of" derivedCont
being misinterpreted by other uses of the LDevID certificate. It also must not ent="Extensible Messaging and Presence Protocol (XMPP): Core"/>" <xref target="R
be misinterpreted to actually be an email address, hence the use of the otherNa FC6120" format="default" sectionFormat="of" derivedContent="RFC6120"/>, "<xref t
me / rfc822Name option in the certificate would be inappropriate.</li> arget="RFC7585" format="title" sectionFormat="of" derivedContent="Dynamic Peer D
iscovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (
NAI)"/>" <xref target="RFC7585" format="default" sectionFormat="of" derivedConte
nt="RFC7585"/>, "<xref target="RFC4985" format="title" sectionFormat="of" derive
dContent="Internet X.509 Public Key Infrastructure Subject Alternative Name for
Expression of Service Name"/>" <xref target="RFC4985" format="default" sectionFo
rmat="of" derivedContent="RFC4985"/>, "<xref target="RFC8398" format="title" sec
tionFormat="of" derivedContent="Internationalized Email Addresses in X.509 Certi
ficates"/>" <xref target="RFC8398" format="default" sectionFormat="of" derivedCo
ntent="RFC8398"/>).</li>
<li pn="section-6.2.2-12.3.2.3" derivedCounter="3.3">The element
required for the ACP should minimize the risk of being misinterpreted by other
uses of the LDevID certificate. It also must not be misinterpreted as an email
address, hence the use of the otherName / rfc822Name option in the certificate w
ould be inappropriate.</li>
</ol> </ol>
</li> </li>
</ol> </ol>
<t>See section 4.2.1.6 of <xref target="RFC5280" format="default"/> fo <t indent="0" pn="section-6.2.2-13">See <xref target="RFC5280" section
r details on the subjectAltName field.</t> Format="of" section="4.2.1.6" format="default" derivedLink="https://rfc-editor.o
<section anchor="asn1" numbered="true" toc="default"> rg/rfc/rfc5280#section-4.2.1.6" derivedContent="RFC5280"/> for details on the su
<name>AcpNodeName ASN.1 Module</name> bjectAltName field.</t>
<t>The following ASN.1 module normatively specifies the AcpNodeName <section anchor="asn1" numbered="true" toc="include" removeInRFC="fals
structure. e" pn="section-6.2.2.1">
This specification uses the ASN.1 definitions from <xref target="RFC5912" format <name slugifiedName="name-acpnodename-asn1-module">AcpNodeName ASN.1
="default"/> Module</name>
with the 2002 ASN.1 notation used in that document. <xref target="RFC5912" form <t indent="0" pn="section-6.2.2.1-1">The following ASN.1 module norm
at="default"/> atively specifies the AcpNodeName structure.
This specification uses the ASN.1 definitions from "<xref target="RFC5912" forma
t="title" sectionFormat="of" derivedContent="New ASN.1 Modules for the Public Ke
y Infrastructure Using X.509 (PKIX)"/>" <xref target="RFC5912" format="default"
sectionFormat="of" derivedContent="RFC5912"/>
with the 2002 ASN.1 notation used in that document. <xref target="RFC5912" form
at="default" sectionFormat="of" derivedContent="RFC5912"/>
updates normative documents using older ASN.1 notation.</t> updates normative documents using older ASN.1 notation.</t>
<figure> <figure align="left" suppress-title="false" pn="figure-3">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-acpnodename-asn1-module-2">AcpNodeName A
SN.1 Module</name>
<sourcecode name="" type="asn.1" markers="false" pn="section-6.2.2
.1-2.1">
ANIMA-ACP-2020 ANIMA-ACP-2020
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-anima-acpnodename-2020(IANA1) } id-mod-anima-acpnodename-2020(97) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
OTHER-NAME OTHER-NAME
FROM PKIX1Implicit-2009 FROM PKIX1Implicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-implicit-02(59) } id-mod-pkix1-implicit-02(59) }
skipping to change at line 701 skipping to change at line 1262
id-mod-pkix1-explicit-02(51) } ; id-mod-pkix1-explicit-02(51) } ;
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
AcpNodeNameOtherNames OTHER-NAME ::= { on-AcpNodeName, ... } AcpNodeNameOtherNames OTHER-NAME ::= { on-AcpNodeName, ... }
on-AcpNodeName OTHER-NAME ::= { on-AcpNodeName OTHER-NAME ::= {
AcpNodeName IDENTIFIED BY id-on-AcpNodeName AcpNodeName IDENTIFIED BY id-on-AcpNodeName
} }
id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on IANA2 } id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on 10 }
AcpNodeName ::= IA5String (SIZE (1..MAX)) AcpNodeName ::= IA5String (SIZE (1..MAX))
-- AcpNodeName as specified in this document carries the -- AcpNodeName as specified in this document carries the
-- acp-node-name as specified in the ABNF in Section 6.1.2 -- acp-node-name as specified in the ABNF in Section 6.2.2
END END
]]></artwork> </sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<!-- domcert-acpinfo --> <section anchor="certcheck" numbered="true" toc="include" removeInRFC="f
<section anchor="certcheck" numbered="true" toc="default"> alse" pn="section-6.2.3">
<name>ACP domain membership check</name> <name slugifiedName="name-acp-domain-membership-check">ACP Domain Memb
<t>The following points constitute the ACP domain membership check of ership Check</name>
a candidate peer via its certificate: <t indent="0" pn="section-6.2.3-1">The following points constitute the
</t> ACP domain membership check of a candidate peer via its certificate:
<dl spacing="compact"> </t>
<dt>1: </dt> <ol spacing="normal" group="acp" start="1" indent="adaptive" type="1"
<dd>The peer has proved ownership of the private key associated with pn="section-6.2.3-2">
the certificate's public key. This check is performed by the security associati <li anchor="step1" pn="section-6.2.3-2.1" derivedCounter="1.">The pe
on protocol used, for example <xref target="RFC7296" format="default"/>, section er has proved ownership of the private key associated
2.15.</dd> with the certificate's public key. This check is performed by the
<dt>2: </dt> security association protocol used, for example, Section <xref target
<dd>The peer's certificate passes certificate path validation as def ="RFC7296" section="2.15" sectionFormat="bare" format="default" derivedLink="htt
ined in <xref target="RFC5280" format="default"/>, section 6 against one of the ps://rfc-editor.org/rfc/rfc7296#section-2.15" derivedContent="RFC7296"/> of <xre
TA associated with the ACP node's ACP certificate (see <xref target="trust-ancho f target="RFC7296" format="default" sectionFormat="of" derivedContent="RFC7296">
rs" format="default"/> below). This includes verification of the validity (lifet "Internet Key Exchange Protocol Version 2 (IKEv2)"</xref>.</li>
ime) of the certificates in the path.</dd> <li anchor="step2" pn="section-6.2.3-2.2" derivedCounter="2.">The pe
<dt>3: </dt> er's certificate passes certificate path validation as
<dd>If the peer's certificate indicates a Certificate Revocation Lis defined in <xref target="RFC5280" sectionFormat="comma" section="6" f
t (CRL) Distribution Point (CRLDP) ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-6" deriv
(<xref target="RFC5280" format="default"/>, section 4.2.1.13) or On edContent="RFC5280"/>, against one of the TAs associated with the ACP node's ACP
line Certificate Status Protocol (OCSP) responder certificate (see <xref target="trust-anchors" format="default" sectionFormat="o
(<xref target="RFC5280" format="default"/>, section 4.2.2.1), then f" derivedContent="Section 6.2.4"/>). This includes verification of the validity
the peer's certificate MUST be valid according to those (lifetime) of the certificates in the path.</li>
mechanisms when they are available: An OCSP check for the peer's ce <li anchor="step3" pn="section-6.2.3-2.3" derivedCounter="3.">
rtificate across the ACP must succeed or the peer certificate must not be listed <t indent="0" pn="section-6.2.3-2.3.1">If the peer's certificate i
in the CRL retrieved from the CRLDP. These mechanisms are not available ndicates a CRLDP
(<xref target="RFC5280" sectionFormat="comma" section="4.2.1.13" fo
rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.1.13"
derivedContent="RFC5280"/>) or OCSP responder
(<xref target="RFC5280" sectionFormat="comma" section="4.2.2.1" for
mat="default" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-4.2.2.1" d
erivedContent="RFC5280"/>), then the peer's certificate <bcp14>MUST</bcp14> be v
alid according to those
mechanisms when they are available: an OCSP check for the peer's ce
rtificate across the ACP must succeed, or the peer's certificate must not be lis
ted in the CRL retrieved from the CRLDP. These mechanisms are not available
when the ACP node has no ACP or non-ACP connectivity to retrieve a current CRL when the ACP node has no ACP or non-ACP connectivity to retrieve a current CRL
or access an OCSP responder and the security association protocol i or has no access an OCSP responder, and the security association pr
tself has also no way to communicate CRL or OCSP check.</dd> otocol itself also has no way to communicate the CRL or OCSP check.</t>
<dt> </dt> <t indent="0" pn="section-6.2.3-2.3.2">Retries to learn revocation
<dd>Retries to learn revocation via OCSP/CRL SHOULD be made using th via OCSP or CRL <bcp14>SHOULD</bcp14> be made using the same backoff as describ
e same backoff as described in <xref target="neighbor_verification" format="defa ed in <xref target="neighbor_verification" format="default" sectionFormat="of" d
ult"/>. If and when the ACP node then learns that an ACP peer's certificate is i erivedContent="Section 6.7"/>. If and when the ACP node then learns that an ACP
nvalid for which rule 3 had to be skipped during ACP secure channel establishmen peer's certificate is invalid for which <xref target="step3" format="none" secti
t, then the ACP secure channel to that peer MUST be closed even if this peer is onFormat="of" derivedContent="">Rule 3</xref> had to be skipped during ACP secur
the only connectivity to access CRL/OCSP. This applies (of course) to all ACP se e channel establishment, then the ACP secure channel to that peer <bcp14>MUST</b
cure channels to this peer if there are multiple. The ACP secure channel connec cp14> be closed even if this peer is the only connectivity to access CRL/OCSP. T
tion MUST be retried periodically to support the case that the neighbor acquires his applies (of course) to all ACP secure channels to this peer if there are mul
a new, valid certificate.</dd> tiple. The ACP secure channel connection <bcp14>MUST</bcp14> be retried periodi
<dt>4: </dt> cally to support the case that the neighbor acquires a new, valid certificate.</
<dd>The peer's certificate has a syntactically valid acp-node-name f t>
ield </li>
and the acp-domain-name in that peer's acp-node-name is the same as <li anchor="step4" pn="section-6.2.3-2.4" derivedCounter="4.">The pe
in this ACP node's certificate (lowercase normalized).</dd> er's certificate has a syntactically valid acp-node-name field,
</dl> and the acp-domain-name in that peer's acp-node-name is the same as
<t>When checking a candidate peer's certificate for the purpose of est in this ACP node's certificate (lowercase normalized).</li>
ablishing an ACP secure channel, </ol>
<t indent="0" pn="section-6.2.3-3">When checking a candidate peer's ce
rtificate for the purpose of establishing an ACP secure channel,
one additional check is performed: one additional check is performed:
</t>
</t> <ol group="acp" start="5" indent="adaptive" spacing="normal" type="1"
<dl spacing="compact"> pn="section-6.2.3-4">
<dt>5: </dt> <li anchor="step5" pn="section-6.2.3-4.1" derivedCounter="5.">The acp-address fi
<dd>The acp-address field of the candidate peer certificate's AcpNod eld of the candidate peer certificate's AcpNodeName is not omitted but is either
eName is not omitted but either 32HEXDIG or 0, according to <xref target="acp-do 32HEXDIG or 0, according to <xref target="acp-dominfo-abnf" format="default" se
minfo-abnf" format="default"/>.</dd> ctionFormat="of" derivedContent="Figure 2"/>.</li>
</dl> </ol>
<t>Technically, ACP secure channels can only be built with nodes that <t indent="0" pn="section-6.2.3-5">Technically, ACP secure channels ca
have an acp-address. Rule 5 ensures that this is taken into account n only be built with nodes that
have an acp-address. <xref target="step5" format="none" sectionFormat="
of" derivedContent="">Rule 5</xref> ensures that this is taken into account
during ACP domain membership check.</t> during ACP domain membership check.</t>
<t>Nodes with an omitted acp-address field can only use their ACP doma <t indent="0" pn="section-6.2.3-6">Nodes with an omitted acp-address f
in ield can only use their ACP domain
certificate for non-ACP-secure channel authentication purposes. certificate for non-ACP secure channel authentication purposes.
This includes for example NMS type nodes permitted to communicate This includes, for example, NMS type nodes permitted to communicate
into the ACP via <xref target="ACPconnect" format="default">ACP connect into the ACP via <xref target="ACPconnect" format="default" sectionForm
</xref></t> at="of" derivedContent="Section 8.1">ACP connect</xref></t>
<t> The special value 0 in an ACP certificates acp-address field <t indent="0" pn="section-6.2.3-7"> The special value "0" in an ACP ce
rtificate's acp-address field
is used for nodes that can and should determine their ACP address is used for nodes that can and should determine their ACP address
through other mechanisms than learning it through the acp-address through mechanisms other than learning it through the acp-address
field in their ACP certificate. These ACP nodes are permitted field in their ACP certificate. These ACP nodes are permitted
to establish ACP secure channels. Mechanisms for those nodes to to establish ACP secure channels. Mechanisms for those nodes to
determine their ACP address are outside the scope of this determine their ACP address are outside the scope of this
specification, but this option is defined here so that any specification, but this option is defined here so that any
ACP nodes can build ACP secure channels to them according to Rule 5.</ ACP nodes can build ACP secure channels to them according to <xref tar
t> get="step5" format="none" sectionFormat="of" derivedContent="">Rule 5.</xref></t
>
<t>The optional rsub field of the AcpNodeName is not relevant to the <t indent="0" pn="section-6.2.3-8">The optional rsub field of the AcpN
odeName is not relevant to the
ACP domain membership check because it only serves to structure routin g and ACP domain membership check because it only serves to structure routin g and
addressing within an ACP but not to segment mutual authentication/auth orization addressing within an ACP but not to segment mutual authentication and authorization
(hence the name "routing subdomain").</t> (hence the name "routing subdomain").</t>
<t indent="0" pn="section-6.2.3-9">In summary:
<t>In summary: </t>
</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<ul spacing="compact"> -6.2.3-10">
<li>Steps 1...4 constitute standard certificate validity verificatio <li pn="section-6.2.3-10.1">
n and private key authentication as defined by <xref target="RFC5280" format="de <xref target="step1" format="none" sectionFormat="of" derivedConte
fault"/> and security association protocols (such as Internet Key Exchange Proto nt="">Steps 1 through 4</xref> constitute standard certificate validity verifica
col version 2 <xref target="RFC7296" format="default">IKEv2</xref> when leveragi tion and private key authentication as defined by <xref target="RFC5280" format=
ng certificates. </li> "default" sectionFormat="of" derivedContent="RFC5280"/> and security association
<li>Steps 1...4 do not include verification of any pre-existing form protocols (such as <xref target="RFC7296" format="default" sectionFormat="of" d
of non-public-key-only based identity elements of a certificate such as a web s erivedContent="RFC7296">IKEv2</xref>) when leveraging certificates. </li>
ervers domain name prefix often encoded in certificate common name. Step 5 is an <li pn="section-6.2.3-10.2">Except for its public key, <xref target=
equivalent step for the AcpNodeName.</li> "step1" format="none" sectionFormat="of" derivedContent="">Steps 1 through 4</xr
<li>Step 4 constitutes standard CRL/OCSP checks refined for the case ef> do not include the verification of any preexisting
of missing connectivity and limited functionality security association protocol form of a certificate's identity
s.</li> elements, such as a web server's domain name prefix, which is
<li>Steps 1...4 authorize to build any secure connection between mem often encoded in the certificate common name. <xref target="step5" format=
bers of the same ACP domain except for ACP secure channels.</li> "none" sectionFormat="of" derivedContent="">Step 5</xref> is an equivalent step
<li>Step 5 is the additional verification of the presence of an ACP for the AcpNodeName.</li>
address as necessary for ACP secure channels.</li> <li pn="section-6.2.3-10.3">
<li>Steps 1...5 therefore authorize to build an ACP secure channel.< <xref target="step4" format="none" sectionFormat="of" derivedConte
/li> nt="">Step 4</xref> constitutes standard CRL and OCSP checks refined for the cas
e of missing connectivity and limited-functionality security association protoco
ls.</li>
<li pn="section-6.2.3-10.4">
<xref target="step1" format="none" sectionFormat="of" derivedConte
nt="">Steps 1 through 4</xref> authorize the building of any secure connection b
etween members of the same ACP domain except for ACP secure channels.</li>
<li pn="section-6.2.3-10.5">
<xref target="step5" format="none" sectionFormat="of" derivedConte
nt="">Step 5</xref> is the additional verification of the presence of an ACP add
ress as necessary for ACP secure channels.</li>
<li pn="section-6.2.3-10.6">
<xref target="step1" format="none" sectionFormat="of" derivedConte
nt="">Steps 1 through 5</xref> therefore authorize the building of an ACP secure
channel.</li>
</ul> </ul>
<t>For brevity, the remainder of this document refers to this process <t indent="0" pn="section-6.2.3-11">For brevity, the remainder of this
only as authentication instead of as authentication and authorization.</t> document refers to this process only as authentication instead of as authentica
tion and authorization.</t>
<t>[RFC-Editor: Please remove the following paragraph].</t> <section anchor="cert-time" numbered="true" toc="include" removeInRFC=
<t>Note that the ACP domain membership check does not verify the netwo "false" pn="section-6.2.3.1">
rk layer address of the security association. See <xref target="ACPDRAFT"/>, App <name slugifiedName="name-realtime-clock-and-time-val">Realtime Cloc
endix B.2 for explanations.</t> k and Time Validation</name>
<t indent="0" pn="section-6.2.3.1-1">An ACP node with a realtime clo
<section anchor="cert-time" numbered="true" toc="default"> ck in which it has confidence <bcp14>MUST</bcp14>
<name>Realtime clock and Time Validation</name> check the timestamps when performing an ACP domain membership check,
<t>An ACP node with a realtime clock in which it has confidence, MUS such
T as checking the certificate validity period in <xref target="step1"
check the time stamps when performing ACP domain membership check su format="none" sectionFormat="of" derivedContent="">Step 1</xref> and the respect
ch ive
as the certificate validity period in step 1. and the respective times in <xref target="step4" format="none" sectionFormat="of" deriv
times in step 4 for revocation information (e.g., signingTimes in CM edContent="">Step 4</xref> for revocation information (e.g., signingTimes in Cry
S signatures).</t> ptographic Message Syntax (CMS) signatures).</t>
<t>An ACP node without such a realtime clock MAY ignore those time <t indent="0" pn="section-6.2.3.1-2">An ACP node without such a real
stamp validation steps if it does not know the current time. time clock <bcp14>MAY</bcp14> ignore those timestamp
Such an ACP node SHOULD obtain the current time in a validation steps if it does not know the current time.
secured fashion, such as via a Network Time Protocol signaled throug Such an ACP node <bcp14>SHOULD</bcp14> obtain the current time in a
h the ACP. secured fashion, such as via NTP signaled through the ACP.
It then ignores time stamp validation only until the current time is It then ignores timestamp validation only until the current time is
known. known.
In the absence of implementing a secured mechanism, such an ACP node In the absence of implementing a secured mechanism, such an ACP node
MAY <bcp14>MAY</bcp14>
use a current time learned in an insecure fashion in the ACP domain membership use a current time learned in an insecure fashion in the ACP domain membership
check.</t> check.</t>
<t>Current time MAY for example be learned unsecured via NTP (<xref target="RFC5905" format="default"/>) <t indent="0" pn="section-6.2.3.1-3">Current time <bcp14>MAY</bcp14> be learned in an unsecured fashion, for example, via NTP ("<xref target="RFC590 5" format="title" sectionFormat="of" derivedContent="Network Time Protocol Versi on 4: Protocol and Algorithms Specification"/>" <xref target="RFC5905" format="d efault" sectionFormat="of" derivedContent="RFC5905"/>)
over the same link-local IPv6 addresses used for the ACP from neighb oring ACP nodes. over the same link-local IPv6 addresses used for the ACP from neighb oring ACP nodes.
ACP nodes that do provide NTP insecure over their link-local address es SHOULD ACP nodes that do provide unsecured NTP over their link-local addres ses <bcp14>SHOULD</bcp14>
primarily run NTP across the ACP and provide NTP time across the ACP only primarily run NTP across the ACP and provide NTP time across the ACP only
when they have a trusted time source. Details for such NTP procedure s are beyond the when they have a trusted time source. Details for such NTP procedure s are beyond the
scope of this specification.</t> scope of this specification.</t>
<t>Beside ACP domain membership check, the ACP itself has no <t indent="0" pn="section-6.2.3.1-4">Besides the ACP domain membersh
dependency against knowledge of the current time, but protocols ip check, the ACP itself has no
and services using the ACP will likely have the need to know dependency on knowing the current time, but protocols
the current time. For example, event logging.</t> and services using the ACP, for example, event logging, will likely
need to know
the current time.</t>
</section> </section>
</section> </section>
<section anchor="trust-anchors" numbered="true" toc="default"> <section anchor="trust-anchors" numbered="true" toc="include" removeInRF
<name>Trust Anchors (TA)</name> C="false" pn="section-6.2.4">
<t>ACP nodes need TA information according to <xref target="RFC5280" <name slugifiedName="name-trust-anchors-ta">Trust Anchors (TA)</name>
format="default"/>, <t indent="0" pn="section-6.2.4-1">ACP nodes need TA information accor
section 6.1.1 (d), typically in the form of one or more certificate of the TA to ding to <xref target="RFC5280" sectionFormat="comma" section="6.1.1" format="def
perform certificate ault" derivedLink="https://rfc-editor.org/rfc/rfc5280#section-6.1.1" derivedCont
path validation as required by <xref target="certcheck" format="default"/>, rule ent="RFC5280"/> (d), typically in the form of one or more certificates of the TA
2. to perform certificate
TA information MUST be provisioned to an ACP node (together with its ACP path validation as required by <xref target="step2" format="none" sectionFormat=
domain certificate) by an ACP Registrar during initial enrollment of a candidate "of" derivedContent="">Section 6.2.3, Rule 2</xref>.
ACP node. ACP nodes MUST also support renewal of TA information via TA information <bcp14>MUST</bcp14> be provisioned to an ACP node (together with
EST as described below in <xref target="domcert-maint" format="default"/>.</t> its ACP
domain certificate) by an ACP registrar during initial enrollment of a candidate
<t>The required information about a TA can consist of not only a singl ACP node. ACP nodes <bcp14>MUST</bcp14> also support the renewal of TA informati
e, but on via
multiple certificates as required for dealing with CA certificate renewals EST as described in <xref target="domcert-maint" format="default" sectionFormat=
as explained in Section 4.4 of CMP (<xref target="RFC4210" format="default"/>).< "of" derivedContent="Section 6.2.5"/>.</t>
/t> <t indent="0" pn="section-6.2.4-2">The required information about a TA
<t>A certificate path is a chain of certificates starting at can consist of
the ACP certificate (leaf/end-entity) followed by zero or more one or more
intermediate CA certificates and ending with the TA information, certificates as required for dealing with CA certificate renewals
which are typically one or two the self-signed certificates of the TA. The as explained in Section <xref target="RFC4210" section="4.4" sectionFormat="bare
" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4210#section-4.4"
derivedContent="RFC4210"/> of <xref target="RFC4210" format="default" sectionFor
mat="of" derivedContent="RFC4210">"Internet X.509 Public Key Infrastructure Cert
ificate Management Protocol (CMP)"</xref>).</t>
<t indent="0" pn="section-6.2.4-3">A certificate path is a chain of ce
rtificates starting at
the ACP certificate (the leaf and/or end entity), followed by zero or more
intermediate CA certificates, and ending with the TA information,
which is typically one or two self-signed certificates of the TA. The
CA that signs the ACP certificate is called the assigning CA. CA that signs the ACP certificate is called the assigning CA.
If there are no intermediate CA, then the assigning CA is the TA. If there are no intermediate CAs, then the assigning CA is the TA.
Certificate path validation authenticates that the ACP certificate is permitted Certificate path validation authenticates that the TA associated with the ACP pe
by a TA associated with the ACP, directly or indirectly via one or more intermed rmits the ACP certificate, either directly or indirectly via one or more interme
iate diate
CA.</t> CA.</t>
<t>Note that different ACP nodes may have different intermediate CA <t indent="0" pn="section-6.2.4-4">Note that different ACP nodes may h
in their certificate path and even different TA. The set of TA for ave different intermediate CAs
in their certificate path and even different TA. The set of TAs for
an ACP domain must be consistent across all ACP members so that any ACP node an ACP domain must be consistent across all ACP members so that any ACP node
can authenticate any other ACP node. The protocols through which can authenticate any other ACP node. The protocols through which the
ACP domain membership check rules 1-3 are performed need to support ACP domain membership check <xref target="step1" format="none" sectionFormat="of
the exchange not only of the ACP nodes certificates, but also exchange of " derivedContent="">Rules 1 through 3</xref> are performed need to support
the intermedia TA.</t> the exchange not only of the ACP nodes certificates but also the exchange of
<t>ACP nodes MUST support for the ACP domain membership check the cert the intermediate TA.</t>
ificate path <t indent="0" pn="section-6.2.4-5">For the ACP domain membership check
validation with 0 or 1 intermediate CA. They SHOULD support 2 intermediate CA , ACP nodes <bcp14>MUST</bcp14> support certificate path
and two TA (to permit migration to from one TA to another TA).</t> validation with zero or one intermediate CA. They <bcp14>SHOULD</bcp14> support
<t>Certificates for an ACP MUST only be given to nodes that are allowe two intermediate CAs
d and two TAs (to permit migration from one TA to another TA).</t>
to be members of that ACP. When the signing CA relies on an ACP <t indent="0" pn="section-6.2.4-6">Certificates for an ACP <bcp14>MUST
Registrar, the CA MUST only sign certificates with acp-node-name </bcp14> only be given to nodes that are allowed
through trusted ACP Registrars. In this setup, any existing CA, unaware of the f to be members of that ACP. When the signing CA relies on an ACP registrar,
ormatting the CA <bcp14>MUST</bcp14> only sign certificates with acp-node-name
through trusted ACP registrars. In this setup, any existing CA, unaware of the f
ormatting
of acp-node-name, can be used.</t> of acp-node-name, can be used.</t>
<t>These requirements can be achieved by using a TA private to the own er of <t indent="0" pn="section-6.2.4-7">These requirements can be achieved by using a TA private to the owner of
the ACP domain or potentially through appropriate contractual agreements between the ACP domain or potentially through appropriate contractual agreements between
the involved parties (Registrar and CA). Using public CA is out of scope of thi the involved parties (registrar and CA). Using a public CA is out of scope of t
s his
document. [RFC-Editor: please remove the following sentence]. See <xref target=" document. </t>
ACPDRAFT"/>, Appendix B.3 for further considerations.</t> <t indent="0" pn="section-6.2.4-8">A single owner can operate multiple
, independent ACP domains from the same
<t>A single owner can operate multiple independent ACP domains from th set of TAs. Registrars must then know into which ACP a node needs to be enrolled
e same .</t>
set of TA. Registrars must then know which ACP a node needs to be enrolled into.
</t>
</section> </section>
<section anchor="domcert-maint" numbered="true" toc="default"> <section anchor="domcert-maint" numbered="true" toc="include" removeInRF
<name>Certificate and Trust Anchor Maintenance</name> C="false" pn="section-6.2.5">
<name slugifiedName="name-certificate-and-trust-ancho">Certificate and
<t>ACP nodes MUST support renewal of their Certificate and TA informat Trust Anchor Maintenance</name>
ion via EST <t indent="0" pn="section-6.2.5-1">ACP nodes <bcp14>MUST</bcp14> suppo
and MAY support other mechanisms. See <xref target="tls" format="default"/> for rt renewal of their certificate and TA information via EST
TLS requirements. and <bcp14>MAY</bcp14> support other mechanisms. See <xref target="tls" format=
An ACP network MUST have at least one ACP node supporting EST server functionali "default" sectionFormat="of" derivedContent="Section 6.1"/> for TLS requirements
ty across the ACP so that EST .
renewal is useable.</t> An ACP network <bcp14>MUST</bcp14> have at least one ACP node supporting EST ser
ver functionality across the ACP so that EST
<t>ACP nodes SHOULD be able to remember the IPv6 locator parameters of renewal is usable.</t>
the O_IPv6_LOCATOR in GRASP of the EST server from which they last <t indent="0" pn="section-6.2.5-2">ACP nodes <bcp14>SHOULD</bcp14> rem
renewed their ACP certificate. They SHOULD provide the ability ember the GRASP O_IPv6_LOCATOR parameters of
for these EST server parameters to also be set by the ACP Registrar the EST server with which they last renewed their ACP certificate.
(see <xref target="acp-registrars" format="default"/>) that initially enrolled t They <bcp14>SHOULD</bcp14> provide the ability
he ACP for these EST server parameters to also be set by the ACP registrar
device with its ACP certificate. When BRSKI (see <xref target="I-D.ietf-anima-bo (see <xref target="acp-registrars" format="default" sectionFormat="of" derivedCo
otstrapping-keyinfra" format="default"/>) ntent="Section 6.11.7"/>) that initially enrolled the ACP
is used, the IPv6 locator of the BRSKI registrar from the BRSKI TLS device with its ACP certificate. When BRSKI
connection SHOULD be remembered and used for the next renewal via is used (see <xref target="RFC8995" format="default" sectionFormat="of" derivedC
ontent="RFC8995"/>), the IPv6 locator of the BRSKI registrar from the BRSKI TLS
connection <bcp14>SHOULD</bcp14> be remembered and used for the next renewal via
EST if that registrar also announces itself as an EST server EST if that registrar also announces itself as an EST server
via GRASP (see next section) on its ACP address.</t> via GRASP on its ACP address (see <xref target="domcert-grasp" format="default"
<t>The EST server MUST present a certificate that is passing ACP domai sectionFormat="of" derivedContent="Section 6.2.5.1"/>).</t>
n <t indent="0" pn="section-6.2.5-3">The EST server <bcp14>MUST</bcp14>
membership check in its TLS connection setup (<xref target="certcheck" format="d present a certificate that passes the ACP domain
efault"/>, membership check in its TLS connection setup (<xref target="step1" format="none"
rules 1...4, not rule 5 as this is not for an ACP secure channel setup). sectionFormat="of" derivedContent="">Section 6.2.3, rules 1 through 4</xref>, n
The EST server certificate MUST also contain the id-kp-cmcRA <xref target="RFC64 ot <xref target="step5" format="none" sectionFormat="of" derivedContent="">rule
02" format="default"/> 5</xref> as this is not for an ACP secure channel setup).
extended key usage attribute and the EST client MUST check its presence.</t> The EST server certificate <bcp14>MUST</bcp14> also contain the id-kp-cmcRA
<t>The additional check against the id-kp-cmcRA extended key usage ext extended key usage attribute <xref target="RFC6402" format="default" sectionForm
ension field at="of" derivedContent="RFC6402"/>, and the EST client <bcp14>MUST</bcp14> check
its presence.</t>
<t indent="0" pn="section-6.2.5-4">The additional check against the id
-kp-cmcRA extended key usage extension field
ensures that clients do not fall prey to an illicit EST server. While such ensures that clients do not fall prey to an illicit EST server. While such
illicit EST servers should not be able to support certificate signing requests ( as they illicit EST servers should not be able to support certificate signing requests ( as they
are not able to elicit a signing response from a valid CA), such an illicit EST server would are not able to elicit a signing response from a valid CA), such an illicit EST server would
be able to provide faked CA certificates to EST clients that need to renew their be able to provide faked CA certificates to EST clients that need to renew their
CA certificates when they expire.</t> CA certificates when they expire.</t>
<t>Note that EST servers supporting multiple ACP domains will need to <t indent="0" pn="section-6.2.5-5">Note that EST servers supporting mu
have for each ltiple ACP domains will need to have
of these ACP domains a separate certificate and respond on a different transport a separate certificate for each of these ACP domains and respond on a different
address (IPv6 address and/or TCP port), but this is easily automated on the transport
EST server as long as the CA does not restrict registrars to request certificate address (IPv6 address and/or TCP port). This is easily automated on the
s EST server if the CA allows registrars to request certificates
with the id-kp-cmcRA extended usage extension for themselves.</t> with the id-kp-cmcRA extended usage extension for themselves.</t>
<section anchor="domcert-grasp" numbered="true" toc="default"> <section anchor="domcert-grasp" numbered="true" toc="include" removeIn
<name>GRASP objective for EST server</name> RFC="false" pn="section-6.2.5.1">
<t>ACP nodes that are EST servers MUST announce their service via GR <name slugifiedName="name-grasp-objective-for-est-ser">GRASP Objecti
ASP in the ACP ve for EST Server</name>
through M_FLOOD messages. See <xref target="I-D.ietf-anima-grasp" format="defaul <t indent="0" pn="section-6.2.5.1-1">ACP nodes that are EST servers
t"/>, <bcp14>MUST</bcp14> announce their service in the ACP via GRASP
section 2.8.11 for the definition of this message type:</t> Flood Synchronization (M_FLOOD) messages. See <xref target="RFC8990" sectionForm
<figure anchor="est-example"> at="comma" section="2.8.11" format="default" derivedLink="https://rfc-editor.org
<name>GRASP SRV.est example</name> /rfc/rfc8990#section-2.8.11" derivedContent="RFC8990"/> for the definition of th
<artwork name="" type="" align="left" alt=""><![CDATA[ is message type
Example: and <xref target="est-example" format="default" sectionFormat="of" derivedConten
t="Figure 4"/> for an example.</t>
[M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, <figure anchor="est-example" align="left" suppress-title="false" pn=
[["SRV.est", 4, 255 ], "figure-4">
[O_IPv6_LOCATOR, <name slugifiedName="name-grasp-srvest-objective-exam">GRASP "SRV.
h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] est" Objective Example</name>
] <sourcecode name="" type="" markers="false" pn="section-6.2.5.1-2.
]]></artwork> 1">
[M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000,
[["SRV.est", 4, 255 ],
[O_IPv6_LOCATOR,
h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]]
]
</sourcecode>
</figure> </figure>
<t> The formal definition of the objective in Concise data definitio <t indent="0" pn="section-6.2.5.1-3"> The formal definition of the o
n language (CDDL) bjective in CDDL
(see <xref target="RFC8610" format="default"/>) is as follows: </t> (see "<xref target="RFC8610" format="title" sectionFormat="of" derivedContent
<figure anchor="est-def"> ="Concise Data Definition Language (CDDL): A Notational Convention to Express Co
<name>GRASP SRV.est definition</name> ncise Binary Object Representation (CBOR) and JSON Data Structures"/>" <xref tar
<artwork name="" type="" align="left" alt=""><![CDATA[ get="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>) is
flood-message = [M_FLOOD, session-id, initiator, ttl, as follows: </t>
+[objective, (locator-option / [])]] <figure anchor="est-def-fig" align="left" suppress-title="false" pn=
; see example above and explanation "figure-5">
; below for initiator and ttl <name slugifiedName="name-grasp-srvest-definition">GRASP "SRV.est"
Definition</name>
objective = ["SRV.est", objective-flags, loop-count, <sourcecode name="" type="cddl" markers="false" pn="section-6.2.5.
objective-value] 1-4.1">
flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]]
; See example above and explanation
; below for initiator and ttl.
objective-flags = sync-only ; as in GRASP spec objective = ["SRV.est", objective-flags, loop-count,
sync-only = 4 ; M_FLOOD only requires synchronization objective-value]
loop-count = 255 ; recommended as there is no mechanism
; to discover network diameter.
objective-value = any ; reserved for future extensions
]]></artwork> objective-flags = sync-only ; As in [RFC8990].
sync-only = 4 ; M_FLOOD only requires synchronization.
loop-count = 255 ; Recommended as there is no mechanism
; to discover network diameter.
objective-value = any ; Reserved for future extensions.
</sourcecode>
</figure> </figure>
<t>The objective name "SRV.est" indicates that the objective is an <t indent="0" pn="section-6.2.5.1-5">The objective name "SRV.est" in
<xref target="RFC7030" format="default"/> compliant EST server because "est" is dicates that the objective is an EST server compliant with
an <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC70
<xref target="RFC6335" format="default"/> registered service name for <xref targ 30"/> because "est" is a
et="RFC7030" format="default"/>. registered service name ("<xref target="RFC6335" format="title" sectionFormat="o
Objective-value MUST be ignored if present. Backward compatible extensions to f" derivedContent="Internet Assigned Numbers Authority (IANA) Procedures for the
<xref target="RFC7030" format="default"/> MAY be indicated through objective-val Management of the Service Name and Transport Protocol Port Number Registry"/>"
ue. <xref target="RFC6335" format="default" sectionFormat="of" derivedContent="RFC63
Non <xref target="RFC7030" format="default"/> compatible certificate renewal opt 35"/>) for <xref target="RFC7030" format="default" sectionFormat="of" derivedCon
ions MUST use a different objective-name. tent="RFC7030"/>.
Non-recognized objective-values (or parts thereof if it is a structure partially The 'objective-value' field <bcp14>MUST</bcp14> be ignored if present. Backward-
understood) MUST be ignored.</t> compatible extensions to
<t>The M_FLOOD message MUST be sent periodically. The default SHOUL <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC70
D be 60 seconds; 30"/> <bcp14>MAY</bcp14> be indicated through 'objective-value'.
the value SHOULD be operator configurable but SHOULD be Certificate renewal options that are incompatible with <xref target="RFC7030" fo
not smaller than 60 seconds. The frequency of sending MUST be such rmat="default" sectionFormat="of" derivedContent="RFC7030"/> <bcp14>MUST</bcp14>
use a different 'objective-name'.
Unrecognized 'objective-value' fields (or parts thereof if it is a partially und
erstood structure) <bcp14>MUST</bcp14> be ignored.</t>
<t indent="0" pn="section-6.2.5.1-6">The M_FLOOD message <bcp14>MUST
</bcp14> be sent periodically. The default <bcp14>SHOULD</bcp14> be 60 seconds;
the value <bcp14>SHOULD</bcp14> be operator configurable but <bcp14>SHOULD</bcp1
4> be
not smaller than 60 seconds. The frequency of sending <bcp14>MUST</bcp14> be su
ch
that the aggregate amount of periodic M_FLOODs from all flooding sources that the aggregate amount of periodic M_FLOODs from all flooding sources
cause only negligible traffic across the ACP. The time-to-live (ttl) parameter cause only negligible traffic across the ACP. The time-to-live (ttl) parameter
SHOULD be 3.5 times the period so that up <bcp14>SHOULD</bcp14> be 3.5 times the period so that up
to three consecutive messages can be dropped before considering an announcement to three consecutive messages can be dropped before an announcement is considere
expired. d expired.
In the example above, the ttl is 210000 msec, 3.5 times 60 seconds. When a servi In the example above, the ttl is 210000 msec, that is, 3.5 times 60 seconds. Whe
ce announcer n a service announcer
using these parameters unexpectedly dies immediately after sending the M_FLOOD, using these parameters unexpectedly dies immediately after sending the M_FLOOD,
receivers would consider it expired 210 seconds later. When a receiver tries to receivers would consider it expired 210 seconds later. When a receiver tries to
connect to this dead service before this timeout, it will experience a failing c onnection and connect to this dead service before this timeout, it will experience a failing c onnection and
use that as an indication that the service instance is dead and select another i nstance of the use that as an indication that the service instance is dead and select another i nstance of the
same service instead (from another GRASP announcement).</t> same service instead (from another GRASP announcement).</t>
<t>The "SRV.est" objective(s) SHOULD only be announced when the ACP node knows t <t indent="0" pn="section-6.2.5.1-7">The "SRV.est" objective(s) <bcp
hat it can successfully 14>SHOULD</bcp14> only be announced when the ACP node knows that it can successf
communicate with a CA to perform the EST renewal/rekeying operations for the ACP ully
domain. See also communicate with a CA to perform the EST renewal and/or rekeying operations for
<xref target="security"/>.</t> the ACP domain. See also
<xref target="security" format="default" sectionFormat="of" derivedContent="Sect
ion 11"/>.</t>
</section> </section>
<section anchor="domcert-renewal" numbered="true" toc="default"> <section anchor="domcert-renewal" numbered="true" toc="include" remove
<name>Renewal</name> InRFC="false" pn="section-6.2.5.2">
<t>When performing renewal, the node SHOULD attempt to connect to th <name slugifiedName="name-renewal">Renewal</name>
e remembered EST server. <t indent="0" pn="section-6.2.5.2-1">When performing renewal, the no
If that fails, it SHOULD attempt to connect to an EST server learned via GRASP. de <bcp14>SHOULD</bcp14> attempt to connect to the remembered EST server.
The server If that fails, it <bcp14>SHOULD</bcp14> attempt to connect to an EST server lear
with which certificate renewal succeeds SHOULD be remembered for the next renewa ned via GRASP. The server
l.</t> with which certificate renewal succeeds <bcp14>SHOULD</bcp14> be remembered for
<t>Remembering the last renewal server and preferring it provides st the next renewal.</t>
ickiness <t indent="0" pn="section-6.2.5.2-2">Remembering the last renewal se
which can help diagnostics. It also provides some protection against off-path rver and preferring it provides stickiness
that can help diagnostics. It also provides some protection against off-path,
compromised ACP members announcing bogus information into GRASP.</t> compromised ACP members announcing bogus information into GRASP.</t>
<t>Renewal of certificates SHOULD start after less than 50% of the d <t indent="0" pn="section-6.2.5.2-3">Renewal of certificates <bcp14>
omain certificate SHOULD</bcp14> start after less than 50% of the domain certificate
lifetime so that network operations has ample time to investigate and lifetime so that network operations have ample time to investigate and
resolve any problems that causes a node to not renew its domain certificate resolve any problems that cause a node to not renew its domain certificate
in time - and to allow prolonged periods of running parts of a network in time, and to allow prolonged periods of running parts of a network
disconnected from any CA.</t> disconnected from any CA.</t>
</section> </section>
<!-- DO NOT FORCE THE TTL=255 OPTION RIGHT NOW. <section anchor="domcert-crl" numbered="true" toc="include" removeInRF
IT MIGHT MAKE MORE SENSE TO DO FOLLOWUP WORK IN WHICH C="false" pn="section-6.2.5.3">
WE DO PROVIDE A MORE COMPLETE SET OF SELECTION OPTIONS <name slugifiedName="name-certificate-revocation-list">Certificate R
COMPATIBLE WITH DNS-SD - 10/2017, Toerless Eckert evocation Lists (CRLs)</name>
<t indent="0" pn="section-6.2.5.3-1">The ACP node <bcp14>SHOULD</bcp
<t>The locator-option indicates the ACP transport address for the EST server. 14> support revocation through CRL(s) via HTTP from one
The loop-count MUST be set to 255. When an ACP node receives the M_FLOOD, or more CRL Distribution Points (CRLDP). The CRLDP(s) <bcp14>MUST</bcp14> be in
it will have been reduced by the number of hops from the EST server.</t> dicated
in the domain certificate when used. If the CRLDP URL uses an IPv6 address
<t>When it is time for domain certificate renewal, the ACP node MUST
attempt to connect to the EST server(s) learned via GRASP starting with
the one that has the highest remaining loop-count (closest one). If
certificate renewal does not succeed, the node MUST attempt to use
the EST server(s) learned during initial provisioning/enrollment of
the certificate. After successful renewal of the domain certificate,
the ACP address from the certificate of the EST server as learned
during the handshake of the TLS connection to the EST server MAY be remembered
could be preferred for future renewal operations. As long
as that EST server is reachable, this provides stickiness in the selection of
the EST server and can simplify troubleshooting.</t>
<t>This logic of selecting an EST server for renewal is chosen to allow
for distributed EST servers to be used effectively but to also allow
fallback to the most reliably learned EST server - those that performed
already successful enrollment in before. A compromised (non EST-server)
ACP node for example can filter or fake GRASP announcements, but it can
not successfully renew a certificate and can only prohibit traffic to
a valid EST server when it is on the path between the ACP node and the
EST server.</t>
<section anchor="domcert-crl" numbered="true" toc="default">
<name>Certificate Revocation Lists (CRLs)</name>
<t>The ACP node SHOULD support revocation through CRL(s) via HTTP fr
om one
or more CRL Distribution Points (CRLDP). The CRLDP(s) MUST be indicated
in the Domain Certificate when used. If the CRLDP URL uses an IPv6 address
(ULA address when using the addressing rules specified in this document), (ULA address when using the addressing rules specified in this document),
the ACP node will connect to the CRLDP via the ACP. If the CRLDP uses a the ACP node will connect to the CRLDP via the ACP. If the CRLDP uses a
domain name, the ACP node will connect to the CRLDP via the Data-Plane.</t> domain name, the ACP node will connect to the CRLDP via the data plane.</t>
<t>It is common to use domain names for CRLDP(s), but there is no re <t indent="0" pn="section-6.2.5.3-2">It is common to use domain name
quirement s for CRLDP(s), but there is no requirement
for the ACP to support DNS. Any DNS lookup in the Data-Plane is for the ACP to support DNS. Any DNS lookup in the data plane is
not only a possible security issue, but it would also not indicate whether not only a possible security issue, but it would also not indicate whether
the resolved address is meant to be reachable across the ACP. Therefore, the resolved address is meant to be reachable across the ACP. Therefore,
the use of an IPv6 address versus the use of a DNS name doubles as an the use of an IPv6 address versus the use of a DNS name doubles as an
indicator whether or not to reach the CRLDP via the ACP.</t> indicator whether or not to reach the CRLDP via the ACP.</t>
<t>A CRLDP can be reachable across the ACP either by running it on a <t indent="0" pn="section-6.2.5.3-3">A CRLDP can be reachable across
node with ACP or by connecting its node via an ACP connect interface (see <xref the ACP either by running it on a
target="ACPconnect" format="default"/>).</t> node with ACP or by connecting its node via an ACP connect interface (see <xref
target="ACPconnect" format="default" sectionFormat="of" derivedContent="Section
<t>When using a private PKI for ACP certificates, the CRL may be need-to-know, f 8.1"/>).</t>
or example <t indent="0" pn="section-6.2.5.3-4">When using a private PKI for AC
P certificates, the CRL may be need-to-know, for example,
to prohibit insight into the operational practices of the domain by tracking to prohibit insight into the operational practices of the domain by tracking
the growth of the CRL. In this case, HTTPS may be chosen to provide the growth of the CRL. In this case, HTTPS may be chosen to provide
confidentiality, especially when making the CRL available via the Data-Plane. confidentiality, especially when making the CRL available via the data plane.
Authentication and authorization SHOULD use ACP certificates and ACP domain memb Authentication and authorization <bcp14>SHOULD</bcp14> use ACP certificates and
ership check. the ACP domain membership check (<xref target="certcheck" format="default" secti
The CRLDP MAY omit the CRL verification during authentication of the peer to per onFormat="of" derivedContent="Section 6.2.3"/>).
mit The CRLDP <bcp14>MAY</bcp14> omit the CRL verification during authentication of
retrieval of the CRL by an ACP node with revoked ACP certificate. This can allow the peer to permit
for that CRL retrieval by an ACP node with a revoked ACP certificate, which can allow the
(ex) ACP node to quickly discover its ACP certificate revocation. This may viola te (ex) ACP node to quickly discover its ACP certificate revocation. This may viola te
the desired need-to-know requirement though. ACP nodes MAY support CRLDP operati ons the desired need-to-know requirement, though. ACP nodes <bcp14>MAY</bcp14> suppo rt CRLDP operations
via HTTPS.</t> via HTTPS.</t>
<!--
<t>The CRLDP SHOULD use an ACP certificate for its HTTPs connections.
The connecting ACP node SHOULD verify that the CRLDP certificate used
during the HTTPs connection has the same ACP address as indicated in the
CRLDP URL of the node's ACP certificate if the CRLDP URL uses an IPv6 address.</
t>
</section> </section>
<section anchor="domcert-lifetime" numbered="true" toc="default"> <section anchor="domcert-lifetime" numbered="true" toc="include" remov
<name>Lifetimes</name> eInRFC="false" pn="section-6.2.5.4">
<t>Certificate lifetime may be set to shorter lifetimes than customa <name slugifiedName="name-lifetimes">Lifetimes</name>
ry <t indent="0" pn="section-6.2.5.4-1">The certificate lifetime may be
(1 year) because certificate renewal is fully automated via ACP and EST. set to shorter lifetimes than customary
(one year) because certificate renewal is fully automated via ACP and EST.
The primary limiting factor for shorter certificate lifetimes The primary limiting factor for shorter certificate lifetimes
is load on the EST server(s) and CA. It is therefore recommended that is the load on the EST server(s) and CA. It is therefore recommended that
ACP certificates are managed via a CA chain where the assigning ACP certificates are managed via a CA chain where the assigning
CA has enough performance to manage short lived certificates. See also CA has enough performance to manage short-lived certificates. See also
<xref target="sub-ca" format="default"/> for discussion about an example setup a <xref target="sub-ca" format="default" sectionFormat="of" derivedContent="Sectio
chieving n 9.2.4"/> for a discussion about an example setup achieving
this. See also <xref target="I-D.ietf-acme-star" format="default"/>.</t> this. See also "<xref target="RFC8739" format="title" sectionFormat="of" derived
<t>When certificate lifetimes are sufficiently short, such as few ho Content="Support for Short-Term, Automatically Renewed (STAR) Certificates in th
urs, e Automated Certificate Management Environment (ACME)"/>" <xref target="RFC8739"
certificate revocation may not be necessary, allowing to simplify the overall format="default" sectionFormat="of" derivedContent="RFC8739"/>.</t>
<t indent="0" pn="section-6.2.5.4-2">When certificate lifetimes are
sufficiently short, such as few hours,
certificate revocation may not be necessary, allowing the simplification of the
overall
certificate maintenance infrastructure.</t> certificate maintenance infrastructure.</t>
<t>See <xref target="bootstrap" format="default"/> for further optim <t indent="0" pn="section-6.2.5.4-3">See <xref target="bootstrap" fo
izations of certificate rmat="default" sectionFormat="of" derivedContent="Appendix A.2"/> for further op
maintenance when BRSKI can be used ("Bootstrapping Remote Secure Key timizations of certificate
Infrastructures", see <xref target="I-D.ietf-anima-bootstrapping-keyinfra" forma maintenance when BRSKI can be used <xref target="RFC8995" format="default" secti
t="default"/>).</t> onFormat="of" derivedContent="RFC8995"/>.</t>
</section> </section>
<section anchor="domcert-re-enroll" numbered="true" toc="default"> <section anchor="domcert-re-enroll" numbered="true" toc="include" remo
<name>Re-enrollment</name> veInRFC="false" pn="section-6.2.5.5">
<t>An ACP node may determine that its ACP certificate <name slugifiedName="name-reenrollment">Reenrollment</name>
has expired, for example because the ACP node was powered down or <t indent="0" pn="section-6.2.5.5-1">An ACP node may determine that
its ACP certificate
has expired, for example, because the ACP node was powered down or
disconnected longer than its certificate lifetime. In this case, the ACP disconnected longer than its certificate lifetime. In this case, the ACP
node SHOULD convert to a role of a re-enrolling candidate ACP node.</t> node <bcp14>SHOULD</bcp14> convert to a role of a reenrolling candidate ACP node
<t>In this role, the node does maintain the TA and certificate .</t>
<t indent="0" pn="section-6.2.5.5-2">In this role, the node maintain
s the TA and certificate
chain associated with its ACP certificate exclusively for the purpose chain associated with its ACP certificate exclusively for the purpose
of re-enrollment, and attempts (or waits) to get re-enrolled with a new ACP of reenrollment, and it attempts (or waits) to get reenrolled with a new ACP
certificate. The details depend on the mechanisms/protocols used certificate. The details depend on the mechanisms and protocols used
by the ACP Registrars.</t> by the ACP registrars.</t>
<t>Please refer to <xref target="acp-registrars" format="default"/> <t indent="0" pn="section-6.2.5.5-3">Please refer to <xref target="a
and <xref target="I-D.ietf-anima-bootstrapping-keyinfra" format="default"/> cp-registrars" format="default" sectionFormat="of" derivedContent="Section 6.11.
for explanations about ACP Registrars and vouchers as used in the following text 7"/> and <xref target="RFC8995" format="default" sectionFormat="of" derivedConte
. nt="RFC8995"/>
for explanations about ACP registrars and vouchers as used in the following text
.
When ACP is intended to be used without BRSKI, the details about BRSKI and When ACP is intended to be used without BRSKI, the details about BRSKI and
vouchers in the following text can be skipped.</t> vouchers in the following text can be skipped.</t>
<t>When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the r <t indent="0" pn="section-6.2.5.5-4">When BRSKI is used (i.e., on AC
e-enrolling P nodes that are ANI nodes), the reenrolling
candidate ACP node would attempt to enroll like a candidate ACP node (BRSKI pled candidate ACP node attempts to enroll like a candidate ACP node (BRSKI pledge),
ge), but instead of using the ACP node's IDevID certificate, it <bcp14>SHOULD</bcp14>
but instead of using the ACP nodes IDevID certificate, it SHOULD first attempt t first attempt to use its ACP domain
o use its ACP domain certificate in the BRSKI TLS authentication. The BRSKI registrar <bcp14>MAY</bc
certificate in the BRSKI TLS authentication. The BRSKI registrar MAY honor p14> honor
this certificate beyond its expiration date purely for the purpose of this certificate beyond its expiration date purely for the purpose of
re-enrollment. Using the ACP node's domain certificate allows the BRSKI reenrollment. Using the ACP node's domain certificate allows the BRSKI
registrar to learn that node's acp-node-name, registrar to learn that node's acp-node-name
so that the BRSKI registrar can re-assign the same ACP address information so that the BRSKI registrar can reassign the same ACP address information
to the ACP node in the new ACP certificate.</t> to the ACP node in the new ACP certificate.</t>
<t indent="0" pn="section-6.2.5.5-5">If the BRSKI registrar denies t
<t>If the BRSKI registrar denies the use of the old ACP certificate, he use of the old ACP certificate,
the re-enrolling candidate ACP node MUST re-attempt re-enrollment using the reenrolling candidate ACP node <bcp14>MUST</bcp14> reattempt reenrollment us
ing
its IDevID certificate as defined in BRSKI during the TLS connection setup.</t> its IDevID certificate as defined in BRSKI during the TLS connection setup.</t>
<t indent="0" pn="section-6.2.5.5-6">When the BRSKI connection is at
<t>Both when the BRSKI connection is attempted with the old ACP cert tempted with either with the old ACP certificate
ificate or the IDevID certificate, the reenrolling candidate ACP node <bcp14>SHOULD</bcp
or the IDevID certificate, the re-enrolling candidate ACP node SHOULD authentica 14> authenticate
te
the BRSKI registrar during TLS connection setup based on its existing TA the BRSKI registrar during TLS connection setup based on its existing TA
certificate chain information associated with its old ACP certificate. certificate chain information associated with its old ACP certificate.
The re-enrolling candidate ACP node SHOULD only fall back to requesting a vouche r from the BRSKI registrar The reenrolling candidate ACP node <bcp14>SHOULD</bcp14> only fall back to reque sting a voucher from the BRSKI registrar
when this authentication fails during TLS connection setup. when this authentication fails during TLS connection setup.
As a countermeasure against attacks that attempt to force the ACP node to forget its prior (expired) certificate As a countermeasure against attacks that attempt to force the ACP node to forget its prior (expired) certificate
and TA, the ACP node should alternate between attempting to re-enroll using and TA, the ACP node should alternate between attempting to reenroll using
its old keying material and attempting to re-enroll with its IDevID and requesti its old keying material and attempting to reenroll with its IDevID and requestin
ng g
a voucher.</t> a voucher.</t>
<t indent="0" pn="section-6.2.5.5-7">When mechanisms other than BRSK
<t>When other mechanisms than BRSKI are used for ACP certificate I are used for ACP certificate
enrollment, the principles of the re-enrolling candidate ACP node are the same. enrollment, the principles of the reenrolling candidate ACP node are the same.
The re-enrolling candidate ACP node attempts to authenticate any ACP Registrar p The reenrolling candidate ACP node attempts to authenticate any ACP registrar pe
eers ers
during re-enrollment protocol/mechanisms via its existing certificate chain/TA i using reenrollment protocols and/or mechanisms via its existing certificate chai
nformation n and/or TA information
and provides its existing ACP certificate and other identification and provides its existing ACP certificate and other identification
(such as the IDevID certificate) as necessary to the registrar.</t> (such as the IDevID certificate) as necessary to the registrar.</t>
<t indent="0" pn="section-6.2.5.5-8">Maintaining existing TA informa
<t>Maintaining existing TA information is especially important tion is especially important
when enrollment mechanisms are used that unlike BRSKI do not leverage when using enrollment mechanisms that do not leverage
a mechanism (such as the voucher in BRSKI) to authenticate the ACP registrar a mechanism to authenticate the ACP registrar (such as the voucher in BRSKI),
and where therefore the injection of certificate failures could otherwise make t and when the injection of certificate failures could otherwise make the ACP vuln
he ACP node easily erable to remote
attackable remotely by returning the ACP node to a "duckling" state in which attacks by returning the ACP node to a "duckling" state in which
it accepts to be enrolled by any network it connects to. The (expired) ACP it accepts enrollment by any network it connects to. The (expired) ACP
certificate and ACP TA SHOULD therefore be maintained and attempted to be used a certificate and ACP TA <bcp14>SHOULD</bcp14> therefore be maintained and attempt
s one possible credential for re-enrollment ed to be used as one possible credential for reenrollment
until new keying material is acquired.</t> until new keying material is acquired.</t>
<t indent="0" pn="section-6.2.5.5-9">When using BRSKI or other proto
<t>When using BRSKI or other protocol/mechanisms supporting vouchers cols and/or mechanisms that support vouchers,
, maintaining existing TA information allows for lighter-weight reenrollment
maintaining existing TA information allows for re-enrollment of expired ACP certificates, especially in
of expired ACP certificates to be more lightweight, especially in
environments where repeated acquisition of vouchers during the lifetime environments where repeated acquisition of vouchers during the lifetime
of ACP nodes may be operationally expensive or otherwise undesirable.</t> of ACP nodes may be operationally expensive or otherwise undesirable.</t>
</section> </section>
<section anchor="domcert-failing" numbered="true" toc="default"> <section anchor="domcert-failing" numbered="true" toc="include" remove
<name>Failing Certificates</name> InRFC="false" pn="section-6.2.5.6">
<t>An ACP certificate is called failing in this document, <name slugifiedName="name-failing-certificates">Failing Certificates
if/when the ACP node to which the certificate was issued can determine that it w </name>
as revoked (or explicitly <t indent="0" pn="section-6.2.5.6-1">An ACP certificate is called fa
iling in this document
if or when the ACP node to which the certificate was issued can determine that i
t was revoked (or explicitly
not renewed), or in the absence of such explicit local diagnostics, not renewed), or in the absence of such explicit local diagnostics,
when the ACP node fails to connect to other ACP nodes in the same ACP when the ACP node fails to connect to other ACP nodes in the same ACP
domain using its ACP certificate. For connection failures to domain using its ACP certificate. To
determine the ACP certificate as the culprit, the peer determine that the ACP certificate is the culprit of a connection failure, the p
should pass the domain membership check (<xref target="certcheck" format="defaul eer
t"/>) should pass the domain membership check (<xref target="certcheck" format="defaul
and other reasons for the connection failure can be excluded because of t" sectionFormat="of" derivedContent="Section 6.2.3"/>),
the connection error diagnostics.</t> and connection error diagnostics should exclude other reasons for the connection
<t>This type of failure can happen during setup/refresh of a secure failure.</t>
ACP channel <t indent="0" pn="section-6.2.5.6-2">This type of failure can happen
connections or any other use of the ACP certificate, such as for the during the setup or refreshment of a secure ACP channel
connection or during any other use of the ACP certificate, such as for the
TLS connection to an EST server for the renewal of the ACP domain TLS connection to an EST server for the renewal of the ACP domain
certificate.</t> certificate.</t>
<t>Example reasons for failing certificates that the ACP node can on <t indent="0" pn="section-6.2.5.6-3">The following are examples of f
ly ailing certificates that the ACP node can only
discover through connection failure are that the domain certificate or discover through connection failure: the domain certificate or
any of its signing certificates could have been revoked or may have expired, any of its signing certificates could have been revoked or may have expired,
but the ACP node cannot self-diagnose this condition directly. Revocation but the ACP node cannot diagnose this condition directly by itself. Revocation
information or clock synchronization may only be available across the ACP, information or clock synchronization may only be available across the ACP,
but the ACP node cannot build ACP secure channels because ACP peers reject but the ACP node cannot build ACP secure channels because the ACP peers reject
the ACP node's domain certificate.</t> the ACP node's domain certificate.</t>
<t>ACP nodes SHOULD support the option to determines whether its ACP <t indent="0" pn="section-6.2.5.6-4">An ACP node <bcp14>SHOULD</bcp1 4> support the option to determine whether its ACP
certificate is failing, and when it does, put itself into the role of a certificate is failing, and when it does, put itself into the role of a
re-enrolling candidate ACP node as explained above (<xref target="domcert-re-enr oll" format="default"/>).</t> reenrolling candidate ACP node as explained in <xref target="domcert-re-enroll" format="default" sectionFormat="of" derivedContent="Section 6.2.5.5"/>.</t>
</section> </section>
</section> </section>
<!-- domcert-maint -->
</section> </section>
<!-- domcert --> <section anchor="adj-table" numbered="true" toc="include" removeInRFC="fal
<section anchor="adj-table" numbered="true" toc="default"> se" pn="section-6.3">
<name>ACP Adjacency Table</name> <name slugifiedName="name-acp-adjacency-table">ACP Adjacency Table</name
<t>To know to which nodes to establish an ACP channel, every ACP node ma >
intains an adjacency table. The adjacency table contains information about adja <t indent="0" pn="section-6.3-1">To know to which nodes to establish an
cent ACP nodes, at a minimum: Node-ID (identifier of the node inside the ACP, se ACP channel, every ACP node maintains an adjacency table. The adjacency table c
e <xref target="zone-scheme" format="default"/> and <xref target="Vlong" format= ontains information about adjacent ACP nodes, at a minimum: Node-ID (the identif
"default"/>), interface on which neighbor was discovered (by GRASP as explained ier of the node inside the ACP, see <xref target="zone-scheme" format="default"
below), link-local IPv6 address of neighbor on that interface, certificate (incl sectionFormat="of" derivedContent="Section 6.11.3"/> and <xref target="Vlong" fo
uding acp-node-name). An ACP node MUST maintain this adjacency table. This tab rmat="default" sectionFormat="of" derivedContent="Section 6.11.5"/>), the interf
le is used to determine to which neighbor an ACP connection is established.</t> ace on which neighbor was discovered (by GRASP as explained below), the link-loc
<t>Where the next ACP node is not directly adjacent (i.e., not on a link al IPv6 address of the neighbor on that interface, and the certificate (includin
connected to this node), the information in the adjacency table can be supplemen g acp-node-name). An ACP node <bcp14>MUST</bcp14> maintain this adjacency table
ted by configuration. For example, the Node-ID and IP address could be configur . This table is used to determine to which neighbor an ACP connection is establ
ed. See <xref target="remote-acp-neighbors" format="default"/>.</t> ished.</t>
<t>The adjacency table MAY contain information about the validity and tr <t indent="0" pn="section-6.3-2">When the next ACP node is not directly
ust of the adjacent ACP node's certificate. However, subsequent steps MUST alwa adjacent (i.e., not on a link
ys start with the ACP domain membership check against the peer (see <xref target connected to this node), the information in the adjacency table can be supplemen
="certcheck" format="default"/>).</t> ted by configuration. For example, the Node-ID and IP address could be configur
<t>The adjacency table contains information about adjacent ACP nodes in ed. See <xref target="remote-acp-neighbors" format="default" sectionFormat="of"
general, independently of their domain and trust status. The next step determin derivedContent="Section 8.2"/>.</t>
es to which of those ACP nodes an ACP connection should be established.</t> <t indent="0" pn="section-6.3-3">The adjacency table <bcp14>MAY</bcp14>
contain information about the validity and trust of the adjacent ACP node's cert
ificate. However, subsequent steps <bcp14>MUST</bcp14> always start with the AC
P domain membership check against the peer (see <xref target="certcheck" format=
"default" sectionFormat="of" derivedContent="Section 6.2.3"/>).</t>
<t indent="0" pn="section-6.3-4">The adjacency table contains informatio
n about adjacent ACP nodes in general, independent of their domain and trust sta
tus. The next step determines to which of those ACP nodes an ACP connection sho
uld be established.</t>
</section> </section>
<section anchor="discovery-grasp" numbered="true" toc="default"> <section anchor="discovery-grasp" numbered="true" toc="include" removeInRF
<name>Neighbor Discovery with DULL GRASP</name> C="false" pn="section-6.4">
<t>[RFC-Editor: GRASP draft is in RFC editor queue, waiting for dependen <name slugifiedName="name-neighbor-discovery-with-dul">Neighbor Discover
cies, including ACP. Please ensure that references to I-D.ietf-anima-grasp that y with DULL GRASP</name>
include section number references (throughout this document) will be updated in <t indent="0" pn="section-6.4-1">Discovery Unsolicited Link-Local (DULL)
case any last-minute changes in GRASP would make those section references change GRASP is a limited subset of GRASP intended to operate across an
.</t> insecure link-local scope. See <xref target="RFC8990" sectionFormat="of" sectio
<t>Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of n="2.5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8990#secti
GRASP intended to operate across an on-2.5.2" derivedContent="RFC8990"/> for its
insecure link-local scope. See section 2.5.2 of <xref target="I-D.ietf-anima-gr
asp" format="default"/> for its
formal definition. The ACP uses one instance of DULL GRASP for every L2 interfa ce formal definition. The ACP uses one instance of DULL GRASP for every L2 interfa ce
of the ACP node to discover link level adjacent candidate ACP neighbors. Unless of the ACP node to discover candidate ACP neighbors that are link-level adjacent
modified . Unless modified
by policy as noted earlier (<xref target="overview" format="default"/> bullet po by policy as noted earlier (<xref target="sec5bt2" format="none" sectionFormat="
int 2.), native interfaces of" derivedContent="">Section 5, bullet point 2</xref>), native interfaces
(e.g., physical interfaces on physical nodes) SHOULD be initialized automaticall (e.g., physical interfaces on physical nodes) <bcp14>SHOULD</bcp14> be initializ
y to a state in which ed automatically to a state in which
ACP discovery can be performed and any native interfaces with ACP neighbors can ACP discovery can be performed, and any native interfaces with ACP neighbors can
then be brought into the ACP even if the interface is otherwise not configured. then be brought into the ACP even if the interface is otherwise unconfigured.
Reception of packets on such otherwise not configured interfaces MUST be limited Reception of packets on such otherwise unconfigured interfaces <bcp14>MUST</bcp1
so that 4> be limited so that
at first only IPv6 StateLess Address Auto Configuration (SLAAC - <xref target="R at first only SLAAC ("<xref target="RFC4862" format="title" sectionFormat="of" d
FC4862" format="default"/>) erivedContent="IPv6 Stateless Address Autoconfiguration"/>" <xref target="RFC486
and DULL GRASP work and then only 2" format="default" sectionFormat="of" derivedContent="RFC4862"/>)
the following ACP secure channel setup packets - but not any other unnecessary t and DULL GRASP work, and then only
raffic the following ACP secure channel setup packets work, but not any other unnecessa
(e.g., no other link-local IPv6 transport stack responders for example).</t> ry traffic
<t>Note that the use of the IPv6 link-local multicast address (ALL_GRASP (e.g., no other link-local IPv6 transport stack responders, for example).</t>
_NEIGHBORS) implies <t indent="0" pn="section-6.4-2">Note that the use of the IPv6 link-loca
the need to use Multicast Listener Discovery Version 2 (MLDv2, see <xref target= l multicast address (ALL_GRASP_NEIGHBORS) implies
"RFC3810" format="default"/>) the need to use MLDv2 (see "<xref target="RFC3810" format="title" sectionFormat=
"of" derivedContent="Multicast Listener Discovery Version 2 (MLDv2) for IPv6"/>"
<xref target="RFC3810" format="default" sectionFormat="of" derivedContent="RFC3
810"/>)
to announce the desire to receive packets for to announce the desire to receive packets for
that address. Otherwise DULL GRASP could fail to operate correctly in the prese that address. Otherwise, DULL GRASP could fail to operate correctly in the pres
nce of ence of
MLD snooping (<xref target="RFC4541" format="default"/>) switches that are not A MLD-snooping switches ("<xref target="RFC4541" format="title" sectionFormat="of"
CP supporting/enabled derivedContent="Considerations for Internet Group Management Protocol (IGMP) an
- because those switches would stop forwarding DULL GRASP packets. d Multicast Listener Discovery (MLD) Snooping Switches"/>" <xref target="RFC4541
Switches not supporting MLD snooping simply need to operate as pure L2 bridges f " format="default" sectionFormat="of" derivedContent="RFC4541"/>) that either do
or not support ACP or are not ACP enabled because those switches would stop forwar
ding DULL GRASP packets.
Switches that do not support MLD snooping simply need to operate as pure L2 brid
ges for
IPv6 multicast packets for DULL GRASP to work.</t> IPv6 multicast packets for DULL GRASP to work.</t>
<t>ACP discovery SHOULD NOT be enabled by default on non-native interfac <t indent="0" pn="section-6.4-3">ACP discovery <bcp14>SHOULD NOT</bcp14>
es. In particular, ACP discovery MUST NOT run inside the ACP across ACP virtual be enabled by default on non-native interfaces. In particular, ACP discovery <
interfaces. See <xref target="enabling-acp" format="default"/> for further, no bcp14>MUST NOT</bcp14> run inside the ACP across ACP virtual interfaces. See <x
n-normative suggestions on how to enable/disable ACP at node and interface level ref target="enabling-acp" format="default" sectionFormat="of" derivedContent="Se
. See <xref target="conf-tunnel" format="default"/> for more details about tunn ction 9.3"/> for further non-normative suggestions on how to enable and disable
els (typical non-native interfaces). See <xref target="acp-l2-switches" format= ACP at the node and interface level. See <xref target="conf-tunnel" format="def
"default"/> for how ACP should be extended on devices operating (also) as L2 bri ault" sectionFormat="of" derivedContent="Section 8.2.2"/> for more details about
dges.</t> tunnels (typical non-native interfaces). See <xref target="acp-l2-switches" fo
<t>Note: If an ACP node also implements BRSKI to enroll its ACP certific rmat="default" sectionFormat="of" derivedContent="Section 7"/> for extending ACP
ate on devices operating (also) as L2 bridges.</t>
(see <xref target="bootstrap" format="default"/> for a summary), then the above <t indent="0" pn="section-6.4-4">Note: if an ACP node also implements BR
considerations also apply to SKI to enroll its ACP certificate
(see <xref target="bootstrap" format="default" sectionFormat="of" derivedContent
="Appendix A.2"/> for a summary), then the above considerations also apply to
GRASP discovery for BRSKI. Each DULL instance of GRASP GRASP discovery for BRSKI. Each DULL instance of GRASP
set up for ACP is then also used for the discovery of a bootstrap proxy via BRSK I when the node set up for ACP is then also used for the discovery of a bootstrap proxy via BRSK I when the node
does not have a domain certificate. does not have a domain certificate.
Discovery of ACP neighbors happens only when the node does have the certificate. The node Discovery of ACP neighbors happens only when the node does have the certificate. The node
therefore never needs to discover both a bootstrap proxy and ACP neighbor at the therefore never needs to discover both a bootstrap proxy and an ACP neighbor at
same time.</t> the same time.</t>
<t>An ACP node announces itself to potential ACP peers by use of the "AN <t indent="0" pn="section-6.4-5">An ACP node announces itself to potenti
_ACP" objective. al ACP peers by use of the "AN_ACP" objective.
This is a synchronization objective intended to be flooded on a single link usin g the This is a synchronization objective intended to be flooded on a single link usin g the
GRASP Flood Synchronization (M_FLOOD) message. In accordance with the design of GRASP Flood Synchronization (M_FLOOD) message. In accordance with the design of
the Flood message, the Flood Synchronization message,
a locator consisting of a specific link-local IP address, IP protocol number and a locator consisting of a specific link-local IP address, IP protocol number, an
port number d port number
will be distributed with the flooded objective. An example of the message is in formally:</t> will be distributed with the flooded objective. An example of the message is in formally:</t>
<figure anchor="an-acp-example"> <figure anchor="an-acp-example" align="left" suppress-title="false" pn="
<name>GRASP AN_ACP example</name> figure-6">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-grasp-an_acp-objective-exam">GRASP "AN_ACP"
Objective Example</name>
<sourcecode name="" type="" markers="false" pn="section-6.4-6.1">
[M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000,
[["AN_ACP", 4, 1, "IKEv2" ], [["AN_ACP", 4, 1, "IKEv2" ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]] h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]]
[["AN_ACP", 4, 1, "DTLS" ], [["AN_ACP", 4, 1, "DTLS" ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]] h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]]
] ]
]]></artwork> </sourcecode>
</figure> </figure>
<t> The formal CDDL definition is: </t> <t indent="0" pn="section-6.4-7"> The formal CDDL definition is: </t>
<figure anchor="an-acp-def"> <figure anchor="an-acp-def" align="left" suppress-title="false" pn="figu
<name>GRASP AN_ACP definition</name> re-7">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name slugifiedName="name-grasp-an_acp-definition">GRASP "AN_ACP" Defi
flood-message = [M_FLOOD, session-id, initiator, ttl, nition</name>
+[objective, (locator-option / [])]] <sourcecode name="" type="cddl" markers="false" pn="section-6.4-8.1">
flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]]
objective = ["AN_ACP", objective-flags, loop-count, objective = ["AN_ACP", objective-flags, loop-count,
objective-value] objective-value]
objective-flags = sync-only ; as in the GRASP specification objective-flags = sync-only ; as in [RFC8990]
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; limit to link-local operation loop-count = 1 ; limit to link-local operation
objective-value = method-name / [ method, *extension ] objective-value = method-name / [ method, *extension ]
method = method-name / [ method-name, *method-param ] method = method-name / [ method-name, *method-param ]
method-name = "IKEv2" / "DTLS" / id method-name = "IKEv2" / "DTLS" / id
extension = any extension = any
method-param = any method-param = any
id = text .regexp "[A-Za-z@_$]([-.]*[A-Za-z0-9@_$])*" id = text .regexp "[A-Za-z@_$]([-.]*[A-Za-z0-9@_$])*"
]]></artwork> </sourcecode>
</figure> </figure>
<t>The objective-flags field is set to indicate synchronization.</t> <t indent="0" pn="section-6.4-9">The 'objective-flags' field is set to i
<t>The loop-count is fixed at 1 since this is a link-local operation.</t ndicate synchronization.</t>
> <t indent="0" pn="section-6.4-10">The 'loop-count' is fixed at 1 since t
<t>In the above example the RECOMMENDED period of sending of the his is a link-local operation.</t>
objective is 60 seconds. The indicated ttl of 210000 msec means <t indent="0" pn="section-6.4-11">In the above example, the <bcp14>RECOM
MENDED</bcp14> period of sending of the
objective is 60 seconds. The indicated 'ttl' of 210000 msec means
that the objective would be cached by ACP nodes even when two that the objective would be cached by ACP nodes even when two
out of three messages are dropped in transit.</t> out of three messages are dropped in transit.</t>
<t>The session-id is a random number used for loop prevention (distingui <t indent="0" pn="section-6.4-12">The 'session-id' is a random number us
shing a message from a prior instance of the same message). In DULL this field ed for loop prevention (distinguishing a message from a prior instance of the sa
is irrelevant but has to be set according to the GRASP specification.</t> me message). In DULL this field is irrelevant but has to be set according to th
<t>The originator MUST be the IPv6 link local address of the originating e GRASP specification.</t>
ACP node on the sending interface.</t> <t indent="0" pn="section-6.4-13">The originator <bcp14>MUST</bcp14> be
<t>The method-name in the 'objective-value' parameter is a string indica the IPv6 link-local address of the originating ACP node on the sending interface
ting the protocol available at the specified or implied locator. It is a protoco .</t>
l supported by the node to negotiate a secure channel. IKEv2 as shown above is t <t indent="0" pn="section-6.4-14">The 'method-name' in the 'objective-va
he protocol used to negotiate an IPsec secure channel.</t> lue' parameter is a string indicating the protocol available at the specified or
<t>Method-params allows to carry method specific parameters. This specif implied locator. It is a protocol supported by the node to negotiate a secure c
ication does not define any method-param(s) for "IKEv2" or "DTLS". Method-params hannel. "IKEv2" as shown in <xref target="an-acp-example" format="default" secti
for these two methods that are not understood by an ACP node MUST be ignored by onFormat="of" derivedContent="Figure 6"/> is the protocol used to negotiate an I
it.</t> Psec secure channel.</t>
<t>extension(s) allows to define method independent parameters. This spe <t indent="0" pn="section-6.4-15">The 'method-param' parameter allows me
cification does not define any extensions. Extensions not understood by an ACP n thod-specific parameters to be carried. This specification does not define any '
ode MUST be ignored by it.</t> method-param'(s) for "IKEv2" or "DTLS". Any method-params for these two methods
<t>The locator-option is optional and only required when the secure chan that are not understood by an ACP node <bcp14>MUST</bcp14> be ignored by it.</t>
nel protocol is not offered at a well-defined port number, or if there is no wel <t indent="0" pn="section-6.4-16">The 'extension' parameter allows the d
l-defined port number.</t> efinition of method-independent parameters. This specification does not define a
ny extensions. Extensions not understood by an ACP node <bcp14>MUST</bcp14> be i
<t>IKEv2 is the actual protocol used to negotiate an Internet Protocol s gnored by it.</t>
ecurity architecture (IPsec) connection. GRASP therefore indicates "IKEv2" and <t indent="0" pn="section-6.4-17">The 'locator-option' is optional and i
not "IPsec". If "IPsec" was used, this too could mean use of the obsolete older s only required when the secure channel protocol is not offered at a well-define
version IKE (v1) (<xref target="RFC2409" format="default"/>). IKEv2 has an IANA d port number, or if there is no well-defined port number.</t>
assigned port number 500, but in the above example, the candidate ACP neighbor <t indent="0" pn="section-6.4-18">IKEv2 is the actual protocol used to n
is offering ACP secure channel negotiation via IKEv2 on port 15000 (purely to sh egotiate an IPsec connection. GRASP therefore indicates "IKEv2" and not "IPsec"
ow through the example that GRASP allows to indicate the port number and it does . If "IPsec" was used, this could mean the use of the obsolete, older version IK
not have to be the IANA assigned one).</t> E (v1) ("<xref target="RFC2409" format="title" sectionFormat="of" derivedContent
="The Internet Key Exchange (IKE)"/>" <xref target="RFC2409" format="default" se
<t>There is no default UDP port for DTLS, it is always locally assigned ctionFormat="of" derivedContent="RFC2409"/>). IKEv2 has an IANA-assigned port n
by the node. For further details about the "DTLS" secure channel protocol, see < umber 500, but in <xref target="an-acp-example" format="default" sectionFormat="
xref target="DTLS" format="default"/>.</t> of" derivedContent="Figure 6"/>, the candidate ACP neighbor is offering ACP secu
re channel negotiation via IKEv2 on port 15000 (purely to show through the examp
<t>If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 le that GRASP allows the indication of a port number, and it does not have to be
address MUST be the same as the initiator address (these are DULL requirements t IANA assigned).</t>
o minimize third party DoS attacks).</t> <t indent="0" pn="section-6.4-19">There is no default UDP port for DTLS,
it is always locally assigned by the node. For further details about the "DTLS"
<t>The secure channel methods defined in this document use the objective secure channel protocol, see <xref target="DTLS" format="default" sectionFormat
-values of "IKEv2" and "DTLS". There is no distinction between IKEv2 native and ="of" derivedContent="Section 6.8.4"/>.</t>
GRE-IKEv2 because this is purely negotiated via IKEv2.</t> <t indent="0" pn="section-6.4-20">If a locator is included, it <bcp14>MU
<t>A node that supports more than one secure channel protocol method nee ST</bcp14> be an O_IPv6_LOCATOR, and the IPv6 address <bcp14>MUST</bcp14> be the
ds to flood multiple versions same as the initiator address (these are DULL requirements to minimize third-pa
of the "AN_ACP" objective so that each method can be accompanied by its own rty DoS attacks).</t>
locator-option. This can use a single GRASP M_FLOOD message as shown in <xref t <t indent="0" pn="section-6.4-21">The secure channel methods defined in
arget="an-acp-example" format="default"/>.</t> this document use "IKEv2" and "DTLS" for 'objective-value'. There is no distinc
<t>The use of DULL GRASP primarily serves to discover the link-local IPv tion between IKEv2 native and GRE-IKEv2 because this is purely negotiated via IK
6 address of candidate ACP peers on subnets. The signaling of the supported secu Ev2.</t>
re channel option is primarily for diagnostic purposes, but it is also necessary <t indent="0" pn="section-6.4-22">A node that supports more than one sec
for discovery when the protocol has no well-known transport address, such as in ure channel protocol method needs to flood multiple versions
the case of DTLS. [RFC-Editor: Please remove the following sentence]. See <xref of the "AN_ACP" objective so that each method can be accompanied by its own
target="ACPDRAFT"/>, Appendix B.4.</t> 'locator-option'. This can use a single GRASP M_FLOOD message as shown in <xref
target="an-acp-example" format="default" sectionFormat="of" derivedContent="Fig
<t>Note that a node serving both as an ACP node and BRSKI Join Proxy may ure 6"/>.</t>
choose to distribute the "AN_ACP" objective and the respective BRSKI in the sam <t indent="0" pn="section-6.4-23">The primary use of DULL GRASP is to di
e M_FLOOD message, since GRASP allows multiple objectives in one message. This scover the link-local IPv6 address of candidate ACP peers on subnets. The signal
may be impractical though if ACP and BRSKI operations are implemented via separa ing of the supported secure channel option is primarily for diagnostic purposes,
te software modules / ASAs.</t> but it is also necessary for discovery when the protocol has no well-known tran
<t>The result of the discovery is the IPv6 link-local address of the nei sport address, such as in the case of DTLS. </t>
ghbor as well as its supported secure channel protocols (and non-standard port t <t indent="0" pn="section-6.4-24">Note that a node serving both as an AC
hey are running on). It is stored in the ACP Adjacency Table (see <xref target= P node and BRSKI Join Proxy may choose to distribute the "AN_ACP" objective and
"adj-table" format="default"/>), which then drives the further building of the A the respective BRSKI in the same M_FLOOD message, since GRASP allows multiple ob
CP to that neighbor.</t> jectives in one message. This may be impractical, though, if ACP and BRSKI oper
<t>Note that the DULL GRASP objective described intentionally does not i ations are implemented via separate software modules and/or ASAs.</t>
nclude the ACP node's ACP certificate even though this would be useful for diagn <t indent="0" pn="section-6.4-25">The result of the discovery is the IPv
ostics and to simplify the security exchange in ACP secure channel security asso 6 link-local address of the neighbor as well as its supported secure channel pro
ciation protocols (see <xref target="associations" format="default"/>). The reas tocols (and the non-standard port they are running on). It is stored in the ACP
on is that DULL GRASP messages are periodically multicasted across IPv6 subnets adjacency table (see <xref target="adj-table" format="default" sectionFormat="o
and full certificates could easily lead to fragmented IPv6 DULL GRASP multicast f" derivedContent="Section 6.3"/>), which then drives the further building of th
packets due to the size of a certificate. This would be highly undesirable.</t> e ACP to that neighbor.</t>
<t indent="0" pn="section-6.4-26">Note that the described DULL GRASP obj
ective intentionally does not include the ACP node's ACP certificate, even thoug
h this would be useful for diagnostics and to simplify the security exchange in
ACP secure channel security association protocols (see <xref target="association
s" format="default" sectionFormat="of" derivedContent="Section 6.8"/>). The reas
on is that DULL GRASP messages are periodically multicast across IPv6 subnets, a
nd full certificates could easily lead to fragmented IPv6 DULL GRASP multicast p
ackets due to the size of a certificate. This would be highly undesirable.</t>
</section> </section>
<!-- discovery-grasp --> <section anchor="selection" numbered="true" toc="include" removeInRFC="fal
<section anchor="selection" numbered="true" toc="default"> se" pn="section-6.5">
<name>Candidate ACP Neighbor Selection</name> <name slugifiedName="name-candidate-acp-neighbor-sele">Candidate ACP Nei
<t>An ACP node determines to which other ACP nodes in the adjacency tabl ghbor Selection</name>
e it should attempt to build an ACP connection. This is based on the informatio <t indent="0" pn="section-6.5-1">An ACP node determines to which other A
n in the ACP Adjacency table.</t> CP nodes in the adjacency table it should attempt to build an ACP connection. T
<t>The ACP is established exclusively between nodes in the same domain. his is based on the information in the ACP adjacency table.</t>
This includes all routing subdomains. <xref target="domain-usage" format="defau <t indent="0" pn="section-6.5-2">The ACP is established exclusively betw
lt"/> explains how ACP connections across multiple routing subdomains are specia een nodes in the same domain. This includes all routing subdomains. <xref targe
l.</t> t="domain-usage" format="default" sectionFormat="of" derivedContent="Appendix A.
<t>The result of the candidate ACP neighbor selection process is a list 6"/> explains how ACP connections across multiple routing subdomains are special
of adjacent or configured autonomic neighbors to which an ACP channel should be .</t>
established. The next step begins that channel establishment.</t> <t indent="0" pn="section-6.5-3">The result of the candidate ACP neighbo
r selection process is a list of adjacent or configured autonomic neighbors to w
hich an ACP channel should be established. The next step begins that channel es
tablishment.</t>
</section> </section>
<!-- selection --> <section anchor="channel-selection" numbered="true" toc="include" removeIn
<section anchor="channel-selection" numbered="true" toc="default"> RFC="false" pn="section-6.6">
<name>Channel Selection</name> <name slugifiedName="name-channel-selection">Channel Selection</name>
<t>To avoid attacks, initial discovery of candidate ACP peers cannot inc <t indent="0" pn="section-6.6-1">To avoid attacks, the initial discovery
lude any non-protected negotiation. To avoid re-inventing and validating securi of candidate ACP peers cannot include any unprotected negotiation. To avoid re
ty association mechanisms, the next step after discovering the address of a cand inventing and validating security association mechanisms, the next step after di
idate neighbor can only be to try first to establish a security association with scovering the address of a candidate neighbor is to establish a security associa
that neighbor using a well-known security association method.</t> tion with that neighbor using a well-known security association method.</t>
<t>From the use-cases it seems clear that not all type of ACP nodes can <t indent="0" pn="section-6.6-2">It seems clear from the use cases that
or need to connect directly to each other or are able to support or prefer all p not all types of ACP nodes can or need to connect directly to each other, nor ar
ossible mechanisms. e they able to support or prefer all possible mechanisms.
For example, code space limited IoT devices may only support DTLS because that For example, IoT devices that are codespace limited may only support DTLS beca
code exists already on them for end-to-end security, but low-end in-ceiling L2 use that code exists already on them for end-to-end security, but low-end, in-ce
switches may only want to support Media Access Control Security (MacSec, see 802 iling L2 switches may only want to support Media Access Control Security (MacSec
.1AE (<xref target="MACSEC" format="default"/>) because that is also supported i , see 802.1AE <xref target="MACSEC" format="default" sectionFormat="of" derivedC
n their chips. Only a flexible gateway device may need to support both of these ontent="MACSEC"/>) because that is also supported in their chips. Only a flexib
mechanisms and potentially more. Note that MacSec is not required by any profi le gateway device may need to support both of these mechanisms and potentially m
les of the ACP in this specification. Instead, MacSec is mentioned as a likely n ore. Note that MacSec is not required by any profiles of the ACP in this specif
ext interesting secure channel protocol. Note also that the security model allo ication. Instead, MacSec is mentioned as an interesting potential secure channel
ws and requires for any-to-any authentication and authorization between all ACP protocol. Note also that the security model allows and requires any-to-any aut
nodes because there is also end-to-end and not only hop-by-hop authentication fo hentication and authorization between all ACP nodes because there is not only ho
r secure channels.</t> p-by-hop but also end-to-end authentication for secure channels.</t>
<t>To support extensible secure channel protocol selection without a sin <t indent="0" pn="section-6.6-3">To support extensible selection of the
gle common mandatory to implement (MTI) protocol, ACP nodes MUST try all the ACP secure channel protocol without a single common mandatory-to-implement (MTI) pro
secure channel protocols it supports and that are feasible because the candidat tocol, an ACP node <bcp14>MUST</bcp14> try all the ACP secure channel protocols
e ACP neighbor also announced them via its AN_ACP GRASP parameters (these are ca it supports and that are also announced by the candidate ACP neighbor via its "A
lled the "feasible" ACP secure channel protocols).</t> N_ACP" GRASP parameters (these are called the "feasible" ACP secure channel prot
<t>To ensure that the selection of the secure channel protocols always s ocols).</t>
ucceeds in a predictable fashion without blocking, the following rules apply: <t indent="0" pn="section-6.6-4">To ensure that the selection of the sec
ure channel protocols always succeeds in a predictable fashion without blocking,
the following rules apply:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6
.6-5">
<li>An ACP node may choose to attempt to initiate the different feasib <li pn="section-6.6-5.1">An ACP node may choose to attempt to initiate
le ACP secure channel protocols it supports according to its local policies sequ the different feasible ACP secure channel protocols it supports according to it
entially or in parallel, but it MUST support acting as a responder to all of the s local policies sequentially or in parallel, but it <bcp14>MUST</bcp14> support
m in parallel.</li> acting as a responder to all of them in parallel.</li>
<li pn="section-6.6-5.2">Once the first ACP secure channel protocol co
<li>Once the first ACP secure channel protocol connection to a specifi nnection to a specific peer IPv6 address passes peer authentication, the two pee
c peer IPv6 address passes peer authentication, the two peers know each other's rs know each other's certificate because those ACP certificates are used by all
certificate because those ACP certificates are used by all secure channel protoc secure channel protocols for mutual authentication. The peer with the higher No
ols for mutual authentication. The peer with the higher Node-ID in the AcpNodeN de-ID in the AcpNodeName of its ACP certificate takes on the role of the Decider
ame of its ACP certificate takes on the role of the Decider towards the peer. Th towards the peer. The other peer takes on the role of the Follower. The Decider
e other peer takes on the role of the Follower. The Decider selects which secure selects which secure channel protocol to ultimately use.</li>
channel protocol to ultimately use.</li> <li pn="section-6.6-5.3">The Follower becomes passive: it does not att
empt to further initiate ACP secure channel protocol connections with the Decide
<li>The Follower becomes passive: it does not attempt to further initi r and does not consider it to be an error when the Decider closes secure channel
ate ACP secure channel protocol connections with the Decider and does not consid s. The Decider becomes the active party, continuing to attempt the setup of sec
er it to be an error when the Decider closes secure channels. The Decider becom ure channel protocols with the Follower. This process terminates when the Decide
es the active party, continues to attempt setting up secure channel protocols wi r arrives at the "best"
th the Follower. This process terminates when the Decider arrives at the "best" ACP secure channel connection option that also works with the Follower ("best"
ACP secure channel connection option that also works with the Follower ("best" from the Decider's point of view).</li>
from the Deciders point of view).</li> <li pn="section-6.6-5.4">A peer with a "0" acp-address in its AcpNodeN
ame takes on the role of Follower when peering with a node that has a non-"0" ac
<li>A peer with a "0" acp-address in its AcpNodeName takes on the role of Follow p-address (note that this specification does not fully define the behavior of AC
er when peering with a node that has a non-"0" acp-address (note that this speci P secure channel negotiation for nodes with a "0" ACP address field, it only def
fication does not fully define the behavior of ACP secure channel negotiation fo ines interoperability with such ACP nodes).</li>
r nodes with a "0" ACP address field, it only defines interoperability with such
ACP nodes).</li>
</ul> </ul>
<t indent="0" pn="section-6.6-6">In a simple example, ACP peer Node 1 at
<t>In a simple example, ACP peer Node 1 attempts to initiate an IPsec vi tempts to initiate an IPsec connection via IKEv2 to peer Node 2. The IKEv2 auth
a IKEv2 connection to peer Node 2. The IKEv2 authentication succeeds. Node 1 ha entication succeeds. Node 1 has the lower ACP address and becomes the Follower.
s the lower ACP address and becomes the Follower. Node 2 becomes the Decider. IK Node 2 becomes the Decider. IKEv2 might not be the preferred ACP secure channel
Ev2 might not be the preferred ACP secure channel protocol for the Decider Node protocol for the Decider Node 2. Node 2 would therefore proceed to attempt secur
2. Node 2 would therefore proceed to attempt secure channel setups with (in its e channel setups with more preferred protocol options (in its view, e.g., DTLS/U
view) more preferred protocol options (e.g., DTLS/UDP). If any such preferred AC DP). If any such preferred ACP secure channel connection of the Decider succeeds
P secure channel connection of the Decider succeeds, it would close the IPsec co , it would close the IPsec connection. If Node 2 has no preferred protocol opti
nnection. If Node 2 has no preferred protocol option over IPsec, or no such con on over IPsec, or no such connection attempt from Node 2 to Node 1 succeeds, Nod
nection attempt from Node 2 to Node 1 succeeds, Node 2 would keep the IPsec conn e 2 would keep the IPsec connection and use it.</t>
ection and use it.</t> <t indent="0" pn="section-6.6-7">The Decider <bcp14>SHOULD NOT</bcp14> s
end actual payload packets across a secure channel until it has decided to use i
<t>The Decider SHOULD NOT send actual payload packets across a secure channel un t. The Follower <bcp14>MAY</bcp14> delay linking the ACP secure channel to the A
til it has decided to use it. The Follower MAY delay linking the ACP secure chan CP virtual interface until it sees the first payload packet from the Decider up
nel into the ACP virtual interface until it sees the first payload packet from t to a maximum of 5 seconds to avoid unnecessarily linking a secure channel that w
he Decider up to a maximum of 5 seconds to avoid unnecessarily linking a secure ill be terminated as undesired by the Decider shortly afterward.</t>
channel that will be terminated as undesired by the Decider shortly afterwards.< <t keepWithNext="true" indent="0" pn="section-6.6-8">The following seque
/t> nce of steps show this example in more detail. Each step is tagged with [&lt;ste
p#&gt;{:&lt;connection&gt;}]. The connection is included to more easily distingu
<?rfc needLines="48" ?> ish which of the two competing connections the step belongs to, one initiated by
<t>The following sequence of steps show this example in more detail. Eac Node 1, one initiated by Node 2.
h step is tagged with [&lt;step#&gt;{:&lt;connection&gt;}]. The connection is in </t>
cluded to more easily distinguish which of the two competing connections the ste <dl newline="false" indent="10" spacing="normal" pn="section-6.6-9">
p belongs to, one initiated by Node 1, one initiated by Node 2. <dt pn="section-6.6-9.1">[1]</dt>
</t> <dd pn="section-6.6-9.2">Node 1 sends GRASP "AN_ACP" message to announ
<figure anchor="sequence-of-steps"> ce itself.</dd>
<name>Secure Channel sequence of steps</name> <dt pn="section-6.6-9.3">[2]</dt>
<artwork name="" type="" align="left" alt=""><![CDATA[ <dd pn="section-6.6-9.4">Node 2 sends GRASP "AN_ACP" message to announ
[1] Node 1 sends GRASP AN_ACP message to announce itself ce itself.</dd>
<dt pn="section-6.6-9.5">[3]</dt>
[2] Node 2 sends GRASP AN_ACP message to announce itself <dd pn="section-6.6-9.6">Node 2 receives [1] from Node 1.</dd>
<dt pn="section-6.6-9.7">[4:C1]</dt>
[3] Node 2 receives [1] from Node 1 <dd pn="section-6.6-9.8">Because of [3], Node 2 starts as initiator on
its preferred
[4:C1] Because of [3], Node 2 starts as initiator on its secure channel protocol towards Node 1. Connection C1.</dd>
preferred secure channel protocol towards Node 1. <dt pn="section-6.6-9.9">[5]</dt>
Connection C1. <dd pn="section-6.6-9.10">Node 1 receives [2] from Node 2.</dd>
<dt pn="section-6.6-9.11">[6:C2]</dt>
[5] Node 1 receives [2] from Node 2 <dd pn="section-6.6-9.12">Because of [5], Node 1 starts as initiator o
n its preferred secure channel protocol towards Node 2. Connection C2.</dd>
[6:C2] Because of [5], Node 1 starts as initiator on its <dt pn="section-6.6-9.13">[7:C1]</dt>
preferred secure channel protocol towards Node 2. <dd pn="section-6.6-9.14">Node 1 and Node 2 have authenticated each ot
Connection C2. her's certificate on connection C1 as valid ACP peers.</dd>
<dt pn="section-6.6-9.15">[8:C1]</dt>
[7:C1] Node1 and Node2 have authenticated each others <dd pn="section-6.6-9.16">Node 1's certificate has a lower ACP Node-ID
certificate on connection C1 as valid ACP peers. than Node 2's, therefore Node 1 considers itself the Follower and Node 2 the De
cider on connection C1. Connection setup C1 is completed.</dd>
[8:C1] Node 1 certificate has lower ACP Node-ID than Node2, therefore <dt pn="section-6.6-9.17">[9]</dt>
Node 1 considers itself the Follower and Node 2 the Decider <dd pn="section-6.6-9.18">Node 1 refrains from attempting any further
on connection C1. Connection setup C1 is completed. secure channel connections to Node
2 (the Decider) as learned from [2] because it knows from [8:C1] that it is the
[9] Node 1 refrains from attempting any further secure channel Follower relative to Node 2.
connections to Node 2 (the Decider) as learned from [2] </dd>
because it knows from [8:C1] that it is the Follower <dt pn="section-6.6-9.19">[10:C2]</dt>
relative to Node 1. <dd pn="section-6.6-9.20">Node 1 and Node 2 have authenticated each ot
her's certificate on connection C2 (like [7:C1]).</dd>
[10:C2] Node1 and Node2 have authenticated each others <dt pn="section-6.6-9.21">[11:C2]</dt>
certificate on connection C2 (like [7:C1]). <dd pn="section-6.6-9.22">Node 1's certificate has a lower ACP Node-ID
than Node 2's, therefore Node 1
[11:C2] Node 1 certificate has lower ACP Node-ID than Node2, considers itself the Follower and Node 2 the Decider on connection C2, but
therefore Node 1 considers itself the Follower and Node 2 the they also identify that C2 is to the same mutual peer as their C1, so this has
Decider on connection C2, but they also identify that C2 is no further impact: the roles Decider and Follower where already assigned
to the same mutual peer as their C1, so this has no further between these two peers by [8:C1].</dd>
impact: the roles Decider and Follower where already assigned <dt pn="section-6.6-9.23">[12:C2]</dt>
between these two peers by [8:C1]. <dd pn="section-6.6-9.24">Node 2 (the Decider) closes C1. Node 1 is fi
ne with this, because of its role as the Follower (from [8:C1]).</dd>
[12:C2] Node 2 (the Decider) closes C1. Node 1 is fine with this, <dt pn="section-6.6-9.25">[13]</dt>
because of its role as the Follower (from [8:C1]). <dd pn="section-6.6-9.26">Node 2 (the Decider) and Node 1 (the Followe
r) start data
[13] Node 2 (the Decider) and Node 1 (the Follower) start data transfer across C2, which makes it become a secure channel for the ACP.</dd>
transfer across C2, which makes it become a secure channel </dl>
for the ACP. <t indent="0" pn="section-6.6-10">All this negotiation is in the context
]]></artwork> of an L2 interface. The Decider and Follower will build ACP connections to eac
</figure> h other on every L2 interface that they both connect to. An autonomic node <bcp
14>MUST NOT</bcp14> assume that neighbors with the same L2 or link-local IPv6 ad
<t>All this negotiation is in the context of an "L2 interface". The Dec dresses on different L2 interfaces are the same node. This can only be determin
ider and Follower will build ACP connections to each other on every "L2 interfac ed after examining the certificate after a successful security association attem
e" that they both connect to. An autonomic node MUST NOT assume that neighbors pt.</t>
with the same L2 or link-local IPv6 addresses on different L2 interfaces are the <t indent="0" pn="section-6.6-11">The Decider <bcp14>SHOULD NOT</bcp14>
same node. This can only be determined after examining the certificate after a suppress attempting a particular ACP secure channel protocol connection on one L
successful security association attempt.</t> 2 interface because this type of ACP secure channel connection has failed to the
peer with the same ACP certificate on another L2 interface: not only may the su
<t>The Decider SHOULD NOT suppress attempting a particular ACP secure channel pr pported ACP secure channel protocol options be different on the same ACP peer ac
otocol connection on one L2 interface because this type of ACP secure channel co ross different L2 interfaces, but also error conditions may cause inconsistent f
nnection has failed to the peer with the same ACP certificate on another L2 inte ailures across different L2 interfaces. Avoiding such connection attempt optimiz
rface: Not only the supported ACP secure channel protocol options may be differe ations can therefore help to increase robustness in the case of errors.</t>
nt on the same ACP peer across different L2 interfaces, but also error condition
s may cause inconsistent failures across different L2 interfaces. Avoiding such
connection attempt optimizations can therefore help to increase robustness in th
e case of errors.</t>
</section> </section>
<!-- channel-selection --> <section anchor="neighbor_verification" numbered="true" toc="include" remo
<section anchor="neighbor_verification" numbered="true" toc="default"> veInRFC="false" pn="section-6.7">
<name>Candidate ACP Neighbor verification</name> <name slugifiedName="name-candidate-acp-neighbor-veri">Candidate ACP Nei
<t>Independent of the security association protocol chosen, candidate AC ghbor Verification</name>
P neighbors need to be authenticated based on their domain certificate. This im <t indent="0" pn="section-6.7-1">Independent of the security association
plies that any secure channel protocol MUST support certificate based authentica protocol chosen, candidate ACP neighbors need to be authenticated based on thei
tion that can support the ACP domain membership check as defined in <xref target r domain certificate. This implies that any secure channel protocol <bcp14>MUST
="certcheck" format="default"/>. If it fails, the connection attempt is aborted </bcp14> support certificate-based authentication that can support the ACP domai
and an error logged. Attempts to reconnect MUST be throttled. The RECOMMENDED d n membership check as defined in <xref target="certcheck" format="default" secti
efault is exponential base 2 backoff with an initial retransmission time (IRT) o onFormat="of" derivedContent="Section 6.2.3"/>. If it fails, the connection att
f 10 seconds and a maximum retransmission time (MRT) of 640 seconds.</t> empt is aborted and an error logged. Attempts to reconnect <bcp14>MUST</bcp14> b
<t>Failure to authenticate an ACP neighbor when acting in the role of a e throttled. The <bcp14>RECOMMENDED</bcp14> default is exponential base-two back
responder off with an initial retransmission time (IRT) of 10 seconds and a maximum retran
of the security authentication protocol MUST NOT impact the attempts of the ACP smission time (MRT) of 640 seconds.</t>
node <t indent="0" pn="section-6.7-2">Failure to authenticate an ACP neighbor
when acting in the role of a responder
of the security authentication protocol <bcp14>MUST NOT</bcp14> impact the attem
pts of the ACP node
to attempt establishing a connection as an initiator. Only failed connection att empts as to attempt establishing a connection as an initiator. Only failed connection att empts as
an initiator must cause throttling. This rule is meant to increase resilience an initiator must cause throttling. This rule is meant to increase resilience
of secure channel creation. <xref target="channel-selection" format="default"/> shows how simultaneous mutual of secure channel creation. <xref target="channel-selection" format="default" se ctionFormat="of" derivedContent="Section 6.6"/> shows how simultaneous mutual
secure channel setup collisions are resolved.</t> secure channel setup collisions are resolved.</t>
</section> </section>
<section anchor="associations" numbered="true" toc="default"> <section anchor="associations" numbered="true" toc="include" removeInRFC="
<name>Security Association (Secure Channel) protocols</name> false" pn="section-6.8">
<t>This section describes how ACP nodes establish secured data connectio <name slugifiedName="name-security-association-secure">Security Associat
ns to automatically discovered or configured peers in the ACP. <xref target="dis ion (Secure Channel) Protocols</name>
covery-grasp" format="default"/> above described how IPv6 subnet adjacent peers <t indent="0" pn="section-6.8-1">This section describes how ACP nodes es
are discovered automatically. <xref target="remote-acp-neighbors" format="defaul tablish secured data connections to automatically discovered or configured peers
t"/> describes how non IPv6 subnet adjacent peers can be configured.</t> in the ACP. <xref target="discovery-grasp" format="default" sectionFormat="of"
<t><xref target="ACP-virtual-interfaces" format="default"/> describes ho derivedContent="Section 6.4"/> describes how peers that are adjacent on an IPv6
w secure channels are mapped to virtual IPv6 subnet interfaces in the ACP. The s subnet are discovered automatically. <xref target="remote-acp-neighbors" format=
imple case is to map every ACP secure channel into a separate ACP point-to-point "default" sectionFormat="of" derivedContent="Section 8.2"/> describes how to con
virtual interface <xref target="ACP-p2p-virtual-interfaces" format="default"/>. figure peers that are not adjacent on an IPv6 subnet.</t>
When a single subnet has multiple ACP peers this results in multiple ACP point- <t indent="0" pn="section-6.8-2"><xref target="ACP-virtual-interfaces" f
to-point virtual interfaces across that underlying multi-party IPv6 subnet. This ormat="default" sectionFormat="of" derivedContent="Section 6.13.5.2"/> describes
can be optimized with ACP multi-access virtual interfaces (<xref target="ACP-ma how secure channels are mapped to virtual IPv6 subnet interfaces in the ACP. Th
-virtual-interfaces" format="default"/>) but the benefits of that optimization m e simple case is to map every ACP secure channel to a separate ACP point-to-poin
ay not justify the complexity of that option.</t> t virtual interface (<xref target="ACP-p2p-virtual-interfaces" format="default"
<section anchor="general-considerations" numbered="true" toc="default"> sectionFormat="of" derivedContent="Section 6.13.5.2.1"/>). When a single subnet
<name>General considerations</name> has multiple ACP peers, this results in multiple ACP point-to-point virtual inte
<t>Due to <xref target="channel-selection" format="default">Channel Se rfaces across that underlying multiparty IPv6 subnet. This can be optimized with
lection</xref>, ACP can support an evolving set of security association protocol ACP multi-access virtual interfaces (<xref target="ACP-ma-virtual-interfaces" f
s and does not require support for a single network wide MTI. ACP nodes only ne ormat="default" sectionFormat="of" derivedContent="Section 6.13.5.2.2"/>), but t
ed to implement those protocols required to interoperate with their candidate pe he benefits of that optimization may not justify the complexity of that option.<
ers, not with potentially any node in the ACP domain. See <xref target="Profiles /t>
" format="default"/> for an example of this.</t> <section anchor="general-considerations" numbered="true" toc="include" r
<t>The degree of security required on every hop of an ACP network need emoveInRFC="false" pn="section-6.8.1">
s to be consistent across the network so that there is no designated "weakest li <name slugifiedName="name-general-considerations">General Consideratio
nk" because it is that "weakest link" that would otherwise become the designated ns</name>
point of attack. When the secure channel protection on one link is compromised, <t indent="0" pn="section-6.8.1-1">Due to channel selection (<xref tar
it can be used to send/receive packets across the whole ACP network. Therefore, get="channel-selection" format="default" sectionFormat="of" derivedContent="Sect
even though the security association protocols can be different, their minimum ion 6.6"/>), ACP can support an evolving set of security association protocols a
degree of security should be comparable.</t> nd does not require support for a single network-wide MTI. ACP nodes only need
<t>Secure channel protocols do not need to always support arbitrary L3 to implement those protocols required to interoperate with their candidate peers
connectivity between peers, but can leverage the fact that the standard use cas , not with potentially any node in the ACP domain. See <xref target="Profiles" f
e for ACP secure channels is an L2 adjacency. Hence, L2 dependent mechanisms cou ormat="default" sectionFormat="of" derivedContent="Section 6.8.5"/> for an examp
ld be adopted for use as secure channel association protocols:</t> le of this.</t>
<t>L2 mechanisms such as strong encrypted radio technologies or <xref <t indent="0" pn="section-6.8.1-2">The degree of security required on
target="MACSEC" format="default"/> may offer equivalent encryption and the ACP s every hop of an ACP network needs to be consistent across the network so that th
ecurity association protocol may only be required to authenticate ACP domain mem ere is no designated "weakest link" because it is that "weakest link" that would
bership of a peer and/or derive a key for the L2 mechanism. Mechanisms to auto-d otherwise become the designated point of attack. When the secure channel protec
iscover and associate ACP peers leveraging such underlying L2 security are possi tion on one link is compromised, it can be used to send and/or receive packets a
ble and desirable to avoid duplication of encryption, but none are specified in cross the whole ACP network. Therefore, even though the security association pro
this document.</t> tocols can be different, their minimum degree of security should be comparable.<
<t>Strong physical security of a link may stand in where cryptographic /t>
security is infeasible. As there is no secure mechanism to automatically discov <t indent="0" pn="section-6.8.1-3">Secure channel protocols do not nee
er strong physical security solely between two peers, it can only be used with e d to always support arbitrary Layer 3 (L3) connectivity between peers, but can l
xplicit configuration and that configuration too could become an attack vector. everage the fact that the standard use case for ACP secure channels is an L2 adj
This document therefore only specifies with <xref target="ACPconnect" format="de acency. Hence, L2 dependent mechanisms could be adopted for use as secure channe
fault">ACP connect</xref> one explicitly configured mechanism without any secure l association protocols.</t>
channel association protocol - for the case where both the link and the nodes a <t indent="0" pn="section-6.8.1-4">L2 mechanisms such as strong encryp
ttached to it have strong physical security.</t> ted radio technologies or <xref target="MACSEC" format="default" sectionFormat="
of" derivedContent="MACSEC"/> may offer equivalent encryption, and the ACP secur
ity association protocol may only be required to authenticate ACP domain members
hip of a peer and/or derive a key for the L2 mechanism. Mechanisms that leverage
such underlying L2 security to auto-discover and associate ACP peers are possib
le and desirable to avoid duplication of encryption, but none are specified in t
his document.</t>
<t indent="0" pn="section-6.8.1-5">Strong physical security of a link
may stand in where cryptographic security is infeasible. As there is no secure m
echanism to automatically discover strong physical security solely between two p
eers, it can only be used with explicit configuration, and that configuration to
o could become an attack vector. This document therefore specifies with <xref ta
rget="ACPconnect" format="default" sectionFormat="of" derivedContent="Section 8.
1">ACP connect</xref> only one explicitly configured mechanism without any secur
e channel association protocol for the case where both the link and the nodes at
tached to it have strong physical security.</t>
</section> </section>
<section anchor="common-requirements" numbered="true" toc="default"> <section anchor="common-requirements" numbered="true" toc="include" remo
<name>Common requirements</name> veInRFC="false" pn="section-6.8.2">
<t>The authentication of peers in any security association protocol MU <name slugifiedName="name-common-requirements">Common Requirements</na
ST use the ACP certificate according to <xref target="certcheck" format="default me>
"/>. Because auto-discovery of candidate ACP neighbors via GRASP (see <xref tar <t indent="0" pn="section-6.8.2-1">The authentication of peers in any
get="discovery-grasp" format="default"/>) as specified in this document does not security association protocol <bcp14>MUST</bcp14> use the ACP certificate accord
communicate the neighbors ACP certificate, and ACP nodes may not (yet) have any ing to <xref target="certcheck" format="default" sectionFormat="of" derivedConte
other network connectivity to retrieve certificates, any security association p nt="Section 6.2.3"/>. Because auto-discovery of candidate ACP neighbors via GRA
rotocol MUST use a mechanism to communicate the certificate directly instead of SP (see <xref target="discovery-grasp" format="default" sectionFormat="of" deriv
relying on a referential mechanism such as communicating only a hash and/or URL edContent="Section 6.4"/>) as specified in this document does not communicate th
for the certificate.</t> e neighbor's ACP certificate, and ACP nodes may not (yet) have any other network
<t>A security association protocol MUST use Forward Secrecy (whether i connectivity to retrieve certificates, any security association protocol <bcp14
nherently or as part of a profile of the security association protocol). </t> >MUST</bcp14> use a mechanism to communicate the certificate directly instead of
<t>Because the ACP payload of legacy protocol payloads inside the ACP relying on a referential mechanism such as communicating only a hash and/or URL
and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP secure chan for the certificate.</t>
nel protocol requires confidentiality. Symmetric encryption for the transmission <t indent="0" pn="section-6.8.2-2">A security association protocol <bc
of secure channel data MUST use encryption schemes considered to be security wi p14>MUST</bcp14> use Forward Secrecy (whether inherently or as part of a profile
se equal to or better than 256-bit key strength, such as AES256. There MUST NOT of the security association protocol). </t>
be support for NULL encryption. </t> <t indent="0" pn="section-6.8.2-3">Because the ACP payload of legacy p
<t>Security association protocols typically only signal the End Entity rotocol payloads inside the ACP and hop-by-hop ACP flooded GRASP information is
certificate unencrypted, the ACP secure channel protocol requires confidentiality. Symmetric
(e.g. the ACP certificate) and any possible intermediate CA certificates encryption for the transmission of secure channel data <bcp14>MUST</bcp14> use
encryption schemes considered to be security wise equal to or better than 256-bi
t key strength, such as AES-256. There <bcp14>MUST NOT</bcp14> be support for NU
LL encryption. </t>
<t indent="0" pn="section-6.8.2-4">Security association protocols typi
cally only signal the end entity certificate
(e.g., the ACP certificate) and any possible intermediate CA certificates
for successful mutual authentication. The TA has to be mutually known and for successful mutual authentication. The TA has to be mutually known and
trusted and therefore its certificate does not need to be signaled for successfu l trusted, and therefore its certificate does not need to be signaled for successf ul
mutual authentication. Nevertheless, for use with ACP secure channel setup, mutual authentication. Nevertheless, for use with ACP secure channel setup,
there SHOULD be the option to include the TA certificate in the signaling there <bcp14>SHOULD</bcp14> be the option to include the TA certificate in the s
to aid troubleshooting, see <xref target="ta-troubleshoot" format="default"/>.</ ignaling
t> to aid troubleshooting, see <xref target="ta-troubleshoot" format="default" sect
<t>Signaling of TA certificates may not be appropriate when the deploy ionFormat="of" derivedContent="Section 9.1.1"/>.</t>
ment is relying on <t indent="0" pn="section-6.8.2-5">Signaling of TA certificates may no
a security model where the TA certificate content is considered confidential an t be appropriate when the deployment relies on
d only its hash a security model where the TA certificate content is considered confidential, a
is appropriate for signaling. ACP nodes SHOULD have a mechanism to select whethe nd only its hash
r is appropriate for signaling. ACP nodes <bcp14>SHOULD</bcp14> have a mechanism t
the TA certificate is signaled or not. Assuming that both options are possible w o select whether
ith the TA certificate is signaled or not, assuming that both options are possible w
ith
a specific secure channel protocol.</t> a specific secure channel protocol.</t>
<t>An ACP secure channel MUST immediately be terminated when the lifet <t indent="0" pn="section-6.8.2-6">An ACP secure channel <bcp14>MUST</
ime of any certificate in the chain used to authenticate the neighbor expires or bcp14> immediately be terminated when the lifetime of any certificate in the cha
becomes revoked. This may not be standard behavior in secure channel protocols in used to authenticate the neighbor expires or becomes revoked. This may not b
because the certificate authentication may only influence the setup of the secu e standard behavior in secure channel protocols because the certificate authenti
re channel in these protocols, but may not be re-validated during the lifetime o cation may only influence the setup of the secure channel in these protocols, bu
f the secure connection in the absence of this requirement.</t> t may not be revalidated during the lifetime of the secure connection in the abs
<t>When specifying an additional security association protocol for ACP ence of this requirement.</t>
secure channels beyond those covered in this document, protocol options SHOULD <t indent="0" pn="section-6.8.2-7">When specifying an additional secur
be eliminated that are not necessary to support devices that are expected to be ity association protocol for ACP secure channels beyond those covered in this do
able to support the ACP to minimize implementation complexity. For example, defi cument, any protocol options that are unnecessary for the support of devices tha
nitions for security protocols often include old/inferior security options requi t are expected to be able to support the ACP <bcp14>SHOULD</bcp14> be eliminated
red only to interoperate with existing devices that will not be able to update t in order to minimize implementation complexity. For example, definitions for se
o the currently preferred security options. Such old/inferior security options d curity protocols often include old and/or inferior security options required onl
o not need to be supported when a security association protocol is first specifi y to interoperate with existing devices that cannot update to the currently pref
ed for the ACP, strengthening the "weakest link" and simplifying ACP implementat erred security options. Such old and/or inferior security options do not need to
ion overhead.</t> be supported when a security association protocol is first specified for the AC
P, thus strengthening the "weakest link" and simplifying ACP implementation over
head.</t>
</section> </section>
<section anchor="IPsec-group" numbered="true" toc="default"> <section anchor="IPsec-group" numbered="true" toc="include" removeInRFC=
<name>ACP via IPsec</name> "false" pn="section-6.8.3">
<t>An ACP node announces its ability to support IPsec, negotiated via <name slugifiedName="name-acp-via-ipsec">ACP via IPsec</name>
IKEv2, as the ACP secure channel protocol using the "IKEv2" objective-value in t <t indent="0" pn="section-6.8.3-1">An ACP node announces its ability t
he "AN_ACP" GRASP objective.</t> o support IPsec, negotiated via IKEv2, as the ACP secure channel protocol using
<t>The ACP usage of IPsec and IKEv2 mandates a profile with a narrow s the "IKEv2" 'objective-value' in the "AN_ACP" GRASP objective.</t>
et of options of the current standards-track usage guidance for IPsec <xref targ <t indent="0" pn="section-6.8.3-2">The ACP usage of IPsec and IKEv2 ma
et="RFC8221" format="default"/> and IKEv2 <xref target="RFC8247" format="default ndates a profile with a narrow set of options of the current Standards Track usa
"/>. These option result in stringent security properties and can exclude depre ge guidance for IPsec ("<xref target="RFC8221" format="title" sectionFormat="of"
cated/legacy algorithms because there is no need for interoperability with legac derivedContent="Cryptographic Algorithm Implementation Requirements and Usage G
y equipment for ACP secure channels. Any such backward compatibility would lead uidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)"
only to increased attack surface and implementation complexity, for no benefit. />" <xref target="RFC8221" format="default" sectionFormat="of" derivedContent="R
</t> FC8221"/>) and IKEv2 ("<xref target="RFC8247" format="title" sectionFormat="of"
<section anchor="IPsec" toc="include" numbered="true"> derivedContent="Algorithm Implementation Requirements and Usage Guidance for the
<name>Native IPsec</name> Internet Key Exchange Protocol Version 2 (IKEv2)"/>" <xref target="RFC8247" for
<t> An ACP node that is supporting native IPsec MUST use IPsec in tu mat="default" sectionFormat="of" derivedContent="RFC8247"/>). These options res
nnel mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next Header of ult in stringent security properties and can exclude deprecated and legacy algor
41). It MUST use local and peer link-local IPv6 addresses for encapsulation. M ithms because there is no need for interoperability with legacy equipment for AC
anual keying MUST NOT be used, see <xref target="domcert" format="default"/>. Tr P secure channels. Any such backward compatibility would lead only to an increa
affic Selectors are:</t> sed attack surface and implementation complexity, for no benefit.</t>
<t>TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)< <section anchor="IPsec" toc="include" numbered="true" removeInRFC="fal
/t> se" pn="section-6.8.3.1">
<t>TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)< <name slugifiedName="name-native-ipsec">Native IPsec</name>
/t> <t indent="0" pn="section-6.8.3.1-1"> An ACP node that is supporting
<t>IPsec tunnel mode is required because the ACP will route/forward native IPsec
packets received from any other ACP node across the ACP secure channels, and not <bcp14>MUST</bcp14> use IPsec in tunnel mode, negotiated via
only its own generated ACP packets. With IPsec transport mode (and no addition IKEv2, and with IPv6 payload (e.g., ESP Next Header of 41). It
al encapsulation header in the ESP payload), it would only be possible to send p <bcp14>MUST</bcp14> use local and peer link-local IPv6 addresses
ackets originated by the ACP node itself because the IPv6 addresses of the ESP m for encapsulation. Manual keying <bcp14>MUST NOT</bcp14> be used,
ust be the same as that of the outer IPv6 header.</t> see <xref target="domcert" format="default" sectionFormat="of" derive
<section anchor="rfc8221req" toc="include" numbered="true"> dContent="Section 6.2"/>. Traffic Selectors
<name>RFC8221 (IPsec/ESP)</name> are:</t>
<t>ACP IPsec implementations MUST comply with <xref target="RFC822 <artwork name="" type="" align="left" alt="" pn="section-6.8.3.1-2">
1" format="default"/> (and its updates). The requirements from above and this se TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
ction amend and superseded its requirements.</t> TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
<t>The IP Authentication Header (AH) MUST NOT be used (because it </artwork>
does not provide confidentiality).</t> <t indent="0" pn="section-6.8.3.1-3">IPsec tunnel mode is required b
<t>For the required ESP encryption algorithms in section 5 of <xre ecause the ACP will route and/or forward packets received from any other ACP nod
f target="RFC8221" format="default"/> the following guidance applies: e across the ACP secure channels, and not only its own generated ACP packets. W
ith IPsec transport mode (and no additional encapsulation header in the ESP payl
oad), it would only be possible to send packets originated by the ACP node itsel
f because the IPv6 addresses of the ESP must be the same as that of the outer IP
v6 header.</t>
<section anchor="rfc8221req" toc="include" numbered="true" removeInR
FC="false" pn="section-6.8.3.1.1">
<name slugifiedName="name-rfc-8221-ipsec-esp">RFC 8221 (IPsec/ESP)
</name>
<t indent="0" pn="section-6.8.3.1.1-1">ACP IPsec implementations <
bcp14>MUST</bcp14> comply with <xref target="RFC8221" format="default" sectionFo
rmat="of" derivedContent="RFC8221"/> and any specifications that update it. The
requirements from above and this section amend and supersede its requirements.</
t>
<t indent="0" pn="section-6.8.3.1.1-2">The IP Authentication Heade
r (AH) <bcp14>MUST NOT</bcp14> be used (because it does not provide confidential
ity).</t>
<t indent="0" pn="section-6.8.3.1.1-3">For the required ESP encryp
tion algorithms in <xref target="RFC8221" sectionFormat="of" section="5" format=
"default" derivedLink="https://rfc-editor.org/rfc/rfc8221#section-5" derivedCont
ent="RFC8221"/>, the following guidance applies:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
<li>ENCR_NULL AH MUST NOT be used (because it does not provide c tion-6.8.3.1.1-4">
onfidentiality).</li> <li pn="section-6.8.3.1.1-4.1">ENCR_NULL AH <bcp14>MUST NOT</bcp
<li>ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for 14> be used (because it does not provide confidentiality).</li>
ACP via IPsec/ESP (it is already listed as MUST in <xref target="RFC8221" forma <li pn="section-6.8.3.1.1-4.2">ENCR_AES_GCM_16 is the only MTI E
t="default"/>).</li> SP encryption algorithm for ACP via IPsec/ESP (it is already listed as <bcp14>MU
<li>ENCR_AES_CBC with AUTH_HMAC_SHA2_256_128 (as the ESP authent ST</bcp14> in <xref target="RFC8221" format="default" sectionFormat="of" derived
ication algorithm) and ENCR_AES_CCM_8 MAY be supported. If either provides highe Content="RFC8221"/>).</li>
r performance than ENCR_AES_GCM_16 it SHOULD be supported.</li> <li pn="section-6.8.3.1.1-4.3">ENCR_AES_CBC with AUTH_HMAC_SHA2_
<li>ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or highe 256_128 (as the ESP authentication algorithm) and ENCR_AES_CCM_8 <bcp14>MAY</bcp
r performance than ENCR_AES_GCM_16. If that performance is not feasible, it MAY 14> be supported. If either provides higher performance than ENCR_AES_GCM_16, it
be supported.</li> <bcp14>SHOULD</bcp14> be supported.</li>
<li pn="section-6.8.3.1.1-4.4">ENCR_CHACHA20_POLY1305 <bcp14>SHO
ULD</bcp14> be supported at equal or higher performance than ENCR_AES_GCM_16. If
that performance is not feasible, it <bcp14>MAY</bcp14> be supported.</li>
</ul> </ul>
<t>IKEv2 indicates an order for the offered algorithms. The algor <t indent="0" pn="section-6.8.3.1.1-5">IKEv2 indicates an order fo
ithms SHOULD be ordered by performance. The first algorithm supported by both s r the offered algorithms. The algorithms <bcp14>SHOULD</bcp14> be ordered by pe
ides is generally chosen.</t> rformance. The first algorithm supported by both sides is generally chosen.</t>
<t> Explanations: <t indent="0" pn="section-6.8.3.1.1-6"> Explanations:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="sec
<li> tion-6.8.3.1.1-7">
<li pn="section-6.8.3.1.1-7.1">
There is no requirement to interoperate with legacy equipment in ACP There is no requirement to interoperate with legacy equipment in ACP
secure channels, so a single MTI encryption algorithm for IPsec in ACP secure channels, so a single MTI encryption algorithm for IPsec in ACP
secure channels is sufficient for interoperability and allows for secure channels is sufficient for interoperability and allows for
the most lightweight implementations. the most lightweight implementations.
</li> </li>
<li> <li pn="section-6.8.3.1.1-7.2">
ENCR_AES_GCM_16 is an authenticated encryption with associated data (AEAD) ENCR_AES_GCM_16 is an Authenticated Encryption with Associated Data (AEAD)
cipher cipher
mode, so no additional ESP authentication algorithm is needed, simplifying mode, so no additional ESP authentication algorithm is needed, simplifying
the MTI requirements of IPsec for the ACP. the MTI requirements of IPsec for the ACP.
</li> </li>
<li>There is no MTI requirement for the support of ENCR_AES_CBC <li pn="section-6.8.3.1.1-7.3">There is no MTI requirement for t
because he support of ENCR_AES_CBC because
ENCR_AES_GCM_16 is assumed to be feasible with less cost/higher ENCR_AES_GCM_16 is assumed to be feasible with less cost and/or higher
performance in modern devices hardware accelerated implementations performance in modern devices' hardware-accelerated implementations
compared to ENCR-AES_CBC. compared to ENCR-AES_CBC.
</li> </li>
<li> <li pn="section-6.8.3.1.1-7.4">
ENCR_CHACHA20_POLY1305 is mandatory in <xref target="RFC8221" format="defa ENCR_CHACHA20_POLY1305 is mandatory in <xref target="RFC8221" format="defa
ult"/> because ult" sectionFormat="of" derivedContent="RFC8221"/> because
of its target use as a fallback algorithm in case weaknesses in AES are of its target use as a fallback algorithm in case weaknesses in AES are
uncovered. Unfortunately, there is currently no way to automatically uncovered. Unfortunately, there is currently no way to automatically
propagate across an ACP a policy to disallow use of AES based algorithms, propagate across an ACP a policy to disallow use of AES-based algorithms,
so this target benefit of ENCR_CHACHA20_POLY1305 cannot fully be adopted so this target benefit of ENCR_CHACHA20_POLY1305 cannot fully be adopted
yet for the ACP. Therefore, this algorithm is only recommended. Changing yet for the ACP. Therefore, this algorithm is only recommended. Changing
from AES to this algorithm at potentially big drop in performance could from AES to this algorithm with a potentially big drop in performance coul
also render the ACP inoperable. Therefore, the performance requirement aga d
inst also render the ACP inoperable. Therefore, there is a performance requirem
ent against
this algorithm so that it could become an effective security backup to AES this algorithm so that it could become an effective security backup to AES
for the ACP once a policy to switch over to it or prefer it is available i n an ACP framework. for the ACP once a policy to switch over to it or prefer it is available i n an ACP framework.
</li> </li>
</ul> </ul>
<t> <t indent="0" pn="section-6.8.3.1.1-8">
<xref target="RFC8221" format="default"/> allows for 128-bit or 256-bit AES ke <xref target="RFC8221" format="default" sectionFormat="of" derivedContent="RFC
ys. 8221"/> allows for 128-bit or 256-bit AES keys.
This document mandates that only 256-bit AES keys MUST be supported. This document mandates that only 256-bit AES keys <bcp14>MUST</bcp14> be suppo
rted.
</t> </t>
<t> <t indent="0" pn="section-6.8.3.1.1-9">
When <xref target="RFC8221" format="default"/> is updated, ACP implementations w When <xref target="RFC8221" format="default" sectionFormat="of" derivedContent="
ill need to RFC8221"/> is updated, ACP implementations will need to
consider legacy interoperability, and the IPsec WG has generally done a very consider legacy interoperability.
good job of taking that into account in its recommendations.
</t> </t>
</section> </section>
<section anchor="rfc4247req" toc="include" numbered="true"> <section anchor="rfc4247req" toc="include" numbered="true" removeInR
<name>RFC8247 (IKEv2)</name> FC="false" pn="section-6.8.3.1.2">
<!-- tte PRF_HMAC_SHA2_512 requirement superseded by requirement f <name slugifiedName="name-rfc-8247-ikev2">RFC 8247 (IKEv2)</name>
or RFC8247, which includes this PRF requirement: <t indent="0" pn="section-6.8.3.1.2-1">
<xref target="RFC8247" format="default" sectionFormat="of" derivedContent="RFC82
<t>The IKEv2 PRF_HMAC_SHA2_512 pseudorandom function MUST be supported (<xref ta 47"/> provides a baseline recommendation for mandatory-to-implement ciphers, int
rget="rfc4868"/>).</t> egrity checks, pseudorandom functions, and Diffie-Hellman mechanisms.
Those recommendations, and the recommendations of subsequent documents, apply as
--> well to the ACP.
<t> Because IKEv2 for ACP secure channels is sufficient to be implemented in control
<xref target="RFC8247" format="default"/> provides a baseline recommendation for plane software rather than in Application-Specific Integrated Circuit (ASIC) ha
mandatory to implement ciphers, integrity checks, pseudo-random-functions and D rdware, and ACP nodes supporting IKEv2 are not assumed to be code space constrai
iffie-Hellman mechanisms. ned, and because existing IKEv2 implementations are expected to support <xref ta
Those recommendations, and the recommendations of subsequent documents apply wel rget="RFC8247" format="default" sectionFormat="of" derivedContent="RFC8247"/> re
l to the ACP. commendations, this document makes no attempt to simplify its recommendations fo
Because IKEv2 for ACP secure channels is sufficient to be implemented in control r use with the ACP.
plane software, rather than in ASIC hardware, and ACP nodes supporting IKEv2 ar
e not assumed to be code-space constrained, and because existing IKEv2 implement
ations are expected to support <xref target="RFC8247" format="default"/> recomme
ndations, this documents makes no attempt to simplify its recommendations for us
e with the ACP.
</t> </t>
<t>See <xref target="IKEV2IANA" format="default"/> for IANA IKEv2 <t indent="0" pn="section-6.8.3.1.2-2">See <xref target="IKEV2IANA
parameter names used in this text.</t> " format="default" sectionFormat="of" derivedContent="IKEV2IANA"/> for IANA IKEv
<t> 2 parameter names used in this text.</t>
ACP Nodes supporting IKEv2 MUST comply with <xref target="RFC8247" format="defau <t indent="0" pn="section-6.8.3.1.2-3">
lt"/> amended by the following requirements which constitute a policy statement ACP nodes supporting IKEv2 <bcp14>MUST</bcp14> comply with <xref target="RFC8247
as permitted by <xref target="RFC8247" format="default"/>. " format="default" sectionFormat="of" derivedContent="RFC8247"/> amended by the
following requirements, which constitute a policy statement as permitted by <xre
f target="RFC8247" format="default" sectionFormat="of" derivedContent="RFC8247"/
>.
</t> </t>
<t>To signal the ACP certificate chain (including TA) as required <t indent="0" pn="section-6.8.3.1.2-4">To signal the ACP certifica
by <xref target="common-requirements" format="default"/>, "X.509 Certificate - S te chain (including TA) as required by <xref target="common-requirements" format
ignature" payload in IKEv2 can be used. It is mandatory according to <xref targe ="default" sectionFormat="of" derivedContent="Section 6.8.2"/>, the "X.509 Certi
t="RFC7296" format="default"/> section 3.6.</t> ficate - Signature" payload in IKEv2 can be used. It is mandatory according to <
<t>ACP nodes SHOULD set up IKEv2 to only use the ACP certificate a xref target="RFC7296" sectionFormat="comma" section="3.6" format="default" deriv
nd TA when acting as an IKEv2 responder on the IPv6 link local address and port edLink="https://rfc-editor.org/rfc/rfc7296#section-3.6" derivedContent="RFC7296"
number indicated in the AN_ACP DULL GRASP announcements (see <xref target="disco />.</t>
very-grasp" format="default"/>).</t> <t indent="0" pn="section-6.8.3.1.2-5">ACP nodes <bcp14>SHOULD</bc
<t>When CERTREQ is received from a peer, and does not indicate any p14> set up IKEv2 to only use the ACP certificate and TA when acting as an IKEv2
of this responder on the IPv6 link-local address and port number indicated in the "AN_A
ACP nodes TA certificates, the ACP node SHOULD ignore the CERTREQ and CP" DULL GRASP announcements (see <xref target="discovery-grasp" format="default
" sectionFormat="of" derivedContent="Section 6.4"/>).</t>
<t indent="0" pn="section-6.8.3.1.2-6">When CERTREQ is received fr
om a peer, and it does not indicate any of this
ACP node's TA certificates, the ACP node <bcp14>SHOULD</bcp14> ignore the CERTRE
Q and
continue sending its certificate chain including its TA as subject to continue sending its certificate chain including its TA as subject to
the requirements and explanations in <xref target="common-requirements" format=" the requirements and explanations in <xref target="common-requirements" format="
default"/>. This will not result in successful mutual authentication but assists default" sectionFormat="of" derivedContent="Section 6.8.2"/>. This will not resu
diagnostics.</t> lt in successful mutual authentication but assists diagnostics.</t>
<t>Note that with IKEv2, failing authentication will only result i <t indent="0" pn="section-6.8.3.1.2-7">Note that with IKEv2, faili
n the responder ng authentication will only result in the responder
receiving the certificate chain from the initiator, but not vice versa. Because receiving the certificate chain from the initiator, but not vice versa. Because
ACP secure channel setup is symmetric (see <xref target="neighbor_verification" ACP secure channel setup is symmetric (see <xref target="neighbor_verification"
format="default"/>), format="default" sectionFormat="of" derivedContent="Section 6.7"/>),
every non-malicious ACP neighbor will attempt to connect as an initiator though, every non-malicious ACP neighbor will attempt to connect as an initiator, though
allowing to obtain the diagnostic information about the neighbors certificate.</ ,
t> allowing it to obtain the diagnostic information about the neighbor's certificat
e.</t>
<t>In IKEv2, ACP nodes are identified by their ACP address. <t indent="0" pn="section-6.8.3.1.2-8">In IKEv2, ACP nodes are ide
The ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST convey the A ntified by their ACP addresses.
CP address. The ID_IPv6_ADDR IKEv2 identification payload <bcp14>MUST</bcp14> be used and <b
If the peer's ACP certificate includes a 32HEXDIG ACP address in the acp-node-na cp14>MUST</bcp14> convey the ACP address.
me (not "0" or omitted), the address in the IKEv2 identification payload MUST ma If the peer's ACP certificate includes a 32HEXDIG ACP address in the acp-node-na
tch it. me (not "0" or omitted), the address in the IKEv2 identification payload <bcp14>
See <xref target="certcheck" format="default"/> for more information about "0" o MUST</bcp14> match it.
r omitted ACP address fields in the acp-node-name. See <xref target="certcheck" format="default" sectionFormat="of" derivedContent=
"Section 6.2.3"/> for more information about "0" or omitted ACP address fields i
n the acp-node-name.
</t> </t>
<t> <t indent="0" pn="section-6.8.3.1.2-9">
IKEv2 authentication MUST use authentication method 14 ("Digital Signature") for IKEv2 authentication <bcp14>MUST</bcp14> use authentication method 14 ("Digital
ACP certificates; this authentication method can be used with both RSA and ECDS Signature") for ACP certificates; this authentication method can be used with bo
A certificates, indicated by an ASN.1 object AlgorithmIdentifier. th RSA and ECDSA certificates, indicated by an ASN.1 object AlgorithmIdentifier.
</t> </t>
<t>The Digital Signature hash SHA2-512 MUST be supported (in addit <t indent="0" pn="section-6.8.3.1.2-10">The Digital Signature hash
ion to SHA2-256).</t> SHA2-512 <bcp14>MUST</bcp14> be supported (in addition to SHA2-256).</t>
<t> <t indent="0" pn="section-6.8.3.1.2-11">
The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), MUST be sup The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), <bcp14>MUST
ported. Reason: ECC provides a similar security level to finite-field (MODP) ke </bcp14> be supported. Reason: ECC provides a similar security level to finite-
y exchange with a shorter key length, so is generally preferred absent other con field (modular exponentiation (MODP)) key exchange with a shorter key length, so
siderations. is generally preferred absent other considerations.
</t> </t>
</section> </section>
</section> </section>
<section anchor="IPsec-GRE" toc="include" numbered="true"> <section anchor="IPsec-GRE" toc="include" numbered="true" removeInRFC=
<name>IPsec with GRE encapsulation</name> "false" pn="section-6.8.3.2">
<t>In network devices it is often more common to implement high perf <name slugifiedName="name-ipsec-with-gre-encapsulatio">IPsec with GR
ormance virtual interfaces on top of GRE encapsulation than on top of a "native" E Encapsulation</name>
IPsec association (without any other encapsulation than those defined by IPsec) <t indent="0" pn="section-6.8.3.2-1">In network devices, it is often
. On those devices it may be beneficial to run the ACP secure channel on top of more common to implement high-performance virtual interfaces on top of GRE enca
GRE protected by the IPsec association.</t> psulation than on top of a "native" IPsec association (without any other encapsu
<t>The requirements for ESP/IPsec/IKEv2 with GRE are the same as for lation than those defined by IPsec). On those devices, it may be beneficial to
native IPsec (see <xref target="IPsec" format="default"/>) except that IPsec tr run the ACP secure channel on top of GRE protected by the IPsec association.</t>
ansport mode and next protocol GRE (47) are to be negotiated. Tunnel mode is not <t indent="0" pn="section-6.8.3.2-2">The requirements for ESP/IPsec/
required because of GRE. Traffic Selectors are:</t> IKEv2 with GRE are the same as
<t>TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-IPv6-LL- for native IPsec (see <xref target="IPsec" format="default" sectionFo
addr)</t> rmat="of" derivedContent="Section 6.8.3.1"/>)
<t>TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL- except that IPsec transport mode and next protocol GRE (47) are to
addr)</t> be negotiated. Tunnel mode is not required because of GRE. Traffic
<t>If IKEv2 initiator and responder support IPsec over GRE, it will Selectors are:</t>
be preferred over native IPsec because of the way how IKEv2 negotiates transport <artwork name="" type="" align="left" alt="" pn="section-6.8.3.2-3">
mode (as used by this IPsec over GRE profile) versus tunnel mode as used by nat TSi = (47, 0-65535, Initiator-IPv6-LL-addr ... Initiator-IPv6-LL-addr)
ive IPsec (see <xref target="RFC7296" format="default"/>, section 1.3.1). The A TSr = (47, 0-65535, Responder-IPv6-LL-addr ... Responder-IPv6-LL-addr)
CP IPv6 traffic has to be carried across GRE according to <xref target="RFC7676" </artwork>
format="default"/>.</t> <t indent="0" pn="section-6.8.3.2-4">If the IKEv2 initiator and resp
onder support IPsec over GRE, it will be preferred over native IPsec because of
how IKEv2 negotiates transport mode (as used by this IPsec over GRE profile) ver
sus tunnel mode as used by native IPsec (see <xref target="RFC7296" sectionForma
t="of" section="1.3.1" format="default" derivedLink="https://rfc-editor.org/rfc/
rfc7296#section-1.3.1" derivedContent="RFC7296"/>). The ACP IPv6 traffic has to
be carried across GRE according to "<xref target="RFC7676" format="title" secti
onFormat="of" derivedContent="IPv6 Support for Generic Routing Encapsulation (GR
E)"/>" <xref target="RFC7676" format="default" sectionFormat="of" derivedContent
="RFC7676"/>.</t>
</section> </section>
</section> </section>
<!-- IPsec --> <section anchor="DTLS" numbered="true" toc="include" removeInRFC="false"
<section anchor="DTLS" numbered="true" toc="default"> pn="section-6.8.4">
<name>ACP via DTLS</name> <name slugifiedName="name-acp-via-dtls">ACP via DTLS</name>
<t indent="0" pn="section-6.8.4-1">This document defines the use of AC
<t>This document defines the use of ACP via DTLS, on the assumption th P via DTLS on the assumption that it is likely the first transport encryption su
at it is likely the first transport encryption supported in some classes of cons pported in some classes of constrained devices: DTLS is commonly used in constra
trained devices: DTLS is commonly used in constrained devices when IPsec is not. ined devices when IPsec is not. Code space on those devices may be also be too l
Code-space on those devices may be also be too limited to support more than the imited to support more than the minimum number of required protocols.</t>
minimum number of required protocols.</t> <t indent="0" pn="section-6.8.4-2">An ACP node announces its ability t
o support DTLS version 1.2 ("<xref target="RFC6347" format="title" sectionFormat
<t>An ACP node announces its ability to support DTLS version 1.2 (<xre ="of" derivedContent="Datagram Transport Layer Security Version 1.2"/>" <xref ta
f target="RFC6347" format="default"/>) compliant with the requirements defined i rget="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>) c
n this document as an ACP secure channel protocol in GRASP through the "DTLS" ob ompliant with the requirements defined in this document as an ACP secure channel
jective-value in the "AN_ACP" objective (see <xref target="discovery-grasp" form protocol in GRASP through the "DTLS" 'objective-value' in the "AN_ACP" objectiv
at="default"/>).</t> e (see <xref target="discovery-grasp" format="default" sectionFormat="of" derive
dContent="Section 6.4"/>).</t>
<t>To run ACP via UDP and DTLS, a locally assigned UDP port is used th <t indent="0" pn="section-6.8.4-3">To run ACP via UDP and DTLS, a loca
at is announced as a parameter in the GRASP AN_ACP objective to candidate neighb lly assigned UDP port is used that is announced as a parameter in the GRASP "AN_
ors. This port can also be any newer version of DTLS as long as that version ca ACP" objective to candidate neighbors. This port can also be any newer version
n negotiate a DTLS v1.2 connection in the presence of an DTLS v1.2 only peer.</t of DTLS as long as that version can negotiate a DTLS 1.2 connection in the prese
> nce of a peer that only supports DTLS 1.2.</t>
<t indent="0" pn="section-6.8.4-4">All ACP nodes supporting DTLS as a
<t>All ACP nodes supporting DTLS as a secure channel protocol MUST adh secure channel protocol <bcp14>MUST</bcp14> adhere to the DTLS implementation re
ere to the DTLS implementation recommendations and security considerations of BC commendations and security considerations of <xref target="RFC7525" format="defa
P 195, <xref target="RFC7525" format="default">BCP 195</xref> except with respec ult" sectionFormat="of" derivedContent="RFC7525">BCP 195</xref> except with resp
t to the DTLS version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUS ect to the DTLS version. ACP nodes supporting DTLS <bcp14>MUST</bcp14> support D
T NOT support older versions of DTLS.</t> TLS 1.2. They <bcp14>MUST NOT</bcp14> support older versions of DTLS.</t>
<t indent="0" pn="section-6.8.4-5">Unlike for IPsec, no attempts are m
<t>Unlike for IPsec, no attempts are made to simplify the requirements ade to simplify the requirements of the recommendations in <xref target="RFC7525
of the BCP 195 recommendations because the expectation is that DTLS would be us " format="default" sectionFormat="of" derivedContent="RFC7525">BCP 195</xref> be
ing software-only implementations where the ability to reuse of widely adopted i cause the expectation is that DTLS would use software-only implementations where
mplementations is more important than minimizing the complexity of a hardware ac the ability to reuse widely adopted implementations is more important than the
celerated implementation which is known to be important for IPsec.</t> ability to minimize the complexity of a hardware-accelerated implementation, whi
ch is known to be important for IPsec.</t>
<t>DTLS v1.3 (<xref target="I-D.ietf-tls-dtls13" format="default"/>) i <t indent="0" pn="section-6.8.4-6">DTLS 1.3 <xref target="I-D.ietf-tls
s "backward compatible" with -dtls13" format="default" sectionFormat="of" derivedContent="TLS-DTLS13"/> is "b
DTLS v1.2 (see section 1. of DTLS v1.3). A DTLS implementation supporting both ackward compatible" with
DTLS v1.2 and DTLS v1.3 does comply with the above requirements of negotiating t DTLS 1.2 (see <xref target="I-D.ietf-tls-dtls13" sectionFormat="of" section="1"
o format="default" derivedLink="https://tools.ietf.org/html/draft-ietf-tls-dtls13-
DTLS v1.2 in the presence of a DTLS v1.2 only peer, but using DTLS v1.3 when 43#section-1" derivedContent="TLS-DTLS13"/>). A DTLS implementation supporting
both
DTLS 1.2 and DTLS 1.3 does comply with the above requirements of negotiating to
DTLS 1.2 in the presence of a DTLS 1.2 only peer, but using DTLS 1.3 when
booth peers support it.</t> booth peers support it.</t>
<t indent="0" pn="section-6.8.4-7">Version 1.2 is the MTI version of D
<t>Version v1.2 is the MTI version of DTLS in this specification becau TLS in this specification because of the following:
se
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>There is more experience with DTLS v1.2 across the spectrum of t -6.8.4-8">
arget ACP nodes.</li> <li pn="section-6.8.4-8.1">There is more experience with DTLS 1.2 ac
<li>Firmware of lower end, embedded ACP nodes may not support a newe ross the spectrum of target ACP nodes.</li>
r version for a long time.</li> <li pn="section-6.8.4-8.2">Firmware of lower-end, embedded ACP nodes
<li>There are significant changes of DTLS v1.3, such as a different may not support a newer version for a long time.</li>
record layer requiring time to gain implementation and deployment experience es <li pn="section-6.8.4-8.3">There are significant changes with DTLS 1
pecially on lower end, code space limited devices.</li> .3, such as a different record layer requiring time to gain implementation and d
<li>The existing BCP <xref target="RFC7525" format="default"/> for D eployment experience especially on lower-end devices with limited code space.</l
TLS v1.2 may equally take longer time to be updated with experience from a newer i>
DTLS version.</li> <li pn="section-6.8.4-8.4">The existing BCP <xref target="RFC7525" f
<li> There are no significant use-case relevant benefits of DTLS v1. ormat="default" sectionFormat="of" derivedContent="RFC7525"/> for DTLS 1.2 may t
3 over DTLS v1.2 in the ake an equally longer time to be updated with experience from a newer DTLS versi
on.</li>
<li pn="section-6.8.4-8.5"> There are no significant benefits of DTL
S 1.3 over DTLS 1.2 that are use-case relevant in the
context of the ACP options for DTLS. For example, signaling performance im provements for session setup in context of the ACP options for DTLS. For example, signaling performance im provements for session setup in
DTLS v1.3 is not important for the ACP given the long-lived nature of ACP DTLS 1.3 is not important for the ACP given the long-lived nature of ACP s
secure channel connections and ecure channel connections and
the fact that DTLS connections are mostly link-local (short RTT).</li> the fact that DTLS connections are mostly link local (short RTT).</li>
</ul> </ul>
<t>Nevertheless, newer versions of DTLS, such as DTLS v1.3 have strict <t indent="0" pn="section-6.8.4-9">Nevertheless, newer versions of DTL
er security requirements and use of the latest standard protocol version is for S, such as DTLS 1.3, have stricter security requirements, and the use of the lat
IETF security standards in general recommended. Therefore, ACP implementations a est standard protocol version is in general recommended for IETF security standa
re advised to support all the newer versions of DTLS that can still negotiate do rds. Therefore, ACP implementations are advised to support all the newer version
wn to DTLS v1.2.</t> s of DTLS that can still negotiate down to DTLS 1.2.</t>
<t indent="0" pn="section-6.8.4-10">There is no additional session set
<t>[RFC-editor: if by the time of AUTH48, DTLS 1.3 would have evolved up or other security association besides this simple DTLS setup. As soon as the
to be an RFC, then not only would the references to the DTLS v1.3 draft be chang DTLS session is functional, the ACP peers will exchange ACP IPv6 packets as the
ed to the RFC number, but that RFC is then going to be put into the normative li payload of the DTLS transport connection. Any DTLS-defined security associatio
st of references and the above paragraph is going to be amended to say: Implemen n mechanisms such as rekeying are used as they would be for any transport applic
tations SHOULD support [DTLSv1.3-RFC]. This is not done right now, because there ation relying solely on DTLS.</t>
is no benefit in potentially waiting in RFC-editor queue for that RFC given how
the text already lays out a non-normative desire to support DTLSv1.3.]</t>
<t>There is no additional session setup or other security association
besides this simple DTLS setup. As soon as the DTLS session is functional, the
ACP peers will exchange ACP IPv6 packets as the payload of the DTLS transport co
nnection. oAny DTLS defined security association mechanisms such as re-keying a
re used as they would be for any transport application relying solely on DTLS.</
t>
<!-- RFC 6125 is a common reference for TLS server-identification/veri
fication procedures, but it covers only names, and only server identities; as su
ch, it's not really a good fit here. In fact, we can't really do much name vali
dation since the connection is over link-local IPv6 addresses anyway. -->
</section> </section>
<!-- DTLS --> <section anchor="Profiles" numbered="true" toc="include" removeInRFC="fa
<section anchor="Profiles" numbered="true" toc="default"> lse" pn="section-6.8.5">
<name>ACP Secure Channel Profiles</name> <name slugifiedName="name-acp-secure-channel-profiles">ACP Secure Chan
<t>As explained in the beginning of <xref target="channel-selection" f nel Profiles</name>
ormat="default"/>, there is no single secure channel mechanism mandated for all <t indent="0" pn="section-6.8.5-1">As explained in the beginning of <x
ACP nodes. Instead, this section defines two ACP profiles (baseline and constrai ref target="channel-selection" format="default" sectionFormat="of" derivedConten
ned) for ACP nodes that do introduce such requirements.</t> t="Section 6.6"/>, there is no single secure channel mechanism mandated for all
<t>An ACP node supporting the "baseline" profile MUST support IPsec na ACP nodes. Instead, this section defines two ACP profiles, "baseline" and "const
tively and MAY support IPsec via GRE. An ACP node supporting the "constrained" p rained", for ACP nodes that do introduce such requirements.</t>
rofile node that cannot support IPsec MUST support DTLS. An ACP node connecting <t indent="0" pn="section-6.8.5-2">An ACP node supporting the baseline
an area of constrained ACP nodes with an area of baseline ACP nodes needs to su profile <bcp14>MUST</bcp14> support IPsec natively and <bcp14>MAY</bcp14> suppo
pport IPsec and DTLS and supports therefore the baseline and constrained profile rt IPsec via GRE. An ACP node supporting the constrained profile that cannot sup
.</t> port IPsec <bcp14>MUST</bcp14> support DTLS. An ACP node connecting an area of
<t>Explanation: Not all type of ACP nodes can or need to connect direc constrained ACP nodes with an area of baseline ACP nodes needs to support both I
tly to each other or are able to support or prefer all possible secure channel m Psec and DTLS and therefore supports both the baseline and constrained profiles.
echanisms. For example, code space limited IoT devices may only support DTLS be </t>
cause that code exists already on them for end-to-end security, but high-end cor <t indent="0" pn="section-6.8.5-3">Explanation: not all types of ACP n
e routers may not want to support DTLS because they can perform IPsec in acceler odes are able to or need to connect directly to each other, nor are they able to
ated hardware but would need to support DTLS in an underpowered CPU forwarding p support or prefer all possible secure channel mechanisms. For example, IoT dev
ath shared with critical control plane operations. This is not a deployment issu ices with limited code space may only support DTLS because that code already exi
e for a single ACP across these type of nodes as long as there are also appropri sts on them for end-to-end security, but high-end core routers may not want to s
ate gateway ACP nodes that support sufficiently many secure channel mechanisms t upport DTLS because they can perform IPsec in accelerated hardware, but they wou
o allow interconnecting areas of ACP nodes with a more constrained set of secure ld need to support DTLS in an underpowered CPU forwarding path shared with criti
channel protocols. On the edge between IoT areas and high-end core networks, ge cal control plane operations. This is not a deployment issue for a single ACP ac
neral-purpose routers that act as those gateways and that can support a variety ross these types of nodes as long as there are also appropriate gateway ACP node
of secure channel protocols is the norm already.</t> s that sufficiently support many secure channel mechanisms to allow interconnect
<t>IPsec natively with tunnel mode provides the shortest encapsulation ing areas of ACP nodes with a more constrained set of secure channel protocols.
overhead. GRE may be preferred by legacy implementations because the virtual in On the edge between IoT areas and high-end core networks, general-purpose router
terfaces required by ACP design in conjunction with secure channels have in the s that act as those gateways and that can support a variety of secure channel pr
past more often been implemented for GRE than purely for native IPsec.</t> otocols are the norm already.</t>
<t>ACP nodes need to specify in documentation the set of secure ACP me <t indent="0" pn="section-6.8.5-4">Native IPsec with tunnel mode provi
chanisms they support and should declare which profile they support according to des the shortest encapsulation overhead. GRE may be preferred by legacy implemen
above requirements.</t> tations because, in the past, the virtual interfaces required by ACP design in c
onjunction with secure channels have been implemented more often for GRE than pu
rely for native IPsec.</t>
<t indent="0" pn="section-6.8.5-5">ACP nodes need to specify the set o
f secure ACP mechanisms they support in documentation and should declare which p
rofile they support according to the above requirements.</t>
</section> </section>
<!-- Profiles -->
</section> </section>
<!-- associations --> <section anchor="GRASP" numbered="true" toc="include" removeInRFC="false"
<section anchor="GRASP" numbered="true" toc="default"> pn="section-6.9">
<name>GRASP in the ACP</name> <name slugifiedName="name-grasp-in-the-acp">GRASP in the ACP</name>
<section anchor="GRASP-core" numbered="true" toc="default"> <section anchor="GRASP-core" numbered="true" toc="include" removeInRFC="
<name>GRASP as a core service of the ACP</name> false" pn="section-6.9.1">
<t>The ACP MUST run an instance of GRASP inside of it. It is a key pa <name slugifiedName="name-grasp-as-a-core-service-of-">GRASP as a Core
rt of the Service of the ACP</name>
<t indent="0" pn="section-6.9.1-1">The ACP <bcp14>MUST</bcp14> run an
instance of GRASP inside of it. It is a key part of the
ACP services. The function in GRASP that makes it fundamental as a serv ice of the ACP ACP services. The function in GRASP that makes it fundamental as a serv ice of the ACP
is the ability to provide ACP wide service discovery (using objectives is the ability to provide ACP-wide service discovery (using objectives i
in GRASP).</t> n GRASP).</t>
<t>ACP provides IP unicast routing via the RPL routing protocol (see < <t indent="0" pn="section-6.9.1-2">ACP provides IP unicast routing via
xref target="routing" format="default"/>).</t> RPL (see <xref target="routing" format="default" sectionFormat="of" derivedCont
<t>The ACP does not use IP multicast routing nor does it provide gener ent="Section 6.12"/>).</t>
ic IP multicast services <t indent="0" pn="section-6.9.1-3">The ACP does not use IP multicast r
(the handling of GRASP link-local multicast messages is explained in <xr outing nor does it provide generic IP multicast services
ef target="GRASP-substrate" format="default"/>). (the handling of GRASP link-local multicast messages is explained in <xr
ef target="GRASP-substrate" format="default" sectionFormat="of" derivedContent="
Section 6.9.2"/>).
Instead, the ACP provides service discovery via the objective discovery/ announcement and Instead, the ACP provides service discovery via the objective discovery/ announcement and
negotiation mechanisms of the ACP GRASP instance (services are a form of objectives). negotiation mechanisms of the ACP GRASP instance (services are a form of objectives).
These mechanisms use hop-by-hop reliable flooding of GRASP messages for both service discovery These mechanisms use hop-by-hop reliable flooding of GRASP messages for both service discovery
(GRASP M_DISCOVERY messages) and service announcement (GRASP M_FLOOD mes sages).</t> (GRASP M_DISCOVERY messages) and service announcement (GRASP M_FLOOD mes sages).</t>
<t>See <xref target="acp-grasp" format="default"/> for discussion abou t this design choice <t indent="0" pn="section-6.9.1-4">See <xref target="acp-grasp" format ="default" sectionFormat="of" derivedContent="Appendix A.5"/> for discussion abo ut this design choice
of the ACP.</t> of the ACP.</t>
</section> </section>
<section anchor="GRASP-substrate" numbered="true" toc="default"> <section anchor="GRASP-substrate" numbered="true" toc="include" removeIn
<name>ACP as the Security and Transport substrate for GRASP</name> RFC="false" pn="section-6.9.2">
<t>In the terminology of GRASP (<xref target="I-D.ietf-anima-grasp" fo <name slugifiedName="name-acp-as-the-security-and-tra">ACP as the Secu
rmat="default"/>), the ACP is the rity and Transport Substrate for GRASP</name>
<t indent="0" pn="section-6.9.2-1">In the terminology of GRASP <xref t
arget="RFC8990" format="default" sectionFormat="of" derivedContent="RFC8990"/>,
the ACP is the
security and transport substrate for the GRASP instance run inside the A CP ("ACP GRASP").</t> security and transport substrate for the GRASP instance run inside the A CP ("ACP GRASP").</t>
<t>This means that the ACP is responsible for ensuring that this insta nce of GRASP is <t indent="0" pn="section-6.9.2-2">This means that the ACP is responsi ble for ensuring that this instance of GRASP is
only sending messages across the ACP GRASP virtual interfaces. only sending messages across the ACP GRASP virtual interfaces.
Whenever the ACP adds or deletes such an interface because of new ACP se cure channels or Whenever the ACP adds or deletes such an interface because of new ACP se cure channels or
loss thereof, the ACP needs to indicate this to the ACP instance of GRAS P. The ACP exists loss thereof, the ACP needs to indicate this to the ACP instance of GRAS P. The ACP exists
also in the absence of any active ACP neighbors. It is created when the node has a domain also in the absence of any active ACP neighbors. It is created when the node has a domain
certificate, and continues to exist even if all of its neighbors cease o certificate, and it continues to exist even if all of its neighbors ceas
peration.</t> e operation.</t>
<t>In this case ASAs using GRASP running on the same node would still <t indent="0" pn="section-6.9.2-3">In this case, ASAs using GRASP runn
need ing on the same node still need
to be able to discover each other's objectives. When the ACP does not e xist, ASAs leveraging to be able to discover each other's objectives. When the ACP does not e xist, ASAs leveraging
the ACP instance of GRASP via APIs MUST still be able to operate, and MU ST be able to the ACP instance of GRASP via APIs <bcp14>MUST</bcp14> still be able to operate, and they <bcp14>MUST</bcp14> be able to
understand that there is no ACP and that therefore the ACP instance of G RASP cannot understand that there is no ACP and that therefore the ACP instance of G RASP cannot
operate.</t> operate.</t>
<t>The following explanation how ACP acts as the security and transpor <t indent="0" pn="section-6.9.2-4">How the ACP acts as the security an
t substrate for GRASP is visualized d transport substrate for GRASP is shown
in <xref target="acp-grasp-picture" format="default"/> below.</t> in <xref target="acp-grasp-picture" format="default" sectionFormat="of"
<t>GRASP unicast messages inside the ACP always use the ACP address. derivedContent="Figure 8"/>.</t>
Link-local <t indent="0" pn="section-6.9.2-5">GRASP unicast messages inside the A
addresses from the ACP VRF MUST NOT be used inside objectives. GRASP un CP always use the ACP address. Link-local
icast messages inside the ACP addresses from the ACP VRF <bcp14>MUST NOT</bcp14> be used inside object
are transported via TLS. See <xref target="tls" format="default"/> for T ives. GRASP unicast messages inside the ACP
LS requirements. are transported via TLS. See <xref target="tls" format="default" section
TLS mutual authentication MUST use the ACP domain membership check Format="of" derivedContent="Section 6.1"/> for TLS requirements.
defined in (<xref target="certcheck" format="default"/>).</t> TLS mutual authentication <bcp14>MUST</bcp14> use the ACP domain members
hip check
<t>GRASP link-local multicast messages are targeted for a specific ACP defined in <xref target="certcheck" format="default" sectionFormat="of"
virtual interface derivedContent="Section 6.2.3"/>.</t>
(as defined <xref target="ACP_interfaces" format="default"/>) but are se <t indent="0" pn="section-6.9.2-6">GRASP link-local multicast messages
nt by the ACP into are targeted for a specific ACP virtual interface
(as defined <xref target="ACP_interfaces" format="default" sectionFormat
="of" derivedContent="Section 6.13.5"/>), but they are sent by the ACP to
an ACP GRASP virtual interface that is constructed from the TCP an ACP GRASP virtual interface that is constructed from the TCP
connection(s) to the IPv6 link-local neighbor address(es) on the underly ing connection(s) to the IPv6 link-local neighbor address(es) on the underly ing
ACP virtual interface. If the ACP GRASP virtual interface has two or mo re neighbors, ACP virtual interface. If the ACP GRASP virtual interface has two or mo re neighbors,
the GRASP link-local multicast messages are replicated to all neighbor T CP connections.</t> the GRASP link-local multicast messages are replicated to all neighbor T CP connections.</t>
<t indent="0" pn="section-6.9.2-7">TCP and TLS connections for GRASP i
<t>TCP and TLS connections for GRASP in the ACP use the IANA assigned n the ACP use the IANA-assigned TCP port for GRASP (7017).
TCP port for GRASP (7107). Effectively, the transport stack is expected to be TLS for connections t
Effectively the transport stack is expected to be TLS for connections fr o and from the ACP
om/to the ACP address (e.g., global-scope address(es)) and TCP for connections to and
address (e.g., global scope address(es)) and TCP for connections from/to from the link-local addresses
link-local addresses on the ACP virtual interfaces. The latter ones are only used for the fl
on the ACP virtual interfaces. The latter ones are only used for floodi ooding of GRASP
ng of GRASP
messages.</t> messages.</t>
<!-- https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/344 --> <figure anchor="acp-grasp-picture" align="left" suppress-title="false"
<?rfc needLines="48" ?> pn="figure-8">
<figure anchor="acp-grasp-picture"> <name slugifiedName="name-acp-as-security-and-transpo">ACP as Securi
<name>ACP as security and transport substrate for GRASP</name> ty and Transport Substrate for GRASP</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-6.9.2-8.1">
..............................ACP.............................. ..............................ACP..............................
. . . .
. /-GRASP-flooding-\ ACP GRASP instance . . /-GRASP-flooding-\ ACP GRASP instance .
. / \ A . / \ A
. GRASP GRASP GRASP C . GRASP GRASP GRASP C
. link-local unicast link-local P . link-local unicast link-local P
. multicast messages multicast . . multicast messages multicast .
. messages | messages . . messages | messages .
. | | | . . | | | .
............................................................... ...............................................................
. v v v ACP security and transport . . v v v ACP security and transport .
. | | | substrate for GRASP . . | | | substrate for GRASP .
. | | | . . | | | .
. | ACP GRASP | - ACP GRASP A . | ACP GRASP | - ACP GRASP A
. | Loopback | Loopback interface C . | loopback | loopback interface C
. | interface | - ACP-cert auth P . | interface | - ACP-cert auth P
. | TLS | . . | TLS | .
. ACP GRASP | ACP GRASP - ACP GRASP virtual . . ACP GRASP | ACP GRASP - ACP GRASP virtual .
. subnet1 | subnet2 virtual interfaces . . subnet1 | subnet2 interfaces .
. TCP | TCP . . TCP | TCP .
. | | | . . | | | .
............................................................... ...............................................................
. | | | ^^^ Users of ACP (GRASP/ASA) . . | | | ^^^ Users of ACP (GRASP/ASA) .
. | | | ACP interfaces/addressing . . | | | ACP interfaces/addressing .
. | | | . . | | | .
. | | | A . | | | A
. | ACP-Loopback Interf.| <- ACP Loopback interface C . | ACP loopback interf.| &lt;- ACP loopback interface C
. | ACP-address | - address (global ULA) P . | ACP-address | - address (global ULA) P
. subnet1 | subnet2 <- ACP virtual interfaces . . subnet1 | subnet2 &lt;- ACP virtual interfaces .
. link-local | link-local - link-local addresses . . link-local | link-local - link-local addresses .
............................................................... ...............................................................
. | | | ACP VRF . . | | | ACP VRF .
. | RPL-routing | virtual routing and forwarding . . | RPL-routing | virtual routing and forwarding .
. | /IP-Forwarding\ | A . | /IP-Forwarding\ | A
. | / \ | C . | / \ | C
. ACP IPv6 packets ACP IPv6 packets P . ACP IPv6 packets ACP IPv6 packets P
. |/ \| . . |/ \| .
. IPsec/DTLS IPsec/DTLS - ACP-cert auth . . IPsec/DTLS IPsec/DTLS - ACP-cert auth .
............................................................... ...............................................................
| | Data-Plane | | Data Plane
| | | |
| | - ACP secure channel | | - ACP secure channel
link-local link-local - encapsulation addresses link-local link-local - encapsulation addresses
subnet1 subnet2 - Data-Plane interfaces subnet1 subnet2 - data plane interfaces
| | | |
ACP-Nbr1 ACP-Nbr2 ACP-Nbr1 ACP-Nbr2
]]></artwork> </artwork>
</figure> </figure>
<section anchor="GRASP-discussion" numbered="true" toc="default"> <section anchor="GRASP-discussion" numbered="true" toc="include" remov
<name>Discussion</name> eInRFC="false" pn="section-6.9.2.1">
<t>TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local me <name slugifiedName="name-discussion">Discussion</name>
ssages is used because <t indent="0" pn="section-6.9.2.1-1">TCP encapsulation for GRASP M_D
these messages are flooded across potentially many hops to all ACP n ISCOVERY and M_FLOOD link-local messages is used because
odes and a single these messages are flooded across potentially many hops to all ACP n
link with even temporary packet loss issues (e.g., WiFi/Powerline li odes, and a single
nk) can reduce the link with even temporary packet-loss issues (e.g., a Wi-Fi or Powerl
probability for loss free transmission so much that applications wou ine link) can reduce the
ld want to increase probability for loss-free transmission so much that applications wou
ld want to increase
the frequency with which they send these messages. Such shorter per iodic retransmission the frequency with which they send these messages. Such shorter per iodic retransmission
of datagrams would result in more traffic and processing overhead in the ACP of datagrams would result in more traffic and processing overhead in the ACP
than the hop-by-hop reliable retransmission mechanism by TCP and dup licate elimination than the hop-by-hop, reliable retransmission mechanism offered by TC P and duplicate elimination
by GRASP.</t> by GRASP.</t>
<t>TLS is mandated for GRASP non-link-local unicast because the ACP secure channel <t indent="0" pn="section-6.9.2.1-2">TLS is mandated for GRASP non-l ink-local unicast because the ACP secure channel
mandatory authentication and encryption protects only against attack s from the outside mandatory authentication and encryption protects only against attack s from the outside
but not against attacks from the inside: Compromised ACP members tha but not against attacks from the inside: compromised ACP members tha
t have (not yet) been t have (not yet) been
detected and removed (e.g., via domain certificate revocation / expi detected and removed (e.g., via domain certificate revocation and/or
ry).</t> expiry).</t>
<t>If GRASP peer connections were to use just TCP, compromised ACP m <t indent="0" pn="section-6.9.2.1-3">If GRASP peer connections were
embers could to use just TCP, compromised ACP members could
simply eavesdrop passively on GRASP peer connections for whom they a simply eavesdrop passively on GRASP peer connections for which they
re on-path ("man in the are on-path ("man in the
middle" - MITM) or intercept and modify them. With TLS, it is not p middle" or MITM) or intercept and modify messages. With TLS, it is
ossible to completely not possible to completely
eliminate problems with compromised ACP members, but attacks are a l eliminate problems with compromised ACP members, but attacks are a l
ot more complex:</t> ot more complex.</t>
<t>Eavesdropping/spoofing by a compromised ACP node is still possibl <t indent="0" pn="section-6.9.2.1-4">Eavesdropping and/or spoofing b
e because y a compromised ACP node is still possible because
in the model of the ACP and GRASP, the provider and consumer of an o bjective have in the model of the ACP and GRASP, the provider and consumer of an o bjective have
initially no unique information (such as an identity) about the othe r side which initially no unique information (such as an identity) about the othe r side that
would allow them to distinguish a benevolent from a compromised peer . The compromised would allow them to distinguish a benevolent from a compromised peer . The compromised
ACP node would simply announce the objective as well, potentially fi lter the original ACP node would simply announce the objective as well, potentially fi lter the original
objective in GRASP when it is a MITM and act as an application level proxy. This of course objective in GRASP when it is a MITM and act as an application-level proxy. This of course
requires that the compromised ACP node understand the semantics of t he GRASP negotiation requires that the compromised ACP node understand the semantics of t he GRASP negotiation
to an extent that allows it to proxy it without being detected, but in an ACP environment to an extent that allows the compromised node to proxy the messages without being detected, but in an ACP environment,
this is quite likely public knowledge or even standardized.</t> this is quite likely public knowledge or even standardized.</t>
<t>The GRASP TLS connections are run the same as any other ACP traff <t indent="0" pn="section-6.9.2.1-5">The GRASP TLS connections are r
ic through the ACP un the same as any other ACP traffic through the ACP
secure channels. This leads to double authentication/encryption, wh secure channels. This leads to double authentication and encryption
ich has the following , which has the following
benefits:</t> benefits:</t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>Secure channel methods such as IPsec may provide protection ag on-6.9.2.1-6">
ainst additional <li pn="section-6.9.2.1-6.1">Secure channel methods such as IPsec
attacks, for example reset-attacks.</li> may provide protection against additional
<li>The secure channel method may leverage hardware acceleration a attacks, for example, reset attacks.</li>
nd there may be little <li pn="section-6.9.2.1-6.2">The secure channel method may leverag
e hardware acceleration, and there may be little
or no gain in eliminating it.</li> or no gain in eliminating it.</li>
<li>There is no different security model for ACP GRASP from other <li pn="section-6.9.2.1-6.3">The security model for ACP GRASP is n
ACP traffic. Instead, o different than other ACP traffic. Instead,
there is just another layer of protection against certain attack there is just another layer of protection against certain attack
s from the inside s from the inside,
which is important due to the role of GRASP in the ACP.</li> which is important due to the role of GRASP in the ACP.</li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
<!-- GRASPinstances --> <section anchor="separation" numbered="true" toc="include" removeInRFC="fa
<section anchor="separation" numbered="true" toc="default"> lse" pn="section-6.10">
<name>Context Separation</name> <name slugifiedName="name-context-separation">Context Separation</name>
<t>The ACP is in a separate context from the normal Data-Plane of the no <t indent="0" pn="section-6.10-1">The ACP is in a separate context from
de. This context includes the ACP channels' IPv6 forwarding and routing as well the normal data plane of the node. This context includes the ACP channels' IPv6
as any required higher layer ACP functions.</t> forwarding and routing as well as any required higher-layer ACP functions.</t>
<t>In classical network system, a dedicated VRF is one logical implement <t indent="0" pn="section-6.10-2">In a classical network system, a dedic
ation option for the ACP. If possible by the systems software architecture, sep ated VRF is one logical implementation option for the ACP. If allowed by the sy
aration options that minimize shared components are preferred, such as a logical stem's software architecture, separation options that minimize shared components
container or virtual machine instance. The context for the ACP needs to be est , such as a logical container or virtual machine instance, are preferred. The c
ablished automatically during bootstrap of a node. As much as possible it shoul ontext for the ACP needs to be established automatically during the bootstrap of
d be protected from being modified unintentionally by ("Data-Plane") configurati a node. As much as possible, it should be protected from being modified uninte
on.</t> ntionally by (data plane) configuration.</t>
<t>Context separation improves security, because the ACP is not reachabl <t indent="0" pn="section-6.10-3">Context separation improves security b
e from the Data-Plane routing or forwarding table(s). Also, configuration error ecause the ACP is not reachable from the data plane routing or forwarding table(
s from the Data-Plane setup do not affect the ACP.</t> s). Also, configuration errors from the data plane setup do not affect the ACP.
</t>
</section> </section>
<!-- separation --> <section anchor="addressing" numbered="true" toc="include" removeInRFC="fa
<section anchor="addressing" numbered="true" toc="default"> lse" pn="section-6.11">
<name>Addressing inside the ACP</name> <name slugifiedName="name-addressing-inside-the-acp">Addressing inside t
<t>The channels explained above typically only establish communication b he ACP</name>
etween two adjacent nodes. In order for communication to happen across multiple <t indent="0" pn="section-6.11-1">The channels explained above typically
hops, the autonomic control plane requires ACP network wide valid addresses and only establish communication between two adjacent nodes. In order for communic
routing. Each ACP node creates a Loopback interface with an ACP network wide u ation to happen across multiple hops, the Autonomic Control Plane requires ACP n
nique address (prefix) inside the ACP context (as explained in in <xref target=" etwork-wide valid addresses and routing. Each ACP node creates a loopback inter
separation" format="default"/>). This address may be used also in other virtual face with an ACP network-wide unique address (prefix) inside the ACP context (as
contexts.</t> explained in <xref target="separation" format="default" sectionFormat="of" deri
<t>With the algorithm introduced here, all ACP nodes in the same routing vedContent="Section 6.10"/>). This address may be used also in other virtual co
subdomain have the same /48 ULA prefix. Conversely, ULA global IDs from differ ntexts.</t>
ent domains are unlikely to clash, such that two ACP networks can be merged, as <t indent="0" pn="section-6.11-2">With the algorithm introduced here, al
long as the policy allows that merge. See also <xref target="self-healing" form l ACP nodes in the same routing subdomain have the same /48 ULA prefix. Convers
at="default"/> for a discussion on merging domains.</t> ely, ULA Global IDs from different domains are unlikely to clash, such that two
<t>Links inside the ACP only use link-local IPv6 addressing, such that e ACP networks can be merged, as long as the policy allows that merge. See also <
ach node's ACP only requires one routable address prefix.</t> xref target="self-healing" format="default" sectionFormat="of" derivedContent="S
<section anchor="addr-fundamentals" numbered="true" toc="default"> ection 10.1"/> for a discussion on merging domains.</t>
<name>Fundamental Concepts of Autonomic Addressing</name> <t indent="0" pn="section-6.11-3">Links inside the ACP only use link-loc
<ul spacing="compact"> al IPv6 addressing, such that each node's ACP only requires one routable address
<li>Usage: Autonomic addresses are exclusively used for self-managem prefix.</t>
ent functions inside a trusted domain. They are not used for user traffic. Com <section anchor="addr-fundamentals" numbered="true" toc="include" remove
munications with entities outside the trusted domain use another address space, InRFC="false" pn="section-6.11.1">
for example normally managed routable address space (called "Data-Plane" in this <name slugifiedName="name-fundamental-concepts-of-aut">Fundamental Con
document).</li> cepts of Autonomic Addressing</name>
<li>Separation: Autonomic address space is used separately from user <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
address space and other address realms. This supports the robustness requireme -6.11.1-1">
nt.</li> <li pn="section-6.11.1-1.1">Usage: autonomic addresses are exclusive
<li>Loopback-only: Only ACP Loopback interfaces (and potentially tho ly used for self-management functions inside a trusted domain. They are not use
se configured for "ACP connect", see <xref target="ACPconnect" format="default"/ d for user traffic. Communications with entities outside the trusted domain use
>) carry routable address(es); all other interfaces (called ACP virtual interfac another address space, for example, a normally managed routable address space (
es) only use IPv6 link local addresses. The usage of IPv6 link local addressing called "data plane" in this document).</li>
is discussed in <xref target="RFC7404" format="default"/>.</li> <li pn="section-6.11.1-1.2">Separation: autonomic address space is u
<li>Use-ULA: For Loopback interfaces of ACP nodes, we use ULA with L sed separately from user address space and other address realms. This supports
=1 (as defined in section 3.1 of <xref target="RFC4193" format="default"/>). Not the robustness requirement.</li>
e that the random hash for ACP Loopback addresses uses the definition in <xref t <li pn="section-6.11.1-1.3">Loopback only: only ACP loopback interfa
arget="scheme" format="default"/> and not the one of <xref target="RFC4193" form ces (and potentially those configured for ACP connect, see <xref target="ACPconn
at="default"/> section 3.2.2.</li> ect" format="default" sectionFormat="of" derivedContent="Section 8.1"/>) carry r
<li>No external connectivity: They do not provide access to the Inte outable address(es); all other interfaces (called ACP virtual interfaces) only u
rnet. If a node requires further reaching connectivity, it should use another, se IPv6 link-local addresses. The usage of IPv6 link-local addressing is discus
traditionally managed address scheme in parallel.</li> sed in "<xref target="RFC7404" format="title" sectionFormat="of" derivedContent=
<li>Addresses in the ACP are permanent, and do not support temporary "Using Only Link-Local Addressing inside an IPv6 Network"/>" <xref target="RFC74
addresses as defined in <xref target="RFC4941" format="default"/>.</li> 04" format="default" sectionFormat="of" derivedContent="RFC7404"/>.</li>
<li>Addresses in the ACP are not considered sensitive on privacy gro <li pn="section-6.11.1-1.4">Use of ULA: for loopback interfaces of A
unds because ACP nodes are not expected to be end-user hosts and ACP addresses d CP nodes, we use ULA with
o therefore not represent end-users or groups of end-users. All ACP nodes are i the L bit set to 1 (as defined in <xref target="RFC4193" sectionFormat
n one (potentially federated) administrative domain. They are assumed to be to b ="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc
e candidate hosts of ACP traffic amongst each other or transit thereof. There ar 4193#section-3.1" derivedContent="RFC4193"/>). Note that the random hash for ACP
e no transit nodes less privileged to know about the identity of other hosts in loopback addresses uses the definition in <xref target="scheme" format="default
the ACP. Therefore, ACP addresses do not need to be pseudo-random as discussed " sectionFormat="of" derivedContent="Section 6.11.2"/> and not the one in <xref
in <xref target="RFC7721" format="default"/>. Because they are not propagated t target="RFC4193" sectionFormat="comma" section="3.2.2" format="default" derivedL
o untrusted (non ACP) nodes and stay within a domain (of trust), we also conside ink="https://rfc-editor.org/rfc/rfc4193#section-3.2.2" derivedContent="RFC4193"/
r them not to be subject to scanning attacks.</li> >.</li>
<li pn="section-6.11.1-1.5">No external connectivity: the addresses
do not provide access to the Internet. If a node requires further connectivity,
it should use another, traditionally managed addressing scheme in parallel.</li
>
<li pn="section-6.11.1-1.6">Addresses in the ACP are permanent and d
o not support temporary addresses as defined in "<xref target="RFC8981" format="
title" sectionFormat="of" derivedContent="Temporary Address Extensions for State
less Address Autoconfiguration in IPv6"/>" <xref target="RFC8981" format="defaul
t" sectionFormat="of" derivedContent="RFC8981"/>.</li>
<li pn="section-6.11.1-1.7">Addresses in the ACP are not considered
sensitive on privacy grounds because ACP nodes are not expected to be end-user h
osts, and therefore ACP addresses do not represent end users or groups of end us
ers. All ACP nodes are in one (potentially federated) administrative domain. Fo
r ACP traffic, the nodes are assumed to be either candidate hosts or transit nod
es. There are no transit nodes with fewer privileges to know the identity of ot
her hosts in the ACP. Therefore, ACP addresses do not need to be pseudorandom a
s discussed in "<xref target="RFC7721" format="title" sectionFormat="of" derived
Content="Security and Privacy Considerations for IPv6 Address Generation Mechani
sms"/>" <xref target="RFC7721" format="default" sectionFormat="of" derivedConten
t="RFC7721"/>. Because they are not propagated to untrusted (non-ACP) nodes and
stay within a domain (of trust), we also do not consider them to be subject to
scanning attacks.</li>
</ul> </ul>
<t>The ACP is based exclusively on IPv6 addressing, for a variety of r <t indent="0" pn="section-6.11.1-2">The ACP is based exclusively on IP
easons: v6 addressing for a variety of reasons:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Simplicity, reliability and scale: If other network layer protoc -6.11.1-3">
ols were supported, each would have to have its own set of security associations <li pn="section-6.11.1-3.1">Simplicity, reliability, and scale: if o
, routing table and process, etc.</li> ther network-layer protocols were supported, each would have to have its own set
<li>Autonomic functions do not require IPv4: Autonomic functions and of security associations, routing table, and process, etc.</li>
autonomic service agents are new concepts. They can be exclusively built on IP <li pn="section-6.11.1-3.2">Autonomic functions do not require IPv4:
v6 from day one. There is no need for backward compatibility.</li> autonomic functions and autonomic service agents are new concepts. They can be
<li>OAM protocols do not require IPv4: The ACP may carry OAM protoco exclusively built on IPv6 from day one. There is no need for backward compatib
ls. All relevant protocols (SNMP, TFTP, SSH, SCP, RADIUS, Diameter, NETCONF ... ility.</li>
) are available in IPv6. See also <xref target="RFC8368" format="default"/> for <li pn="section-6.11.1-3.3">OAM protocols do not require IPv4: the A
how ACP could be made to interoperate with IPv4 only OAM.</li> CP may carry OAM protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, RADIU
S, Diameter, NETCONF, etc.) are available in IPv6. See also <xref target="RFC836
8" format="default" sectionFormat="of" derivedContent="RFC8368"/> for how ACP co
uld be made to interoperate with IPv4-only OAM.</li>
</ul> </ul>
<t>Further explanation about the addressing and routing related reason s for the choice of the autonomous ACP addressing can be found in <xref target=" ACP-loopback" format="default"/>.</t> <t indent="0" pn="section-6.11.1-4">Further explanation about the addr essing and routing-related reasons for the choice of the autonomous ACP addressi ng can be found in <xref target="ACP-loopback" format="default" sectionFormat="o f" derivedContent="Section 6.13.5.1"/>.</t>
</section> </section>
<section anchor="scheme" numbered="true" toc="default"> <section anchor="scheme" numbered="true" toc="include" removeInRFC="fals
<name>The ACP Addressing Base Scheme</name> e" pn="section-6.11.2">
<t>The Base ULA addressing scheme for ACP nodes has the following form <name slugifiedName="name-the-acp-addressing-base-sch">The ACP Address
at:</t> ing Base Scheme</name>
<figure anchor="base-addr-scheme"> <t indent="0" pn="section-6.11.2-1">The ULA addressing base scheme for
<name>ACP Addressing Base Scheme</name> ACP nodes has the following format:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <figure anchor="base-addr-scheme" align="left" suppress-title="false"
pn="figure-9">
<name slugifiedName="name-acp-addressing-base-scheme">ACP Addressing
Base Scheme</name>
<artwork name="" type="" align="left" alt="" pn="section-6.11.2-2.1"
>
8 40 2 78 8 40 2 78
+--+-------------------------+------+------------------------------+ +--+-------------------------+------+------------------------------+
|fd| hash(routing-subdomain) | Type | (sub-scheme) | |fd| hash(routing-subdomain) | Type | (sub-scheme) |
+--+-------------------------+------+------------------------------+ +--+-------------------------+------+------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t>The first 48-bits follow the ULA scheme, as defined in <xref target <t indent="0" pn="section-6.11.2-3">The first 48 bits follow the ULA s
="RFC4193" format="default"/>, to which a type field is added: cheme as defined in <xref target="RFC4193" format="default" sectionFormat="of" d
</t> erivedContent="RFC4193"/>, to which a Type field is added.
<ul spacing="compact"> </t>
<li>"fd" identifies a locally defined ULA address.</li> <dl spacing="normal" newline="false" indent="3" pn="section-6.11.2-4">
<li>The 40-bits ULA "global ID" (term from <xref target="RFC4193" fo <dt pn="section-6.11.2-4.1">fd:</dt>
rmat="default"/>) for ACP addresses carried in the acp-node-name in the ACP cert <dd pn="section-6.11.2-4.2">Identifies a locally defined ULA address
ificates are the first 40-bits of the SHA256 hash of the routing subdomain from .</dd>
the same acp-node-name. In the example of <xref target="domcert-acpinfo" format <dt pn="section-6.11.2-4.3">hash(routing-subdomain):</dt>
="default"/>, the routing subdomain is "area51.research.acp.example.com" and the <dd pn="section-6.11.2-4.4">
40-bits ULA "global ID" 89b714f3db.</li> <t indent="0" pn="section-6.11.2-4.4.1">The 40-bit ULA Global ID (
<li>When creating a new routing-subdomain for an existing autonomic a term from <xref target="RFC4193" format="default" sectionFormat="of" derivedCo
network, it MUST be ensured, that rsub is selected so the resulting hash of the ntent="RFC4193"/>) for ACP addresses carried in the acp-node-name in the ACP cer
routing-subdomain does not collide with the hash of any pre-existing routing-sub tificates are the first 40 bits of the SHA-256 hash of the routing-subdomain fro
domains of the autonomic network. This ensures that ACP addresses created by reg m the same acp-node-name. In the example of <xref target="domcert-acpinfo" form
istrars for different routing subdomains do not collide with each other.</li> at="default" sectionFormat="of" derivedContent="Section 6.2.2"/>, the routing-su
<li>To allow for extensibility, the fact that the ULA "global ID" is bdomain is "area51.research.acp.example.com", and the 40-bit ULA Global ID is 89
a hash of the routing subdomain SHOULD NOT be assumed by any ACP node during no b714f3db.</t>
rmal operations. The hash function is only executed during the creation of the <t indent="0" pn="section-6.11.2-4.4.2">When creating a new routin
certificate. If BRSKI is used, then the BRSKI registrar will create the acp-nod g-subdomain for an existing Autonomic Network, it <bcp14>MUST</bcp14> be ensured
e-name in response to the EST Certificate Signing Request (CSR) Attribute Reques that rsub is selected so the resulting hash of the routing-subdomain does not c
t message by the pledge.</li> ollide with the hash of any preexisting routing-subdomains of the Autonomic Netw
<li>Establishing connectivity between different ACP (different acp-d ork. This ensures that ACP addresses created by registrars for different routing
omain-name) is outside the scope of this specification. subdomains do not collide with each other.</t>
If it is being done through future extensions, then the rsub of all routing-sub <t indent="0" pn="section-6.11.2-4.4.3">To allow for extensibility
domains across those autonomic networks need to be selected so the resulting rou , the fact that the ULA Global ID is a hash of the routing-subdomain <bcp14>SHOU
ting-subdomain hashes do not collide. For example, a large cooperation with its LD NOT</bcp14> be assumed by any ACP node during normal operations. The hash fu
own private TA may want to create different autonomic networks that initially sh nction is only executed during the creation of the certificate. If BRSKI is use
ould not be able to connect but where the option to do so should be kept open. W d, then the BRSKI registrar will create the acp-node-name in response to the EST
hen taking this future possibility into account, it is easy to always select rsu Certificate Signing Request (CSR) Attributes Request message sent by the pledge
b so that no collisions happen.</li> .</t>
<li>Type: This field allows different address sub-schemes. This add <t indent="0" pn="section-6.11.2-4.4.4">Establishing connectivity
resses the "upgradability" requirement. Assignment of types for this field will between different ACPs (different acp-domain-names) is outside the scope of this
be maintained by IANA.</li> specification.
</ul> If it is being done through future extensions, then the rsub of all routing-sub
<t>The sub-scheme may imply a range or set of addresses assigned to th domains across those Autonomic Networks needs to be selected so that the resulti
e node, this is called the ACP address range/set and explained in each sub-schem ng routing-subdomain hashes do not collide. For example, a large cooperation wit
e.</t> h its own private TA may want to create different Autonomic Networks that initia
<t>Please refer to <xref target="acp-registrars" format="default"/> an lly do not connect but where the option to do so should be kept open. When takin
d <xref target="address-spaces" format="default"/> for further explanations why g this possibility into account, it is always easy to select rsub so that no col
the following Sub-Addressing schemes are used and why multiple are necessary.</t lisions happen.</t>
> </dd>
<t> <dt pn="section-6.11.2-4.5">Type:</dt>
The following summarizes the addressing Sub-Schemes: <dd pn="section-6.11.2-4.6">This field allows different addressing s
ub-schemes. This addresses the "upgradability" requirement. Assignment of type
s for this field will be maintained by IANA.</dd>
<dt pn="section-6.11.2-4.7">(sub-scheme):</dt>
<dd pn="section-6.11.2-4.8">The sub-scheme may imply a range or set
of addresses assigned to the node. This is called the ACP address range/set and
explained in each sub-scheme.</dd>
</dl>
<t indent="0" pn="section-6.11.2-5">Please refer to <xref target="acp-
registrars" format="default" sectionFormat="of" derivedContent="Section 6.11.7"/
> and <xref target="address-spaces" format="default" sectionFormat="of" derivedC
ontent="Appendix A.1"/> for further explanations for why the following addressin
g sub-schemes are used and why multiple are necessary.</t>
<t indent="0" pn="section-6.11.2-6">
The following summarizes the addressing sub-schemes:
</t> </t>
<figure anchor="addr-scheme-summary"> <table anchor="tab-1" align="center" pn="table-1">
<name>Addressing Sub-Schemes</name> <name slugifiedName="name-addressing-sub-schemes">Addressing Sub-Sch
<artwork name="" type="" align="left" alt=""><![CDATA[ emes</name>
+------+-----------------+-----------+-------------------+ <thead>
| Type | Name |F-bit| Z | V-bits | Prefix | <tr>
+------+-----------------+-----+-----+----------+--------+ <th align="left" colspan="1" rowspan="1">Type</th>
| 0x00 | ACP-Zone | N/A | 0 | 1 bit | /127 | <th align="left" colspan="1" rowspan="1">Name</th>
+------+-----------------+-----+-----+----------+--------+ <th align="left" colspan="1" rowspan="1">F-bit</th>
| 0x00 | ACP-Manual | N/A | 1 | N/A | /64 | <th align="left" colspan="1" rowspan="1">Z</th>
+------+-----------------+-----+-----+----------+--------+ <th align="left" colspan="1" rowspan="1">V-bits</th>
| 0x01 | ACP-VLong-8 | 0 | N/A | 8 bits | /120 | <th align="left" colspan="1" rowspan="1">Prefix</th>
+------+-----------------+-----+-----+----------+--------+ </tr>
| 0x01 | ACP-VLong-16 | 1 | N/A | 16 bits | /112 | </thead>
+------+-----------------+-----+-----+----------+--------+ <tbody>
| 0x10 | Reserved / For future definition/allocation | <tr>
+------+-----------------+-----+-----+----------+--------+ <td align="left" colspan="1" rowspan="1">0</td>
| 0x11 | Reserved / For future definition/allocation | <td align="left" colspan="1" rowspan="1">ACP-Zone</td>
+------+-----------------+-----+-----+----------+--------+ <td align="left" colspan="1" rowspan="1">N/A</td>
]]></artwork> <td align="left" colspan="1" rowspan="1">0</td>
</figure> <td align="left" colspan="1" rowspan="1">1 bit</td>
<t>F-Bit and Z are two encoding fields explained below for <td align="left" colspan="1" rowspan="1">/127</td>
the Sub-Schemes that introduce/use them. V-bits is the number </tr>
<tr>
<td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">ACP-Manual</td>
<td align="left" colspan="1" rowspan="1">N/A</td>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">N/A</td>
<td align="left" colspan="1" rowspan="1">/64</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">ACP-Vlong-8</td>
<td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">N/A</td>
<td align="left" colspan="1" rowspan="1">8 bits</td>
<td align="left" colspan="1" rowspan="1">/120</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">ACP-Vlong-16</td>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">N/A</td>
<td align="left" colspan="1" rowspan="1">16 bits</td>
<td align="left" colspan="1" rowspan="1">/112</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2</td>
<td colspan="5" align="left" rowspan="1">Reserved / For future d
efinition/allocation</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">3</td>
<td colspan="5" align="left" rowspan="1">Reserved / For future d
efinition/allocation</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-6.11.2-8">The F-bit (format bit, <xref targe
t="Vlong" format="default" sectionFormat="of" derivedContent="Section 6.11.5"/>)
and Z (<xref target="manual-scheme" format="default" sectionFormat="of" derived
Content="Section 6.11.4"/>) are two encoding fields that are explained in the se
ctions covering
the sub-schemes that use them. V-bits is the number
of bits of addresses allocated to the ACP node. of bits of addresses allocated to the ACP node.
Prefix is the prefix the ACP node is announcing into the Prefix is the prefix that the ACP node is announcing into
RPL routing protocol.</t> RPL.</t>
</section> </section>
<!-- base-scheme --> <section anchor="zone-scheme" numbered="true" toc="include" removeInRFC=
<section anchor="zone-scheme" numbered="true" toc="default"> "false" pn="section-6.11.3">
<name>ACP Zone Addressing Sub-Scheme (ACP-Zone)</name> <name slugifiedName="name-acp-zone-addressing-sub-sch">ACP Zone Addres
<t>This sub-scheme is used when the Type field of the base scheme is 0 sing Sub-Scheme (ACP-Zone)</name>
x00 and the Z bit is 0x0.</t> <t indent="0" pn="section-6.11.3-1">This sub-scheme is used when the T
<figure anchor="addr-scheme"> ype field of the base scheme is 0 and the Z bit is 0.</t>
<name>ACP Zone Addressing Sub-Scheme</name> <figure anchor="addr-scheme" align="left" suppress-title="false" pn="f
<artwork name="" type="" align="left" alt=""><![CDATA[ igure-10">
<name slugifiedName="name-acp-zone-addressing-sub-sche">ACP Zone Add
ressing Sub-Scheme</name>
<artwork name="" type="" align="left" alt="" pn="section-6.11.3-2.1"
>
64 64 64 64
+-----------------+---+---------++-----------------------------+---+ +-----------------+---+---------++-----------------------------+---+
| (base scheme) | Z | Zone-ID || Node-ID | | (base scheme) | Z | Zone-ID || Node-ID |
| | | || Registrar-ID | Node-Number| V | | | | || Registrar-ID | Node-Number| V |
+-----------------+---+---------++--------------+--------------+---+ +-----------------+---+---------++--------------+--------------+---+
50 1 13 48 15 1 50 1 13 48 15 1
]]></artwork> </artwork>
</figure> </figure>
<t>The fields are defined as follows:</t> <t indent="0" pn="section-6.11.3-3">The fields are defined as follows:
<ul spacing="compact"> </t>
<li>Type: MUST be 0x0.</li> <dl spacing="normal" newline="false" indent="3" pn="section-6.11.3-4">
<li>Z: MUST be 0x0.</li> <dt pn="section-6.11.3-4.1">Type:</dt>
<li>Zone-ID: A value for a network zone.</li> <dd pn="section-6.11.3-4.2">
<li>Node-ID: A unique value for each node.</li> <bcp14>MUST</bcp14> be 0.</dd>
</ul> <dt pn="section-6.11.3-4.3">Z: </dt>
<t>The 64-bit Node-ID must be unique across the ACP domain for each no <dd pn="section-6.11.3-4.4">
de. It is derived and composed as follows:</t> <bcp14>MUST</bcp14> be 0.</dd>
<ul spacing="compact"> <dt pn="section-6.11.3-4.5">Zone-ID:</dt>
<li>Registrar-ID (48-bit): A number unique inside the domain that id <dd pn="section-6.11.3-4.6"> A value for a network zone.</dd>
entifies the ACP registrar which assigned the Node-ID to the node. One or more <dt pn="section-6.11.3-4.7">Node-ID:</dt>
domain-wide unique identifiers of the ACP registrar can be used for this purpose <dd pn="section-6.11.3-4.8">
. See <xref target="registrars-unique" format="default"/>.</li> <t indent="0" pn="section-6.11.3-4.8.1">A unique value for each no
<li>Node-Number: Number to make the Node-ID unique. This can be seq de.</t>
uentially assigned by the ACP Registrar owning the Registrar-ID.</li> <t indent="0" pn="section-6.11.3-4.8.2">The 64-bit Node-ID must be
<li>V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP unique across the ACP domain for each node. It is derived and composed as follo
node base system); 1: Indicates the optional "host" context on the ACP node (se ws:</t>
e below).</li> <dl spacing="normal" newline="false" indent="3" pn="section-6.11.3
</ul> -4.8.3">
<t>In the ACP Zone Addressing Sub-Scheme, the ACP address in the certi <dt pn="section-6.11.3-4.8.3.1">Registrar-ID (48 bits): </dt>
ficate has V field as all zero bits.</t> <dd pn="section-6.11.3-4.8.3.2">A number unique inside the domai
<t>The ACP address set of the node includes addresses with any Zone-ID n identifying the ACP registrar that assigned the Node-ID to the node. One or m
value and any V value. No two nodes in the same ACP can have the same Node-ID, ore domain-wide unique identifiers of the ACP registrar can be used for this pur
but different Zone-IDs.</t> pose. See <xref target="registrars-unique" format="default" sectionFormat="of" d
<t>The Virtual bit in this sub-scheme allows the easy addition of the erivedContent="Section 6.11.7.2"/>.</dd>
ACP as a component to existing systems without causing problems in the port numb <dt pn="section-6.11.3-4.8.3.3">Node-Number:</dt>
er space between the services in the ACP and the existing system. V:0 is the AC <dd pn="section-6.11.3-4.8.3.4"> A number to make the Node-ID un
P router (autonomic node base system), V:1 is the host with pre-existing transpo ique. This can be sequentially assigned by the ACP registrar owning the Registr
rt endpoints on it that could collide with the transport endpoints used by the A ar-ID.</dd>
CP router. The ACP host could for example have a p2p virtual interface with the </dl>
V:0 address as its router into the ACP. Depending on the software design of AS </dd>
As, which is outside the scope of this specification, they may use the V:0 or V: <dt pn="section-6.11.3-4.9">V (1 bit):</dt>
1 address.</t> <dd pn="section-6.11.3-4.10">
<t>The location of the V bit(s) at the end of the address allows the a <t indent="0" pn="section-6.11.3-4.10.1">Virtualization bit:</t>
nnouncement of a single prefix for each ACP node. For example, in a network wit <dl spacing="normal" newline="false" indent="3" pn="section-6.11.3
h 20,000 ACP nodes, this avoid 20,000 additional routes in the routing table.</t -4.10.2">
> <dt pn="section-6.11.3-4.10.2.1">0:</dt>
<t>It is RECOMMENDED that only Zone-ID 0 is used unless it is meant to <dd pn="section-6.11.3-4.10.2.2">Indicates the ACP itself ("ACP
be node base system)</dd>
used in conjunction with operational practices for partial/incre <dt pn="section-6.11.3-4.10.2.3">1:</dt>
mental adoption <dd pn="section-6.11.3-4.10.2.4">Indicates the optional "host" c
of the ACP as described in <xref target="incremental-adoption" f ontext on the ACP node (see below).</dd>
ormat="default"/>.</t> </dl>
<t>Note: Zones and Zone-ID as defined here are not related to <xref ta </dd>
rget="RFC4007" format="default"/> zones or zone_id. ACP zone addresses are not s </dl>
coped (reachable only from within an RFC4007 zone) but reachable across the whol <t indent="0" pn="section-6.11.3-5">In the Zone Addressing Sub-Scheme,
e ACP. An RFC4007 zone_id is a zone index that has only local significance on a the ACP address in the certificate has V field as all zero bits.</t>
node, whereas an ACP Zone-ID is an identifier for an ACP zone that is unique acr <t indent="0" pn="section-6.11.3-6">The ACP address set of the node in
oss that ACP.</t> cludes addresses with any Zone-ID value and any V value. Therefore, no two nodes
in the same ACP and the same hash(routing-subdomain)
can have the same Node-ID with the Zone Addressing Sub-Scheme, for
example, by differing only in their Zone-ID.</t>
<t indent="0" pn="section-6.11.3-7">The Virtualization bit in this sub
-scheme allows the easy addition of the ACP as a component to existing systems w
ithout causing problems in the port number space between the services in the ACP
and the existing system. V=0 is the ACP router (autonomic node base system), V
=1 is the host with preexisting transport endpoints on it that could collide wit
h the transport endpoints used by the ACP router. The ACP host could, for examp
le, have a P2P (peer-to-peer) virtual interface with the V=0 address as its rout
er to the ACP. Depending on the software design of ASAs, which is outside the s
cope of this specification, they may use the V=0 or V=1 address.</t>
<t indent="0" pn="section-6.11.3-8">The location of the V bit(s) at th
e end of the address allows the announcement of a single prefix for each ACP nod
e. For example, in a network with 20,000 ACP nodes, this avoids 20,000 addition
al routes in the routing table.</t>
<t indent="0" pn="section-6.11.3-9">It is <bcp14>RECOMMENDED</bcp14> t
hat only Zone-ID 0 is used unless it is meant to be
used in conjunction with operational practices for partial or in
cremental adoption
of the ACP as described in <xref target="incremental-adoption" f
ormat="default" sectionFormat="of" derivedContent="Section 9.4"/>.</t>
<t indent="0" pn="section-6.11.3-10">Note: Zones and Zone-ID as define
d here are not related to zones or zone_id defined in "<xref target="RFC4007" fo
rmat="title" sectionFormat="of" derivedContent="IPv6 Scoped Address Architecture
"/>" <xref target="RFC4007" format="default" sectionFormat="of" derivedContent="
RFC4007"/>. ACP zone addresses are not scoped (i.e., reachable only from within
a zone as defined by <xref target="RFC4007" format="default" sectionFormat="of"
derivedContent="RFC4007"/>) but are reachable across the whole ACP. A zone_id is
a zone index that has only local significance on a node <xref target="RFC4007"
format="default" sectionFormat="of" derivedContent="RFC4007"/>, whereas an ACP Z
one-ID is an identifier for an ACP zone that is unique across that ACP.</t>
</section> </section>
<!-- zone-scheme --> <section anchor="manual-scheme" numbered="true" toc="include" removeInRF
<section anchor="manual-scheme" numbered="true" toc="default"> C="false" pn="section-6.11.4">
<name>ACP Manual Addressing Sub-Scheme (ACP-Manual)</name> <name slugifiedName="name-acp-manual-addressing-sub-s">ACP Manual Addr
<t>This sub-scheme is used when the Type field of the base scheme is 0 essing Sub-Scheme (ACP-Manual)</name>
x00 and the Z bit is 0x1.</t> <t indent="0" pn="section-6.11.4-1">This sub-scheme is used when the T
<figure anchor="manual-scheme-pic"> ype field of the base scheme is 0 and the Z bit is 1.</t>
<name>ACP Manual Addressing Sub-Scheme</name> <figure anchor="manual-scheme-pic" align="left" suppress-title="false"
<artwork name="" type="" align="left" alt=""><![CDATA[ pn="figure-11">
<name slugifiedName="name-acp-manual-addressing-sub-sc">ACP Manual A
ddressing Sub-Scheme</name>
<artwork name="" type="" align="left" alt="" pn="section-6.11.4-2.1"
>
64 64 64 64
+---------------------+---+----------++-----------------------------+ +---------------------+---+----------++-----------------------------+
| (base scheme) | Z | Subnet-ID|| Interface Identifier | | (base scheme) | Z | Subnet-ID|| Interface Identifier |
+---------------------+---+----------++-----------------------------+ +---------------------+---+----------++-----------------------------+
50 1 13 50 1 13
]]></artwork> </artwork>
</figure> </figure>
<t>The fields are defined as follows: <t indent="0" pn="section-6.11.4-3">The fields are defined as follows:
</t> </t>
<ul spacing="compact"> <dl spacing="normal" newline="false" indent="3" pn="section-6.11.4-4">
<li>Type: MUST be 0x0.</li> <dt pn="section-6.11.4-4.1">Type:</dt>
<li>Z: MUST be 0x1.</li> <dd pn="section-6.11.4-4.2">
<li>Subnet-ID: Configured subnet identifier.</li> <bcp14>MUST</bcp14> be 0.</dd>
<li>Interface Identifier.</li> <dt pn="section-6.11.4-4.3">Z:</dt>
</ul> <dd pn="section-6.11.4-4.4">
<t>This sub-scheme is meant for "manual" allocation to subnets where t <bcp14>MUST</bcp14> be 1.</dd>
he other addressing schemes cannot be used. The primary use case is for assignm <dt pn="section-6.11.4-4.5">Subnet-ID:</dt>
ent to ACP connect subnets (see <xref target="NMS" format="default"/>).</t> <dd pn="section-6.11.4-4.6"> Configured subnet identifier.</dd>
<t>"Manual" means that allocations of the Subnet-ID need to be done to <dt pn="section-6.11.4-4.7">Interface Identifier:</dt>
day with pre-existing, non-autonomic mechanisms. Every subnet that uses this ad <dd pn="section-6.11.4-4.8">Interface identifier according to <xref
dressing sub-scheme needs to use a unique Subnet-ID (unless some anycast setup i target="RFC4291" format="default" sectionFormat="of" derivedContent="RFC4291"/>.
s done).</t> </dd>
<t>The Z bit field was added to distinguish Zone addressing and manual </dl>
addressing sub-schemes without requiring one more bit in the base scheme and th <t indent="0" pn="section-6.11.4-5">This sub-scheme is meant for the "
erefore allowing for the Vlong scheme (described below) to have one more bit ava manual" allocation to subnets where the other addressing schemes cannot be used.
ilable.</t> The primary use case is for assignment to ACP connect subnets (see <xref targe
<t>Manual addressing sub-scheme addresses SHOULD NOT be used in ACP ce t="NMS" format="default" sectionFormat="of" derivedContent="Section 8.1.1"/>).</
rtificates. Any node capable to build ACP secure channels and permitted by Regis t>
trar policy to participate in building ACP secure channels SHOULD receive an ACP <t indent="0" pn="section-6.11.4-6">"Manual" means that allocations of
address (prefix) from one of the other ACP addressing sub-schemes. Nodes not c the Subnet-ID need to be done with preexisting, non-autonomic mechanisms. Ever
apable (or permitted) to participate in ACP secure channels can connect to the A y subnet that uses this addressing sub-scheme needs to use a unique Subnet-ID (u
CP via ACP connect interfaces of ACP edge nodes (see <xref target="ACPconnect" f nless some anycast setup is done).</t>
ormat="default"/>), without setting up an ACP secure channel. Their ACP certific <t indent="0" pn="section-6.11.4-7">The Z bit field was added to disti
ate MUST omit the acp-address field to indicate that their ACP certificate is on nguish between the Zone Addressing Sub-Scheme and the Manual Addressing Sub-Sche
ly usable for non- ACP secure channel authentication, such as end-to-end transpo me without requiring one more bit in the base scheme and therefore allowing for
rt connections across the ACP or Data-Plane.</t> the Vlong Addressing Sub-Scheme (described in <xref target="Vlong" format="defau
<t>Address management of ACP connect subnets is done using traditional lt" sectionFormat="of" derivedContent="Section 6.11.5"/>) to have one more bit a
assignment methods and existing IPv6 protocols. See <xref target="ACautoconfig" vailable.</t>
format="default"/> for details. Therefore, the notion of V-bit many addresses a <t indent="0" pn="section-6.11.4-8">The Manual Addressing Sub-Scheme a
ssigned to the ACP nodes does not apply to this Sub-Scheme.</t> ddresses <bcp14>SHOULD NOT</bcp14> be used in ACP certificates. Any node capable
of building ACP secure channels and is permitted by registrar policy to partici
pate in building ACP secure channels <bcp14>SHOULD</bcp14> receive an ACP addres
s (prefix) from one of the other ACP addressing sub-schemes. A node that cannot
or is not permitted to participate in ACP secure channels can connect to the AC
P via ACP connect interfaces of ACP edge nodes (see <xref target="ACPconnect" fo
rmat="default" sectionFormat="of" derivedContent="Section 8.1"/>) without settin
g up an ACP secure channel. Its ACP certificate <bcp14>MUST</bcp14> omit the acp
-address field to indicate that its ACP certificate is only usable for non-ACP s
ecure channel authentication, such as end-to-end transport connections across th
e ACP or data plane.</t>
<t indent="0" pn="section-6.11.4-9">Address management of ACP connect
subnets is done using traditional assignment methods and existing IPv6 protocols
. See <xref target="ACautoconfig" format="default" sectionFormat="of" derivedCon
tent="Section 8.1.3"/> for details. Therefore, the notion of /V-bits multiple ad
dresses assigned to the ACP nodes does not apply to this sub-scheme.</t>
</section> </section>
<!-- manual --> <section anchor="Vlong" numbered="true" toc="include" removeInRFC="false
<section anchor="Vlong" numbered="true" toc="default"> " pn="section-6.11.5">
<name>ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16</name> <name slugifiedName="name-acp-vlong-addressing-sub-sc">ACP Vlong Addre
<t>This sub-scheme is used when the Type field of the base scheme is 0 ssing Sub-Scheme (ACP-Vlong-8/ACP-Vlong-16)</name>
x01.</t> <t indent="0" pn="section-6.11.5-1">This addressing sub-scheme is used
<figure anchor="v8-scheme"> when the Type field of the base scheme is 1.</t>
<name>ACP Vlong Addressing Sub-Scheme</name> <figure anchor="v8-scheme" align="left" suppress-title="false" pn="fig
<artwork name="" type="" align="left" alt=""><![CDATA[ ure-12">
<name slugifiedName="name-acp-vlong-addressing-sub-sch">ACP Vlong Ad
dressing Sub-Scheme</name>
<artwork name="" type="" align="left" alt="" pn="section-6.11.5-2.1"
>
50 78 50 78
+---------------------++-----------------------------+----------+ +---------------------++-----------------------------+----------+
| (base scheme) || Node-ID | | (base scheme) || Node-ID |
| || Registrar-ID |F| Node-Number| V | | || Registrar-ID |F| Node-Number| V |
+---------------------++--------------+--------------+----------+ +---------------------++--------------+--------------+----------+
50 46 1 23/15 8/16 50 46 1 23/15 8/16
]]></artwork> </artwork>
</figure> </figure>
<t> <t indent="0" pn="section-6.11.5-3">
This addressing scheme foregoes the Zone-ID field to allow This addressing sub-scheme foregoes the Zone-ID field (<xref t
arget="zone-scheme" format="default" sectionFormat="of" derivedContent="Section
6.11.3"/>) to allow
for larger, flatter routed networks (e.g., as in IoT) with for larger, flatter routed networks (e.g., as in IoT) with
8421376 Node-Numbers (2^23+2^15). It also allows for up to 8,421,376 Node-Numbers (2<sup>23</sup> + 2<sup>15</sup>). It
2^16 (i.e. 65536) different virtualized addresses within a also allows for up to
2<sup>16</sup> (i.e., 65,536) different virtualized addresses
within a
node, which could be used to address individual software node, which could be used to address individual software
components in an ACP node. components in an ACP node.
</t> </t>
<t> <t indent="0" pn="section-6.11.5-4">
The fields are the same as in the Zone-ID sub-scheme with the The fields are the same as in the Zone Addressing Sub-Scheme (<x
ref target="zone-scheme" format="default" sectionFormat="of" derivedContent="Sec
tion 6.11.3"/>) with the
following refinements:</t> following refinements:</t>
<ul spacing="compact"> <dl spacing="normal" newline="false" indent="3" pn="section-6.11.5-5">
<li> <dt pn="section-6.11.5-5.1">
F: format bit. This bit determines the format of the F:</dt>
<dd pn="section-6.11.5-5.2">Format bit. This bit determines the for
mat of the
subsequent bits. subsequent bits.
</li> </dd>
<li> <dt pn="section-6.11.5-5.3">
V: Virtualization bit: this is a field that is V:</dt>
<dd pn="section-6.11.5-5.4">Virtualization bit: this is a field that
is
either 8 or 16 bits. For F=0, it is 8 bits, for F=1 either 8 or 16 bits. For F=0, it is 8 bits, for F=1
it is 16 bits. The V bits are assigned by the ACP it is 16 bits. The V-bits are assigned by the ACP
node. In the ACP certificate's ACP address <xref target="do node. In the ACP certificate's ACP address (<xref target="d
mcert-acpinfo" format="default"/>, the V-bits are always omcert-acpinfo" format="default" sectionFormat="of" derivedContent="Section 6.2.
2"/>), the V-bits are always
set to 0. set to 0.
</li> </dd>
<li> <dt pn="section-6.11.5-5.5">
Registrar-ID: To maximize Node-Number and V, the Registrar-ID:</dt>
Registrar-ID is reduced to 46-bits. One or more domain-wide <dd pn="section-6.11.5-5.6"> To maximize Node-Number and V, the
unique identifiers of the ACP registrar can be used for this purpose. See <xref Registrar-ID is reduced to 46 bits. One or more domain-wide
target="registrars-unique" format="default"/>. unique identifiers of the ACP registrar can be used for this purpose. See <xref
</li> target="registrars-unique" format="default" sectionFormat="of" derivedContent="S
<li> ection 6.11.7.2"/>.
The Node-Number is unique to each ACP node. There are </dd>
<dt pn="section-6.11.5-5.7">
Node-Number:</dt>
<dd pn="section-6.11.5-5.8">The Node-Number is unique to each ACP no
de. There are
two formats for the Node-Number. When F=0, the two formats for the Node-Number. When F=0, the
node-number is 23 bits, for F=1 it is 15 bits. Node-Number is 23 bits, for F=1, it is 15 bits.
Each format of node-number is considered to be in a Each format of Node-Number is considered to be in a
unique number space. unique number space.
</li> </dd>
</ul> </dl>
<t> <t indent="0" pn="section-6.11.5-6">
The F=0 bit format addresses are intended to be used for The F=0 bit format addresses are intended to be used for
"general purpose" ACP nodes that would potentially have a "general purpose" ACP nodes that would potentially have a
limited number (&lt; 256) of clients (ASA/Autonomic Functions limited number (less than 256) of clients (ASA and/or autonomi c functions
or legacy services) of the ACP that require separate or legacy services) of the ACP that require separate
V(irtual) addresses. V(irtual) addresses.
</t> </t>
<t> <t indent="0" pn="section-6.11.5-7">
The F=1 bit Node-Numbers are intended for The F=1 bit Node-Numbers are intended for
ACP nodes that are ACP edge nodes (see <xref target="NMS" form at="default"/>) ACP nodes that are ACP edge nodes (see <xref target="NMS" form at="default" sectionFormat="of" derivedContent="Section 8.1.1"/>)
or that have a large number of clients requiring separate or that have a large number of clients requiring separate
V(irtual) addresses. For example, large SDN controllers with V(irtual) addresses, for example, large SDN controllers with
container modular software architecture (see <xref target="sof container modular software architecture (see <xref target="sof
tware" format="default"/>). tware" format="default" sectionFormat="of" derivedContent="Section 8.1.2"/>).
</t> </t>
<t> <t indent="0" pn="section-6.11.5-8">
In the Vlong addressing sub-scheme, the ACP address in the In the Vlong Addressing Sub-Scheme, the ACP address in the
certificate has all V field bits as zero. The ACP address certificate has all V field bits as zero. The ACP address
set for the node includes any V value. set for the node includes any V value.
</t> </t>
</section> </section>
<!-- Vlong --> <section anchor="other-sub-schemes" numbered="true" toc="include" remove
<section anchor="other-sub-schemes" numbered="true" toc="default"> InRFC="false" pn="section-6.11.6">
<name>Other ACP Addressing Sub-Schemes</name> <name slugifiedName="name-other-acp-addressing-sub-sc">Other ACP Addre
<t>Before further addressing sub-schemes are defined, experience with ssing Sub-Schemes</name>
the schemes defined here should be collected. The schemes defined in this docum <t indent="0" pn="section-6.11.6-1">Before further addressing sub-sche
ent have been devised to allow hopefully sufficiently flexible setup of ACPs for mes are defined, experience with the schemes defined here should be collected.
a variety of situation. These reasons also lead to the fairly liberal use of a The schemes defined in this document have been devised to allow hopefully a suff
ddress space: The Zone Addressing Sub-Scheme is intended to enable optimized rou iciently flexible setup of ACPs for a variety of situations. These reasons also
ting in large networks by reserving bits for Zone-ID's. The Vlong addressing su lead to the fairly liberal use of address space: the Zone Addressing Sub-Scheme
b-scheme enables the allocation of 8/16-bit of addresses inside individual ACP n is intended to enable optimized routing in large networks by reserving bits for
odes. Both address spaces allow distributed, uncoordinated allocation of node a Zone-IDs. The Vlong Addressing Sub-Scheme enables the allocation of 8/16-bit o
ddresses by reserving bits for the registrar-ID field in the address.</t> f addresses inside individual ACP nodes. Both address spaces allow distributed,
uncoordinated allocation of node addresses by reserving bits for the Registrar-
ID field in the address.</t>
</section> </section>
<section anchor="acp-registrars" numbered="true" toc="default"> <section anchor="acp-registrars" numbered="true" toc="include" removeInR
<name>ACP Registrars</name> FC="false" pn="section-6.11.7">
<t>ACP registrars are responsible to enroll candidate ACP nodes <name slugifiedName="name-acp-registrars">ACP Registrars</name>
with ACP certificates and associated trust anchor(s). They are <t indent="0" pn="section-6.11.7-1">ACP registrars are responsible for
also responsible that an acp-node-name field enrolling candidate ACP nodes
is included in the ACP certificate carrying the ACP with ACP certificates and associated trust anchor(s). They are also
domain name and the ACP nodes ACP address prefix. This address responsible for including an acp-node-name field in the ACP
certificate. This field carries the ACP domain name and the ACP
node's ACP address prefix. This address
prefix is intended to persist unchanged through the lifetime of the prefix is intended to persist unchanged through the lifetime of the
ACP node.</t> ACP node.</t>
<t>Because of the ACP addressing sub-schemes, an ACP domain can have <t indent="0" pn="section-6.11.7-2">Because of the ACP addressing sub- schemes, an ACP domain can have
multiple distributed ACP registrars that do not need to coordinate multiple distributed ACP registrars that do not need to coordinate
for address assignment. ACP registrars can also be sub-CAs, in for address assignment. ACP registrars can also be sub-CAs, in
which case they can also assign ACP certificates without which case they can also assign ACP certificates without
dependencies against a (shared) TA (except during renewals dependencies against a (shared) TA (except during renewals
of their own certificates).</t> of their own certificates).</t>
<t>ACP registrars are PKI registration authorities (RA) enhanced with <t indent="0" pn="section-6.11.7-3">ACP registrars are PKI registratio
the handling of the ACP certificate specific fields. They n authorities (RA) enhanced with
request certificates for ACP nodes from a Certification Authority the handling of the ACP certificate-specific fields. They
request certificates for ACP nodes from a CA
through any appropriate mechanism (out of scope in this document, through any appropriate mechanism (out of scope in this document,
but required to be BRSKI for ANI registrars). Only nodes that but this mechanism is required to be BRSKI for ANI registrars). Only nodes that
are trusted to be compliant with the requirements against registrar are trusted to be compliant with the registrar requirements
described in this section can be given the necessary credentials described in this section can be given the necessary credentials
to perform this RA function, such as credentials for the BRSKI to perform this RA function, such as the credential for the ACP registrar to con
connection to the CA for ANI registrars.</t> nect to the CA
<section anchor="registrars-protocols" numbered="true" toc="default"> as a registrar.</t>
<name>Use of BRSKI or other Mechanism/Protocols</name> <section anchor="registrars-protocols" numbered="true" toc="include" r
<t>Any protocols or mechanisms may be used by ACP registrars, emoveInRFC="false" pn="section-6.11.7.1">
as long as the resulting ACP certificate and TA certificate(s) allow <name slugifiedName="name-use-of-brski-or-other-mecha">Use of BRSKI
to perform the ACP domain membership described in <xref target="certcheck" forma or Other Mechanisms or Protocols</name>
t="default"/> <t indent="0" pn="section-6.11.7.1-1">Any protocols or mechanisms ma
with other ACP domain members, and meet the ACP addressing y be used by ACP registrars
requirements for its acp-node-name as described further below in this section.</ as long as the resulting ACP certificate and TA certificate(s) can be used
t> by other domain members to perform the ACP domain membership check described in
<t>An ACP registrar could be a person deciding whether to <xref target="certcheck" format="default" sectionFormat="of" derivedContent="Sec
tion 6.2.3"/>,
and the acp-node-name meets the ACP addressing
requirements described in the next three sections.</t>
<t indent="0" pn="section-6.11.7.1-2">An ACP registrar could be a pe
rson deciding whether to
enroll a candidate ACP node and then orchestrating the enroll a candidate ACP node and then orchestrating the
enrollment of the ACP certificate and associated TA, enrollment of the ACP certificate and associated TA,
using command line or web based commands on the candidate ACP node using command line or web-based commands on the candidate ACP node
and TA to generate and sign the ACP certificate and TA to generate and sign the ACP certificate
and configure certificate and TA onto the node.</t> and configure certificate and TA onto the node.</t>
<t>The only currently defined protocol for ACP registrars is BRSKI <t indent="0" pn="section-6.11.7.1-3">The only currently defined pro
(<xref target="I-D.ietf-anima-bootstrapping-keyinfra" format="default"/>). When tocol for ACP registrars is BRSKI
BRSKI <xref target="RFC8995" format="default" sectionFormat="of" derivedContent="RFC89
95"/>. When BRSKI
is used, the ACP nodes are called ANI nodes, and the ACP registrars is used, the ACP nodes are called ANI nodes, and the ACP registrars
are called BRSKI or ANI registrars. The BRSKI specification does not define the are called BRSKI or ANI registrars. The BRSKI specification does not define the
handling of the acp-node-name field because the rules handling of the acp-node-name field because the rules
do not depend on BRSKI but apply equally to any protocols/mechanisms an do not depend on BRSKI but apply equally to any protocols or mechanisms that an
ACP registrar may use.</t> ACP registrar may use.</t>
</section> </section>
<section anchor="registrars-unique" numbered="true" toc="default"> <section anchor="registrars-unique" numbered="true" toc="include" remo
<name>Unique Address/Prefix allocation</name> veInRFC="false" pn="section-6.11.7.2">
<t>ACP registrars MUST NOT allocate ACP address prefixes to ACP node <name slugifiedName="name-unique-address-prefix-alloc">Unique Addres
s s/Prefix Allocation</name>
<t indent="0" pn="section-6.11.7.2-1">ACP registrars <bcp14>MUST NOT
</bcp14> allocate ACP address prefixes to ACP nodes
via the acp-node-name that would collide via the acp-node-name that would collide
with the ACP address prefixes of other ACP nodes in the same ACP domain. with the ACP address prefixes of other ACP nodes in the same ACP domain.
This includes both prefixes allocated by the same ACP registrar to This includes both prefixes allocated by the same ACP registrar to
different ACP nodes as well as prefixes allocated by other ACP registrars different ACP nodes as well as prefixes allocated by other ACP registrars
for the same ACP domain.</t> for the same ACP domain.</t>
<t>To support such unique address allocation, an ACP registrar MUST <t indent="0" pn="section-6.11.7.2-2">To support such unique address
have allocation, an ACP registrar <bcp14>MUST</bcp14> have
one or more 46-bit identifiers unique across the ACP domain which is called the one or more 46-bit identifiers, called the Registrar-ID, that are unique across
Registrar-ID. Allocation of Registrar-ID(s) to an ACP registrar can happen thro the ACP domain.
ugh Allocation of Registrar-ID(s) to an ACP registrar can happen through
OAM mechanisms in conjunction with some database / allocation orchestration.</t> OAM mechanisms in conjunction with some database and/or allocation orchestration
<t>ACP registrars running on physical devices with known globally un .</t>
ique <t indent="0" pn="section-6.11.7.2-3">ACP registrars running on phys
EUI-48 MAC address(es) can use the lower 46 bits of those address(es) ical devices with known globally unique
as unique Registrar-IDs without requiring any external signaling/configuration EUI-48 MAC address(es) (EUI stands for "Extended Unique Identifier") can use the
(the upper two bits, V and U are not uniquely assigned but functional). lower 46 bits of those address(es)
as unique Registrar-IDs without requiring any external signaling and/or configur
ation
(the upper two bits, V and U, are not uniquely assigned but are functional).
This approach is attractive for distributed, non-centrally administered, lightwe ight This approach is attractive for distributed, non-centrally administered, lightwe ight
ACP registrar implementations. There is no mechanism to deduce from a MAC ACP registrar implementations. There is no mechanism to deduce from a MAC
address itself whether it is actually uniquely assigned. Implementations need address itself whether it is actually uniquely assigned. Implementations need
to consult additional offline information before making this assumption. For to consult additional offline information before making this assumption, for
example by knowing that a particular physical product/MIC-chip is example, by knowing that a particular physical product or Network Interface Cont
roller (NIC) chip is
guaranteed to use globally unique assigned EUI-48 MAC address(es).</t> guaranteed to use globally unique assigned EUI-48 MAC address(es).</t>
<t>When the candidate ACP device (called Pledge in BRSKI) is to be <t indent="0" pn="section-6.11.7.2-4">When the candidate ACP device (called pledge in BRSKI) is to be
enrolled into an ACP domain, the ACP registrar needs to allocate enrolled into an ACP domain, the ACP registrar needs to allocate
a unique ACP address to the node and ensure that the ACP certificate a unique ACP address to the node and ensure that the ACP certificate
gets a acp-node-name field (<xref target="domcert-acpinfo" format="default"/>) gets an acp-node-name field (<xref target="domcert-acpinfo" format="default" sec
with the appropriate information - ACP domain-name, ACP-address, tionFormat="of" derivedContent="Section 6.2.2"/>)
with the appropriate information: ACP domain name, ACP address,
and so on. If the ACP registrar uses BRSKI, it signals the ACP and so on. If the ACP registrar uses BRSKI, it signals the ACP
acp-node-name field to the Pledge via the EST /csrattrs command acp-node-name field to the pledge via EST CSR Attributes
(see <xref target="I-D.ietf-anima-bootstrapping-keyinfra" format="default"/>, (see <xref target="RFC8995" sectionFormat="comma" section="5.9.2" format="defaul
section 5.9.2 - "EST CSR Attributes").</t> t" derivedLink="https://rfc-editor.org/rfc/rfc8995#section-5.9.2" derivedContent
<t>[RFC-Editor: please update reference to section 5.9.2 accordingly ="RFC8995"/>, "EST CSR Attributes").</t>
with latest BRSKI draft at time of publishing, or RFC]</t>
</section> </section>
<section anchor="registrars-policy" numbered="true" toc="default"> <section anchor="registrars-policy" numbered="true" toc="include" remo
<name>Addressing Sub-Scheme Policies</name> veInRFC="false" pn="section-6.11.7.3">
<t>The ACP registrar selects for the candidate ACP node a unique <name slugifiedName="name-addressing-sub-scheme-polic">Addressing Su
b-Scheme Policies</name>
<t indent="0" pn="section-6.11.7.3-1">The ACP registrar selects for
the candidate ACP node a unique
address prefix from an appropriate ACP addressing sub-scheme, address prefix from an appropriate ACP addressing sub-scheme,
either a zone addressing sub-scheme prefix (see <xref target="zone-scheme" forma either a Zone Addressing Sub-Scheme prefix (see <xref target="zone-scheme" forma
t="default"/>), t="default" sectionFormat="of" derivedContent="Section 6.11.3"/>),
or a Vlong addressing sub-scheme prefix (see <xref target="Vlong" format="defaul or a Vlong Addressing Sub-Scheme prefix (see <xref target="Vlong" format="defaul
t"/>). The t" sectionFormat="of" derivedContent="Section 6.11.5"/>). The
assigned ACP address prefix encoded in the acp-node-name field assigned ACP address prefix encoded in the acp-node-name field
of the ACP certificate indicates to the ACP node its ACP of the ACP certificate indicates to the ACP node its ACP
address information. The sub-addressing scheme indicates the address information. The addressing sub-scheme indicates the
prefix length: /127 for zone address sub-scheme, /120 or /112 prefix length: /127 for the Zone Addressing Sub-Scheme, /120 or /112
for Vlong address sub-scheme. The first address of the prefix is the ACP address for the Vlong Addressing Sub-Scheme. The first address of the prefix is the ACP
. address.
All other addresses in the prefix are for other uses by the ACP node All other addresses in the prefix are for other uses by the ACP node
as described in the zone and Vlong addressing sub scheme sections. as described in the Zone Addressing Sub-Scheme and Vlong Addressing Sub-Scheme s ections.
The ACP address prefix itself is then signaled by the ACP node into The ACP address prefix itself is then signaled by the ACP node into
the ACP routing protocol (see <xref target="routing" format="default"/>) to esta blish the ACP routing protocol (see <xref target="routing" format="default" sectionFor mat="of" derivedContent="Section 6.12"/>) to establish
IPv6 reachability across the ACP.</t> IPv6 reachability across the ACP.</t>
<t>The choice of addressing sub-scheme and prefix-length in the Vlon <t indent="0" pn="section-6.11.7.3-2">The choice of addressing sub-s
g address cheme and prefix length in the Vlong Addressing
sub-scheme is subject to ACP registrar policy. It could be an ACP domain Sub-Scheme is subject to ACP registrar policy. It could be an ACP domain-wide
wide policy, or a per ACP node or per ACP node type policy. For example, policy, or a per ACP node or per ACP node type policy. For example,
in BRSKI, the ACP registrar is aware of the IDevID certificate of the candidate ACP node, in BRSKI, the ACP registrar is aware of the IDevID certificate of the candidate ACP node,
which typically contains a "serialNumber" attribute in the which typically contains a "serialNumber" attribute in the
subject field distinguished name encoding that is often indicating the node's subject field distinguished name encoding that often indicates the node's
vendor and device type and can be used to drive a policy selecting an appropriat vendor and device type, and it can be used to drive a policy for selecting an ap
e propriate
addressing sub-scheme for the (class of) node(s).</t> addressing sub-scheme for the (class of) node(s).</t>
<t>ACP registrars SHOULD default to allocate ACP zone sub-address sc heme <t indent="0" pn="section-6.11.7.3-3">ACP registrars <bcp14>SHOULD</ bcp14> default to allocating Zone Addressing Sub-Scheme
addresses with Zone-ID 0.</t> addresses with Zone-ID 0.</t>
<t>ACP registrars that are aware of the IDevID certificate of a cand <t indent="0" pn="section-6.11.7.3-4">ACP registrars that are aware
idate ACP device of the IDevID certificate of a candidate ACP device
SHOULD be able to choose the zone vs. Vlong sub-address scheme for <bcp14>SHOULD</bcp14> be able to choose the Zone vs. Vlong Addressing Sub-Scheme
ACP nodes based on the <xref target="X.520" format="default"/> "serialNumber" at for
tribute in the ACP nodes based on the "serialNumber" attribute <xref target="X.520" format="def
subject field distinguished name encoding of the IDevID certificate, for example ault" sectionFormat="of" derivedContent="X.520"/> in the
by the PID (Product Identifier) part which identifies the product type, subject field distinguished name encoding of the IDevID certificate, for example
or the complete "serialNumber". The PID for example could identify ,
nodes that allow for specialized ASA requiring multiple addresses or non-autonom by the PID (Product Identifier) part, which identifies the product type,
ic VMs for or by the complete "serialNumber". The PID, for example, could identify
services and those nodes could receive Vlong sub-address scheme ACP addresses.</ nodes that allow for specialized ASA requiring multiple addresses or for non-aut
t> onomic virtual machines (VMs) for
<t>In a simple allocation scheme, an ACP registrar remembers persist services, and those nodes could receive Vlong Addressing Sub-Scheme ACP addresse
ently s.</t>
across reboots its currently used Registrar-ID and for each addressing <t indent="0" pn="section-6.11.7.3-5">In a simple allocation scheme,
an ACP registrar remembers persistently
across reboots its currently used Registrar-ID and, for each addressing
scheme (Zone with Zone-ID 0, Vlong with /112, Vlong with /120), the scheme (Zone with Zone-ID 0, Vlong with /112, Vlong with /120), the
next Node-Number available for allocation and increases it during successful next Node-Number available for allocation, and it increases the next Node-Number
enrollment to an ACP node. In this simple allocation scheme, the ACP registrar during successful
would not recycle ACP address prefixes from no longer used ACP nodes.</t> enrollment of an ACP node. In this simple allocation scheme, the ACP registrar
<t>If allocated addresses cannot be remembered by registrars, then would not recycle ACP address prefixes from ACP nodes that are no longer used.</
it is necessary to either use a new value for the Register-ID field t>
in the ACP addresses, or determine allocated ACP addresses from determining the <t indent="0" pn="section-6.11.7.3-6">If allocated addresses cannot
be remembered by registrars, then
it is necessary either to use a new value for the Register-ID field
in the ACP addresses or to determine allocated ACP addresses by determining the
addresses of reachable ACP nodes, which is not necessarily the set of all ACP no des. addresses of reachable ACP nodes, which is not necessarily the set of all ACP no des.
Non-tracked ACP addresses can be reclaimed by revoking Untracked ACP addresses can be reclaimed by revoking
or not renewing their certificates and instead handing out new certificate or not renewing their certificates and instead handing out new certificates
with new addresses (for example with a new Registrar-ID value). Note that with new addresses (for example, with a new Registrar-ID value). Note that
such strategies may require coordination amongst registrars.</t> such strategies may require coordination amongst registrars.</t>
</section> </section>
<section anchor="registrars-renewal" numbered="true" toc="default"> <section anchor="registrars-renewal" numbered="true" toc="include" rem
<name>Address/Prefix Persistence</name> oveInRFC="false" pn="section-6.11.7.4">
<t>When an ACP certificate is renewed or rekeyed via EST or other <name slugifiedName="name-address-prefix-persistence">Address/Prefix
Persistence</name>
<t indent="0" pn="section-6.11.7.4-1">When an ACP certificate is ren
ewed or rekeyed via EST or other
mechanisms, the ACP address/prefix in the acp-node-name field mechanisms, the ACP address/prefix in the acp-node-name field
MUST be maintained unless security issues or violations of the unique <bcp14>MUST</bcp14> be maintained unless security issues or violations of the un ique
address assignment requirements exist or are suspected by the ACP registrar.</t > address assignment requirements exist or are suspected by the ACP registrar.</t >
<t>ACP address information SHOULD be maintained even when the renewi ng/rekeying <t indent="0" pn="section-6.11.7.4-2">ACP address information <bcp14 >SHOULD</bcp14> be maintained even when the renewing and/or rekeying
ACP registrar is not the same as the one that enrolled the prior ACP certificate . ACP registrar is not the same as the one that enrolled the prior ACP certificate .
See <xref target="sub-ca" format="default"/> for an example.</t> See <xref target="sub-ca" format="default" sectionFormat="of" derivedContent="Se
<t>ACP address information SHOULD also be maintained even after an A ction 9.2.4"/> for an example.</t>
CP <t indent="0" pn="section-6.11.7.4-3">ACP address information <bcp14
certificate did expire or failed. See <xref target="domcert-re-enroll" format="d >SHOULD</bcp14> also be maintained even after an ACP
efault"/> certificate expires or fails. See <xref target="domcert-re-enroll" format="defau
and <xref target="domcert-failing" format="default"/>.</t> lt" sectionFormat="of" derivedContent="Section 6.2.5.5"/>
and <xref target="domcert-failing" format="default" sectionFormat="of" derivedCo
ntent="Section 6.2.5.6"/>.</t>
</section> </section>
<section anchor="registrars-further" numbered="true" toc="default"> <section anchor="registrars-further" numbered="true" toc="include" rem
<name>Further Details</name> oveInRFC="false" pn="section-6.11.7.5">
<t><xref target="registrar-considerations" format="default"/> discus <name slugifiedName="name-further-details">Further Details</name>
ses further informative <t indent="0" pn="section-6.11.7.5-1"><xref target="registrar-consid
details of ACP registrars: What interactions registrars need, what erations" format="default" sectionFormat="of" derivedContent="Section 9.2"/> dis
parameters they require, certificate renewal and limitations, use of sub-CAs on cusses further informative
registrars and centralized policy control.</t> details of ACP registrars: needed interactions, required
parameters, certificate renewal and limitations, use of sub-CAs on
registrars, and centralized policy control.</t>
</section> </section>
</section> </section>
</section> </section>
<!-- addressing --> <section anchor="routing" numbered="true" toc="include" removeInRFC="false
<section anchor="routing" numbered="true" toc="default"> " pn="section-6.12">
<name>Routing in the ACP</name> <name slugifiedName="name-routing-in-the-acp">Routing in the ACP</name>
<t>Once ULA address are set up all autonomic entities should run a routi <t indent="0" pn="section-6.12-1">Once ULA addresses are set up, all aut
ng protocol within the autonomic control plane context. This routing protocol d onomic entities should run a routing protocol within the ACP context. This rout
istributes the ULA created in the previous section for reachability. The use of ing protocol distributes the ULA created in the previous section for reachabilit
the autonomic control plane specific context eliminates the probable clash with y. The use of the ACP-specific context eliminates the probable clash with data
Data-Plane routing tables and also secures the ACP from interference from the c plane routing tables and also secures the ACP from interference from configurati
onfiguration mismatch or incorrect routing updates.</t> on mismatch or incorrect routing updates.</t>
<t>The establishment of the routing plane and its parameters are automat <t indent="0" pn="section-6.12-2">The establishment of the routing plane
ic and strictly within the confines of the autonomic control plane. Therefore, and its parameters are automatic and strictly within the confines of the ACP.
no explicit configuration is required.</t> Therefore, no explicit configuration is required.</t>
<t>All routing updates are automatically secured in transit as the chann <t indent="0" pn="section-6.12-3">All routing updates are automatically
els of the ACP are encrypted, and this routing runs only inside the ACP.</t> secured in transit as the channels of the ACP are encrypted, and this routing ru
<t>The routing protocol inside the ACP is RPL (<xref target="RFC6550" fo ns only inside the ACP.</t>
rmat="default"/>). See <xref target="why-rpl" format="default"/> for more detai <t indent="0" pn="section-6.12-4">The routing protocol inside the ACP is
ls on the choice of RPL.</t> RPL <xref target="RFC6550" format="default" sectionFormat="of" derivedContent="
<t>RPL adjacencies are set up across all ACP channels in the same domain RFC6550"/>. See <xref target="why-rpl" format="default" sectionFormat="of" deri
including all its routing subdomains. See <xref target="domain-usage" format=" vedContent="Appendix A.4"/> for more details on the choice of RPL.</t>
default"/> for more details.</t> <t indent="0" pn="section-6.12-5">RPL adjacencies are set up across all
<section anchor="rpl-profile" numbered="true" toc="default"> ACP channels in the same domain including all its routing subdomains. See <xref
<name>ACP RPL Profile</name> target="domain-usage" format="default" sectionFormat="of" derivedContent="Appen
<t>The following is a description of the RPL profile that ACP nodes ne dix A.6"/> for more details.</t>
ed to support by default. The format of this section is derived from <xref targ <section anchor="rpl-profile" numbered="true" toc="include" removeInRFC=
et="I-D.ietf-roll-applicability-template" format="default"/>.</t> "false" pn="section-6.12.1">
<section anchor="rpl-summary" numbered="true" toc="default"> <name slugifiedName="name-acp-rpl-profile">ACP RPL Profile</name>
<name>Overview</name> <t indent="0" pn="section-6.12.1-1">The following is a description of
<t>RPL Packet Information (RPI) defined in <xref target="RFC6550" fo the RPL profile that ACP nodes need to support by default. The format of this s
rmat="default"/>, section 11.2 defines the ection is derived from <xref target="I-D.ietf-roll-applicability-template" forma
data packet artefacts required or beneficial in forwarding of packets routed t="default" sectionFormat="of" derivedContent="ROLL-APPLICABILITY"/>.</t>
by RPL. <section anchor="rpl-summary" numbered="true" toc="include" removeInRF
C="false" pn="section-6.12.1.1">
<name slugifiedName="name-overview">Overview</name>
<t indent="0" pn="section-6.12.1.1-1">RPL Packet Information (RPI),
defined in <xref target="RFC6550" sectionFormat="comma" section="11.2" format="d
efault" derivedLink="https://rfc-editor.org/rfc/rfc6550#section-11.2" derivedCon
tent="RFC6550"/>, defines the
data packet artifacts required or beneficial in the forwarding of packets rou
ted by RPL.
This profile does not use RPI for better compatibility with accelerated hardw are This profile does not use RPI for better compatibility with accelerated hardw are
forwarding planes which most often does not support the Hop-by-Hop headers us forwarding planes, which most often do not support the Hop-by-Hop headers use
ed for RPI, d for RPI,
but also to avoid the overhead of the RPI header on the wire and cost of addi but also to avoid the overhead of the RPI header on the wire and cost of addi
ng/removing them. ng and/or removing them.
</t> </t>
<!-- <section anchor="rpl-single-instance" numbered="true" toc="include"
Note: Insertion/removal of headers by a (potentially silicon based) ACP removeInRFC="false" pn="section-6.12.1.1.1">
node would be be necessary when senders/receivers of ACP packets are legacy <name slugifiedName="name-single-instance">Single Instance</name>
NOC devices connected via ACP connect (see <xref target="NMS"/> to the ACP. <t indent="0" pn="section-6.12.1.1.1-1">
Their connectivity can be handled in RPL as non-RPL-aware leafs (or "Internet" To avoid the need for RPI, the ACP RPL profile uses a simple routing/forwa
) rding table based on destination prefix.
according to the Data-Plane architecture explained in To achieve this, the profile uses only one RPL
<xref target="I-D.ietf-roll-useofrplinfo" />. instanceID. This single instanceID can contain only one Destination-Orien
<section anchor="rpl-single-instance" numbered="true" toc="default"> ted
<name>Single Instance</name>
<t>
To avoid the need for RPI, the ACP RPL profile uses a simple destination p
refix
based routing/forwarding table. To achieve this, the profiles uses only on
e RPL
instanceID. This single instanceID can contain only one Destination Orien
ted
Directed Acyclic Graph (DODAG), and the routing/forwarding table can there fore Directed Acyclic Graph (DODAG), and the routing/forwarding table can there fore
only calculate a single class of service ("best effort towards the primary NOC/root") only calculate a single class of service ("best effort towards the primary NOC/root")
and cannot create optimized routing paths to accomplish latency or energy goals and cannot create optimized routing paths to accomplish latency or energy goals
between any two nodes. between any two nodes.
</t> </t>
<t> <t indent="0" pn="section-6.12.1.1.1-2">
This choice is a compromise. Consider a network that has multiple NOCs in different locations. This choice is a compromise. Consider a network that has multiple NOCs in different locations.
Only one NOC will become the DODAG root. Traffic to and from other NOCs ha s to be Only one NOC will become the DODAG root. Traffic to and from other NOCs ha s to be
sent through the DODAG (shortest path tree) rooted in the primary NOC. sent through the DODAG (shortest path tree) rooted in the primary NOC.
Depending on topology, this can be an annoyance from a latency point of vi Depending on topology, this can be an annoyance from a point of view of la
ew tency
or from minimizing network path resources, but this is deemed to be accept or minimizing network path resources, but this is deemed to be acceptable
able
given how ACP traffic is "only" network management/control traffic. given how ACP traffic is "only" network management/control traffic.
See <xref target="future-rpl" format="default"/> for more details.</t> See <xref target="future-rpl" format="default" sectionFormat="of" derivedC
<t>Using a single instanceID/DODAG does not introduce a single poi ontent="Appendix A.9.4"/> for more details.</t>
nt of <t indent="0" pn="section-6.12.1.1.1-3">Using a single instanceID/
failure, as the DODAG will reconfigure itself when it detects Data-Plane DODAG does not introduce a single point of
forwarding failures including choosing a different root when the primary o failure, as the DODAG will reconfigure itself when it detects data plane
ne fails. forwarding failures, including choosing a different root when the primary
</t> one fails.
<t>The benefit of this profile, especially compared to other IGPs </t>
is <t indent="0" pn="section-6.12.1.1.1-4">The benefit of this profil
that it does not calculate routes for node reachable through the same e, especially compared to other IGPs, is
that it does not calculate routes for nodes reachable through the same
interface as the DODAG root. This RPL profile can therefore scale to interface as the DODAG root. This RPL profile can therefore scale to
much larger number of ACP nodes in the same amount of compute and memory a much larger number of ACP nodes in the same amount of computation and me
than other routing protocols. Especially on nodes that are leafs of the t mory
opology than other routing protocols, especially on nodes that are leafs of the to
pology
or those close to those leafs. or those close to those leafs.
</t> </t>
</section> </section>
<section anchor="rpl-convergence" numbered="true" toc="default"> <section anchor="rpl-convergence" numbered="true" toc="include" remo
<name>Reconvergence</name> veInRFC="false" pn="section-6.12.1.1.2">
<t> <name slugifiedName="name-reconvergence">Reconvergence</name>
In RPL profiles where RPL Packet Information (RPI, see <xref target="rpl-D <t indent="0" pn="section-6.12.1.1.2-1">
ata-Plane" format="default"/>) In RPL profiles where RPI (see <xref target="rpl-Data-Plane" format="defau
is present, it is also used to trigger reconvergence when misrouted, for e lt" sectionFormat="of" derivedContent="Section 6.12.1.13"/>) is present,
xample looping, packets it is also used to trigger reconvergence when misrouted, for example, loop
are recognized because of their RPI data. This helps to minimize RPL signa ing packets, which
ling traffic are recognized because of their RPI data. This helps to minimize RPL signa
ling traffic,
especially in networks without stable topology and slow links. especially in networks without stable topology and slow links.
</t> </t>
<t> <t indent="0" pn="section-6.12.1.1.2-2">
The ACP RPL profile instead relies on quick reconverging the DODAG by The ACP RPL profile instead relies on quickly reconverging the DODAG by
recognizing link state change (down/up) and triggering reconvergence signa ling recognizing link state change (down/up) and triggering reconvergence signa ling
as described in <xref target="rpl-dodag-repair" format="default"/>. Since as described in <xref target="rpl-dodag-repair" format="default" sectionFo
links in the ACP rmat="of" derivedContent="Section 6.12.1.7"/>. Since links in the ACP
are assumed to be mostly reliable (or have link layer protection against l are assumed to be mostly reliable (or have link-layer protection against l
oss) oss)
and because there is no stretch according to <xref target="rpl-dodag-repai and because there is no stretch according to <xref target="rpl-dodag-repai
r" format="default"/>, r" format="default" sectionFormat="of" derivedContent="Section 6.12.1.7"/>,
loops caused by loss of RPL routing protocol signaling packets should be e loops caused by loss of RPL signaling packets should be exceedingly rare.
xceedingly rare. </t>
</t> <t indent="0" pn="section-6.12.1.1.2-3">
<t>
In addition, there are a variety of mechanisms possible in RPL to further In addition, there are a variety of mechanisms possible in RPL to further
avoid temporary loops RECOMMENDED to be used for the ACPL RPL profile: avoid temporary loops that are <bcp14>RECOMMENDED</bcp14> to be used for t
DODAG Information Objects (DIOs) SHOULD be sent 2 or 3 times to inform chi he ACP RPL profile:
ldren DODAG Information Objects (DIOs) <bcp14>SHOULD</bcp14> be sent two or thre
when losing the last parent. The technique in <xref target="RFC6550" forma e times to inform children
t="default"/> when losing the last parent. The technique in <xref target="RFC6550" secti
section 8.2.2.6. (Detaching) SHOULD be favored over that in section 8.2.2. onFormat="comma" section="8.2.2.6" format="default" derivedLink="https://rfc-edi
5., tor.org/rfc/rfc6550#section-8.2.2.6" derivedContent="RFC6550"/> (Detaching) <bcp
(Poisoning) because it allows local connectivity. Nodes SHOULD select 14>SHOULD</bcp14> be favored over that in Section <xref target="RFC6550" section
more than one parent, at least 3 if possible, and send Destination Adverti Format="bare" section="8.2.2.5" format="default" derivedLink="https://rfc-editor
sement Objects (DAO)s to all .org/rfc/rfc6550#section-8.2.2.5" derivedContent="RFC6550"/>
(Poisoning) because it allows local connectivity. Nodes <bcp14>SHOULD</bcp
14> select
more than one parent, at least three if possible, and send Destination Adv
ertisement Objects (DAOs) to all
of them in parallel.</t> of them in parallel.</t>
<t> <t indent="0" pn="section-6.12.1.1.2-4">
Additionally, failed ACP tunnels can be quickly discovered trough the Additionally, failed ACP tunnels can be quickly discovered through the
secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. secure channel protocol mechanisms such as IKEv2 dead peer detection.
This can function as a replacement for a Low-power and Lossy Networks' This can function as a replacement for a Low-power and Lossy Network's
(LLN's) Expected Transmission Count (ETX) feature that is not used (LLN's) Expected Transmission Count (ETX) feature, which is not used
in this profile. A failure of an ACP tunnel should immediately signal the RPL in this profile. A failure of an ACP tunnel should immediately signal the RPL
control plane to pick a different parent. control plane to pick a different parent.
</t> </t>
</section> </section>
</section> </section>
<section anchor="rpl-instances" numbered="true" toc="default"> <section anchor="rpl-instances" numbered="true" toc="include" removeIn
<name>RPL Instances</name> RFC="false" pn="section-6.12.1.2">
<t>Single RPL instance. Default RPLInstanceID = 0.</t> <name slugifiedName="name-rpl-instances">RPL Instances</name>
<t indent="0" pn="section-6.12.1.2-1">There is a single RPL instance
. The default RPLInstanceID is 0.</t>
</section> </section>
<section anchor="rpl-storing" numbered="true" toc="default"> <section anchor="rpl-storing" numbered="true" toc="include" removeInRF
<name>Storing vs. Non-Storing Mode</name> C="false" pn="section-6.12.1.3">
<t>RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode <name slugifiedName="name-storing-vs-non-storing-mode">Storing vs. N
of Operations on-Storing Mode</name>
with no multicast support". Implementations MAY support mode 3 ("... wi <t indent="0" pn="section-6.12.1.3-1">The RPL Mode of Operation (MOP
th multicast support" as that is a superset of mode 2). Note: Root indicates mo ) <bcp14>MUST</bcp14> support mode 2, "Storing Mode of Operations
de in DIO flow.</t> with no multicast support". Implementations <bcp14>MAY</bcp14> support
mode 3 ("... with multicast support") as that is a superset of mode 2. Note: Ro
ot indicates mode in DIO flow.</t>
</section> </section>
<section anchor="rpl-dao-policy" numbered="true" toc="default"> <section anchor="rpl-dao-policy" numbered="true" toc="include" removeI
<name>DAO Policy</name> nRFC="false" pn="section-6.12.1.4">
<t>Proactive, aggressive DAO state maintenance:</t> <name slugifiedName="name-dao-policy">DAO Policy</name>
<ul spacing="compact"> <t indent="0" pn="section-6.12.1.4-1">The DAO policy is proactive, a
<li>Use K-flag in unsolicited DAO indicating change from previous ggressive DAO state maintenance:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
on-6.12.1.4-2">
<li pn="section-6.12.1.4-2.1">Use the 'K' flag in unsolicited DAO
to indicate change from previous
information (to require DAO-ACK).</li> information (to require DAO-ACK).</li>
<li>Retry such DAO DAO-RETRIES(3) times with DAO- <li pn="section-6.12.1.4-2.2">Retry such DAO DAO-RETRIES(3) times
ACK_TIME_OUT(256ms) in between.</li> with DAO-ACK_TIME_OUT(256ms) in between.</li>
</ul> </ul>
</section> </section>
<section anchor="rpl-path-metric" numbered="true" toc="default"> <section anchor="rpl-path-metric" numbered="true" toc="include" remove
<name>Path Metric</name> InRFC="false" pn="section-6.12.1.5">
<t>Use Hopcount according to <xref target="RFC6551" format="default" <name slugifiedName="name-path-metrics">Path Metrics</name>
/>. Note that this is <t indent="0" pn="section-6.12.1.5-1">Use Hop Count according to "<x
solely for diagnostic purposes as it is not used by the objective functi ref target="RFC6551" format="title" sectionFormat="of" derivedContent="Routing M
on.</t> etrics Used for Path Calculation in Low-Power and Lossy Networks"/>" <xref targe
t="RFC6551" format="default" sectionFormat="of" derivedContent="RFC6551"/>. Note
that this is
solely for diagnostic purposes as it is not used by the Objective Functi
on.</t>
</section> </section>
<section anchor="rpl-objective-function" numbered="true" toc="default" <section anchor="rpl-objective-function" numbered="true" toc="include"
> removeInRFC="false" pn="section-6.12.1.6">
<name>Objective Function</name> <name slugifiedName="name-objective-function">Objective Function</na
<t>Objective Function (OF): Use OF0 <xref target="RFC6552" format="d me>
efault"/>. <dl indent="3" newline="false" spacing="normal" pn="section-6.12.1.6
No use of metric containers.</t> -1">
<t>rank_factor: Derived from link speed: <dt pn="section-6.12.1.6-1.1">Objective Function (OF):</dt>
&lt;= 100Mbps: LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1)</t> <dd pn="section-6.12.1.6-1.2">Use Objective Function Zero (OF0) ("
<t>This is a simple rank differentiation between typical "low speed" <xref target="RFC6552" format="title" sectionFormat="of" derivedContent="Objecti
or "IoT" links that commonly max out at 100 Mbps and typical ve Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)
"/>" <xref target="RFC6552" format="default" sectionFormat="of" derivedContent="
RFC6552"/>).
Metric containers are not used.</dd>
<dt pn="section-6.12.1.6-1.3">rank_factor:</dt>
<dd pn="section-6.12.1.6-1.4">
<t indent="0" pn="section-6.12.1.6-1.4.1">Derived from link spee
d:
if less than or equal to 100 Mbps, LOW_SPEED_FACTOR(5), else HIGH_SP
EED_FACTOR(1).</t>
<t indent="0" pn="section-6.12.1.6-1.4.2">This is a simple rank
differentiation between typical "low speed"
or IoT links that commonly max out at 100 Mbps and typical
infrastructure links with speeds of 1 Gbps or higher. Given how infrastructure links with speeds of 1 Gbps or higher. Given how
the path selection for the ACP focusses only on reachability but the path selection for the ACP focuses only on reachability but
not on path cost optimization, no attempts at finer grained path not on path cost optimization, no attempts at finer-grained path
optimization are made. </t> optimization are made. </t>
</dd>
</dl>
</section> </section>
<section anchor="rpl-dodag-repair" numbered="true" toc="default"> <section anchor="rpl-dodag-repair" numbered="true" toc="include" remov
<name>DODAG Repair</name> eInRFC="false" pn="section-6.12.1.7">
<t>Global Repair: we assume stable links and ranks (metrics), so the <name slugifiedName="name-dodag-repair">DODAG Repair</name>
re is <dl indent="3" newline="false" spacing="normal" pn="section-6.12.1.7
-1">
<dt pn="section-6.12.1.7-1.1">Global Repair:</dt>
<dd pn="section-6.12.1.7-1.2">We assume stable links and ranks (me
trics), so there is
no need to periodically rebuild the DODAG. The DODAG version is o nly no need to periodically rebuild the DODAG. The DODAG version is o nly
incremented under catastrophic events (e.g., administrative action incremented under catastrophic events (e.g., administrative action
).</t> ).</dd>
<t>Local Repair: As soon as link breakage is detected, the ACP node <dt pn="section-6.12.1.7-1.3">Local Repair:</dt>
send <dd pn="section-6.12.1.7-1.4">
No-Path DAO for all the targets that were reachable only via this link. <t indent="0" pn="section-6.12.1.7-1.4.1">As soon as link breaka
ge is detected, the ACP node sends
a No-Path DAO for all the targets that were reachable only via this link
.
As soon as link repair is detected, the ACP node validates if this link provides As soon as link repair is detected, the ACP node validates if this link provides
a better parent. If so, a new rank is computed by the ACP node and it s a better parent. If so, a new rank is computed by the ACP node, and it
ends new DIO sends a new DIO
that advertise the new rank. Then it sends a DAO with a new path sequen that advertises the new rank. Then it sends a DAO with a new path seque
ce about itself.</t> nce about itself.</t>
<t>When using ACP multi-access virtual interfaces, local repair can <t indent="0" pn="section-6.12.1.7-1.4.2">When using ACP multi-a
be ccess virtual interfaces, local repair can be
triggered directly by peer breakage, see <xref target="ACP-ma-vir triggered directly by peer breakage, see <xref target="ACP-ma-vir
tual-interfaces" format="default"/>.</t> tual-interfaces" format="default" sectionFormat="of" derivedContent="Section 6.1
<t>stretch_rank: none provided ("not stretched").</t> 3.5.2.2"/>.</t>
<t>Data Path Validation: Not used.</t> </dd>
<t>Trickle: Not used.</t> <dt pn="section-6.12.1.7-1.5">stretch_rank:</dt>
<dd pn="section-6.12.1.7-1.6">None provided ("not stretched").</dd
>
<dt pn="section-6.12.1.7-1.7">Data-Path Validation:</dt>
<dd pn="section-6.12.1.7-1.8"> Not used.</dd>
<dt pn="section-6.12.1.7-1.9">Trickle:</dt>
<dd pn="section-6.12.1.7-1.10">Not used.</dd>
</dl>
</section> </section>
<section anchor="rpl-multicast" numbered="true" toc="default"> <section anchor="rpl-multicast" numbered="true" toc="include" removeIn
<name>Multicast</name> RFC="false" pn="section-6.12.1.8">
<t>Not used yet but possible because of the selected mode of operati <name slugifiedName="name-multicast">Multicast</name>
ons.</t> <t indent="0" pn="section-6.12.1.8-1">Multicast is not used yet, but
it is possible because of the selected mode of operations.</t>
</section> </section>
<section anchor="rpl-security" numbered="true" toc="default"> <section anchor="rpl-security" numbered="true" toc="include" removeInR
<name>Security</name> FC="false" pn="section-6.12.1.9">
<t><xref target="RFC6550" format="default"/> security not used, subs <name slugifiedName="name-security">Security</name>
tituted by ACP security.</t> <t indent="0" pn="section-6.12.1.9-1">RPL security <xref target="RFC
<t>Because the ACP links already include provisions for confidential 6550" format="default" sectionFormat="of" derivedContent="RFC6550"/> is not used
ity and , and ACP security is substituted.</t>
<t indent="0" pn="section-6.12.1.9-2">Because the ACP links already
include provisions for confidentiality and
integrity protection, their usage at the RPL layer would be redundant, and integrity protection, their usage at the RPL layer would be redundant, and
so RPL security is not used.</t> so RPL security is not used.</t>
</section> </section>
<section anchor="rpl-p2p" numbered="true" toc="default"> <section anchor="rpl-p2p" numbered="true" toc="include" removeInRFC="f
<name>P2P communications</name> alse" pn="section-6.12.1.10">
<t>Not used.</t> <name slugifiedName="name-p2p-communications">P2P Communications</na
me>
<t indent="0" pn="section-6.12.1.10-1">Not used.</t>
</section> </section>
<section anchor="rpl-ipv6" numbered="true" toc="default"> <section anchor="rpl-ipv6" numbered="true" toc="include" removeInRFC="
<name>IPv6 address configuration</name> false" pn="section-6.12.1.11">
<name slugifiedName="name-ipv6-address-configuration">IPv6 Address C
<t>Every ACP node (RPL node) announces an IPv6 prefix covering the a onfiguration</name>
ddresses assigned to the ACP node via the AcpNodeName. The prefix length depend <t indent="0" pn="section-6.12.1.11-1">Every ACP node (RPL node) ann
s on the addressing sub-scheme of the acp-address, /127 for Zone Addressing Sub- ounces an IPv6 prefix covering the addresses assigned to the ACP node via the Ac
Scheme and /112 or /120 for Vlong addressing sub-scheme. See <xref target="addr pNodeName. The prefix length depends on the addressing sub-scheme of the acp-ad
essing" format="default"/> for more details.</t> dress, /127 for the Zone Addressing Sub-Scheme and /112 or /120 for the Vlong Ad
dressing Sub-Scheme. See <xref target="addressing" format="default" sectionForm
<t>Every ACP node MUST install a black hole (aka null) route if ther at="of" derivedContent="Section 6.11"/> for more details.</t>
e are unused parts of the ACP address space assigned to the ACP node via its Acp <t indent="0" pn="section-6.12.1.11-2">Every ACP node <bcp14>MUST</b
NodeName. This is superseded by longer prefixes assigned to interfaces for the a cp14> install a black hole route (also known as a null route) if there are unuse
ddress space actually used by the node. For example, when the node has an ACP-V d parts of the ACP address space assigned to the ACP node via its AcpNodeName. T
Long-8 address space, it installs a /120 black hole route. If it then for exampl his is superseded by longer prefixes assigned to interfaces for the address spac
e only uses the ACP address (first address from the space), it would assign that e actually used by the node. For example, when the node has an ACP-Vlong-8 addr
address via a /128 address prefix to the ACP loopback interface (see <xref targ ess space, it installs a /120 black hole route. If it then only uses the ACP add
et="ACP-loopback" format="default"/>). None of those longer prefixes are announc ress (first address from the space), for example, it would assign that address v
ed into RPL.</t> ia a /128 address prefix to the ACP loopback interface (see <xref target="ACP-lo
opback" format="default" sectionFormat="of" derivedContent="Section 6.13.5.1"/>)
<t>For ACP-Manual address prefixes configured on an ACP node, for e . None of those longer prefixes are announced into RPL.</t>
xample for ACP connect subnets (see <xref target="NMS" format="default"/>), the <t indent="0" pn="section-6.12.1.11-3">For ACP-Manual address prefix
node announces the /64 subnet prefix.</t> es configured on an ACP node, for example, for ACP connect subnets (see <xref ta
rget="NMS" format="default" sectionFormat="of" derivedContent="Section 8.1.1"/>)
, the node announces the /64 subnet prefix.</t>
</section> </section>
<section anchor="rpl-admin" numbered="true" toc="default"> <section anchor="rpl-admin" numbered="true" toc="include" removeInRFC=
<name>Administrative parameters</name> "false" pn="section-6.12.1.12">
<t>Administrative Preference (<xref target="RFC6550" format="default <name slugifiedName="name-administrative-parameters">Administrative
"/>, 3.2.6 – to become root): Indicated in DODAGPreference field of DIO message. Parameters</name>
</t> <dl indent="3" newline="false" spacing="normal" pn="section-6.12.1.1
<ul spacing="compact"> 2-1">
<li>Explicit configured ”root”: 0b100</li> <dt pn="section-6.12.1.12-1.1">Administrative Preference (<xref ta
<li>ACP registrar (Default): 0b011</li> rget="RFC6550" section="3.2.6" sectionFormat="comma" format="default" derivedLin
<li>ACP-connect (non-registrar): 0b010</li> k="https://rfc-editor.org/rfc/rfc6550#section-3.2.6" derivedContent="RFC6550"/>
<li>Default: 0b001.</li> --to become root):</dt>
</ul> <dd pn="section-6.12.1.12-1.2">
<t indent="0" pn="section-6.12.1.12-1.2.1">The preference is ind
icated in the DODAGPreference field of DIO message.
</t>
<dl indent="3" newline="false" spacing="normal" pn="section-6.12
.1.12-1.2.2">
<dt pn="section-6.12.1.12-1.2.2.1">Explicitly configured "root
":</dt>
<dd pn="section-6.12.1.12-1.2.2.2"> 0b100</dd>
<dt pn="section-6.12.1.12-1.2.2.3">ACP registrar (default):</d
t>
<dd pn="section-6.12.1.12-1.2.2.4"> 0b011</dd>
<dt pn="section-6.12.1.12-1.2.2.5">ACP connect (non-registrar)
:</dt>
<dd pn="section-6.12.1.12-1.2.2.6"> 0b010</dd>
<dt pn="section-6.12.1.12-1.2.2.7">Default:</dt>
<dd pn="section-6.12.1.12-1.2.2.8"> 0b001</dd>
</dl>
</dd>
</dl>
</section> </section>
<section anchor="rpl-Data-Plane" numbered="true" toc="default"> <section anchor="rpl-Data-Plane" numbered="true" toc="include" removeI
<name>RPL Packet Information</name> nRFC="false" pn="section-6.12.1.13">
<t>RPI is not required in the ACP RPL profile for the following reas <name slugifiedName="name-rpl-packet-information">RPL Packet Informa
ons. tion</name>
</t> <t indent="0" pn="section-6.12.1.13-1">RPI is not required in the AC
<t>One RPI option is the RPL Source Routing Header (SRH) <xref targe P RPL profile for the following reasons.
t="RFC6554" format="default"/> which is not </t>
<t indent="0" pn="section-6.12.1.13-2">One RPI option is the RPL Sou
rce Routing Header (SRH) ("<xref target="RFC6554" format="title" sectionFormat="
of" derivedContent="An IPv6 Routing Header for Source Routes with the Routing Pr
otocol for Low-Power and Lossy Networks (RPL)"/>" <xref target="RFC6554" format=
"default" sectionFormat="of" derivedContent="RFC6554"/>), which is not
necessary because the ACP RPL profile uses storing mode where each ho p has the necessary next-hop necessary because the ACP RPL profile uses storing mode where each ho p has the necessary next-hop
forwarding information.</t> forwarding information.</t>
<t>The simpler RPL Option header <xref target="RFC6553" format="defa <t indent="0" pn="section-6.12.1.13-3">The simpler RPL Option header
ult"/> is also "<xref target="RFC6553" format="title" sectionFormat="of" derivedContent="The R
not necessary in this profile, because it uses a single RPL instance outing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL I
and data path nformation in Data-Plane Datagrams"/>" <xref target="RFC6553" format="default" s
ectionFormat="of" derivedContent="RFC6553"/> is also
not necessary in this profile, because it uses a single RPL instance
and data-path
validation is also not used.</t> validation is also not used.</t>
</section> </section>
<section anchor="rpl-unknown" numbered="true" toc="default"> <section anchor="rpl-unknown" numbered="true" toc="include" removeInRF
<name>Unknown Destinations</name> C="false" pn="section-6.12.1.14">
<t>Because RPL minimizes the size of the routing and forwarding tabl <name slugifiedName="name-unknown-destinations">Unknown Destinations
e, prefixes reachable through the same interface as the RPL root are not known o </name>
n every ACP node. Therefore, traffic to unknown destination addresses can only <t indent="0" pn="section-6.12.1.14-1">Because RPL minimizes the siz
be discovered at the RPL root. The RPL root SHOULD have attach safe mechanisms e of the routing and forwarding table, prefixes reachable through the same inter
to operationally discover and log such packets.</t> face as the RPL root are not known on every ACP node. Therefore, traffic to unk
nown destination addresses can only be discovered at the RPL root. The RPL root
<t>As this requirement places additional constraints on the Data-Pla <bcp14>SHOULD</bcp14> have attach-safe mechanisms to operationally discover and
ne log such packets.</t>
<t indent="0" pn="section-6.12.1.14-2">As this requirement places ad
ditional constraints on the data plane
functionality of the RPL root, it does not apply to "normal" nodes functionality of the RPL root, it does not apply to "normal" nodes
that are not configured to have special functionality (i.e., the that are not configured to have special functionality (i.e., the
administrative parameter from <xref target="rpl-admin" format="def ault"/> has value 0b001). administrative parameter from <xref target="rpl-admin" format="def ault" sectionFormat="of" derivedContent="Section 6.12.1.12"/> has value 0b001).
If the ACP network is degraded to the point where there are no nod es that If the ACP network is degraded to the point where there are no nod es that
could be configured as root, registrar, or ACP-connect nodes, it i s could be configured as root, registrar, or ACP connect nodes, it i s
possible that the RPL root (and thus the ACP as a whole) would be possible that the RPL root (and thus the ACP as a whole) would be
unable to detect traffic to unknown destinations. However, in the unable to detect traffic to unknown destinations. However, in the
absence of nodes with administrative preference other than 0b001, absence of nodes with administrative preference other than 0b001,
there is also unlikely to be a way to get diagnostic information o ut there is also unlikely to be a way to get diagnostic information o ut
of the ACP, so detection of traffic to unknown destinations would not of the ACP, so detection of traffic to unknown destinations would not
be actionable anyway. be actionable anyway.
</t> </t>
</section> </section>
</section> </section>
<!-- rpl -->
</section> </section>
<!-- routing --> <section anchor="acp_general" numbered="true" toc="include" removeInRFC="f
<section anchor="acp_general" numbered="true" toc="default"> alse" pn="section-6.13">
<name>General ACP Considerations</name> <name slugifiedName="name-general-acp-considerations">General ACP Consid
<t>Since channels are by default established between adjacent neighbors, erations</name>
the resulting overlay network does hop-by-hop encryption. Each node decrypts i <t indent="0" pn="section-6.13-1">Since channels are established between
ncoming traffic from the ACP, and encrypts outgoing traffic to its neighbors in adjacent neighbors by default, the resulting overlay network does hop-by-hop en
the ACP. Routing is discussed in <xref target="routing" format="default"/>.</t> cryption. Each node decrypts incoming traffic from the ACP and encrypts outgoin
<section anchor="performance" numbered="true" toc="default"> g traffic to its neighbors in the ACP. Routing is discussed in <xref target="ro
<name>Performance</name> uting" format="default" sectionFormat="of" derivedContent="Section 6.12"/>.</t>
<t>There are no performance requirements against ACP implementations d <section anchor="performance" numbered="true" toc="include" removeInRFC=
efined in this document because the performance requirements depend on the inten "false" pn="section-6.13.1">
ded use case. It is expected that full autonomic node with a wide range of ASA <name slugifiedName="name-performance">Performance</name>
can require high forwarding plane performance in the ACP, for example for teleme <t indent="0" pn="section-6.13.1-1">There are no performance requireme
try. Implementations of ACP to solely support traditional/SDN style use cases c nts for ACP implementations defined in this document because the performance req
an benefit from ACP at lower performance, especially if the ACP is used only for uirements depend on the intended use case. It is expected that a fully autonomi
critical operations, e.g., when the Data-Plane is not available. The design of c node with a wide range of ASA can require high forwarding plane performance in
the ACP as specified in this document is intended to support a wide range of per the ACP, for example, for telemetry. Implementations of ACP that solely suppor
formance options: It is intended to allow software-only implementations at poten t traditional or SDN-style use cases can benefit from ACP at lower performance,
tially low performance, but can also support high performance options. See <xref especially if the ACP is used only for critical operations, e.g., when the data
target="RFC8368" format="default"/> for more details.</t> plane is not available. The design of the ACP as specified in this document is i
ntended to support a wide range of performance options: it is intended to allow
software-only implementations at potentially low performance, but the design can
also support high-performance options. See <xref target="RFC8368" format="defau
lt" sectionFormat="of" derivedContent="RFC8368"/> for more details.</t>
</section> </section>
<!-- performance --> <section anchor="general_addressing" numbered="true" toc="include" remov
<section anchor="general_addressing" numbered="true" toc="default"> eInRFC="false" pn="section-6.13.2">
<name>Addressing of Secure Channels</name> <name slugifiedName="name-addressing-of-secure-channe">Addressing of S
<t>In order to be independent of the Data-Plane routing and addressing ecure Channels</name>
, <t indent="0" pn="section-6.13.2-1">In order to be independent of the
the GRASP discovered ACP secure channels use IPv6 link local addresses between data plane routing and addressing,
adjacent neighbors. Note: <xref target="remote-acp-neighbors" format="default"/ the ACP secure channels discovered via GRASP use IPv6 link-local addresses betwe
> specifies en
adjacent neighbors. Note: <xref target="remote-acp-neighbors" format="default"
sectionFormat="of" derivedContent="Section 8.2"/> specifies
extensions in which secure channels are configured tunnels operating over extensions in which secure channels are configured tunnels operating over
the Data-Plane, so those secure channels cannot be independent of the the data plane, so those secure channels cannot be independent of the
Data-Plane.</t> data plane.</t>
<t>To avoid that Data-Plane configuration can impact the operations of <t indent="0" pn="section-6.13.2-2">To avoid impacting the operations
the of the
IPv6 (link-local) interface/address used for ACP channels, appropriate IPv6 (link-local) interface/address used for ACP channels when configuring the d
ata plane, appropriate
implementation considerations are required. If the IPv6 interface/link-local implementation considerations are required. If the IPv6 interface/link-local
address is shared with the Data-Plane, it needs to be impossible to unconfigure/ disable address is shared with the data plane, it needs to be impossible to unconfigure and/or disable
it through configuration. Instead of sharing the IPv6 interface/link-local it through configuration. Instead of sharing the IPv6 interface/link-local
address, a separate (virtual) interface with a separate IPv6 link-local address, a separate (virtual) interface with a separate IPv6 link-local
address can be used. For example, the ACP interface could be run over a separate address can be used. For example, the ACP interface could be run over a separate
MAC address of an underlying L2 (Ethernet) interface. For more details and opti ons, MAC address of an underlying L2 (Ethernet) interface. For more details and opti ons,
see <xref target="dp-dependency" format="default"/>.</t> see <xref target="dp-dependency" format="default" sectionFormat="of" derivedCont
<t>Note that other (non-ideal) implementation choices may introduce ad ent="Appendix A.9.2"/>.</t>
ditional undesired <t indent="0" pn="section-6.13.2-3">Note that other (nonideal) impleme
dependencies against the Data-Plane. For example, shared code and configuration ntation choices may introduce additional, undesired
of the secure channel protocols (IPsec / DTLS).</t> dependencies against the data plane, for example, shared code and configuration
of the secure channel protocols (IPsec and/or DTLS).</t>
</section> </section>
<section anchor="general_MTU" numbered="true" toc="default"> <section anchor="general_MTU" numbered="true" toc="include" removeInRFC=
<name>MTU</name> "false" pn="section-6.13.3">
<t>The MTU for ACP secure channels MUST be derived locally from the un <name slugifiedName="name-mtu">MTU</name>
derlying link MTU minus the secure channel encapsulation overhead.</t> <t indent="0" pn="section-6.13.3-1">The MTU for ACP secure channels <b
<t>ACP secure Channel protocols do not need to perform MTU discovery b cp14>MUST</bcp14> be derived locally from the underlying link MTU minus the secu
ecause they are built across L2 adjacencies - the MTU on both sides connecting t re channel encapsulation overhead.</t>
o the L2 connection are assumed to be consistent. Extensions to ACP where the A <t indent="0" pn="section-6.13.3-2">ACP secure channel protocols do no
CP is for example tunneled need to consider how to guarantee MTU consistency. T t need to perform MTU discovery because they are built across L2 adjacencies: th
his is an issue of tunnels, not an issue of running the ACP across a tunnel. Tr e MTUs on both sides connecting to the L2 connection are assumed to be consisten
ansport stacks running across ACP can perform normal PMTUD (Path MTU Discovery). t. Extensions to ACP where the ACP is, for example, tunneled need to consider h
Because the ACP is meant to prioritize reliability over performance, they MAY ow to guarantee MTU consistency. This is an issue of tunnels, not an issue of r
opt to only expect IPv6 minimum MTU (1280) to avoid running into PMTUD implement unning the ACP across a tunnel. Transport stacks running across ACP can perform
ation bugs or underlying link MTU mismatch problems.</t> normal PMTUD (Path MTU Discovery). Because the ACP is meant to prioritize reli
ability over performance, they <bcp14>MAY</bcp14> opt to only expect IPv6 minimu
m MTU (1280 octets) to avoid running into PMTUD implementation bugs or underlyin
g link MTU mismatch problems.</t>
</section> </section>
<section anchor="general_multipath" numbered="true" toc="default"> <section anchor="general_multipath" numbered="true" toc="include" remove
<name>Multiple links between nodes</name> InRFC="false" pn="section-6.13.4">
<t>If two nodes are connected via several links, the ACP SHOULD be est <name slugifiedName="name-multiple-links-between-node">Multiple Links
ablished across every link, but it is possible to establish the ACP only on a su between Nodes</name>
b-set of links. Having an ACP channel on every link has a number of advantages, <t indent="0" pn="section-6.13.4-1">If two nodes are connected via sev
for example it allows for a faster failover in case of link failure, and it ref eral links, the ACP <bcp14>SHOULD</bcp14> be established across every link, but
lects the physical topology more closely. Using a subset of links (for example, it is possible to establish the ACP only on a subset of links. Having an ACP ch
a single link), reduces resource consumption on the node, because state needs t annel on every link has a number of advantages, for example, it allows for a fas
o be kept per ACP channel. The negotiation scheme explained in <xref target="ch ter failover in case of link failure, and it reflects the physical topology more
annel-selection" format="default"/> allows the Decider (the node with the higher closely. Using a subset of links (for example, a single link), reduces resourc
ACP address) to drop all but the desired ACP channels to the Follower - and the e consumption on the node because state needs to be kept per ACP channel. The n
Follower will not re-try to build these secure channels from its side unless th egotiation scheme explained in <xref target="channel-selection" format="default"
e Decider shows up with a previously unknown GRASP announcement (e.g., on a diff sectionFormat="of" derivedContent="Section 6.6"/> allows the Decider (the node
erent link or with a different address announced in GRASP).</t> with the higher ACP address) to drop all but the desired ACP channels to the Fol
lower, and the Follower will not retry to build these secure channels from its s
ide unless the Decider appears with a previously unknown GRASP announcement (e.g
., on a different link or with a different address announced in GRASP).</t>
</section> </section>
<!-- multiple_interfaces --> <section anchor="ACP_interfaces" numbered="true" toc="include" removeInR
<section anchor="ACP_interfaces" numbered="true" toc="default"> FC="false" pn="section-6.13.5">
<name>ACP interfaces</name> <name slugifiedName="name-acp-interfaces">ACP Interfaces</name>
<t>The ACP VRF has conceptually two type of interfaces: The "ACP Loopb <t indent="0" pn="section-6.13.5-1">Conceptually, the ACP VRF has two
ack types of interfaces: the "ACP loopback
interface(s)" to which the ACP ULA address(es) are assigned and the interface(s)" to which the ACP ULA address(es) are assigned and the
"ACP virtual interfaces" that are mapped to the ACP secure channels.</t > "ACP virtual interfaces" that are mapped to the ACP secure channels.</t >
<section anchor="ACP-loopback" numbered="true" toc="default"> <section anchor="ACP-loopback" numbered="true" toc="include" removeInR
<name>ACP loopback interfaces</name> FC="false" pn="section-6.13.5.1">
<t>For autonomous operations of the ACP, as described in <xref targe <name slugifiedName="name-acp-loopback-interfaces">ACP Loopback Inte
t="self-creation" format="default"/> rfaces</name>
and <xref target="acp-l2-switches" format="default"/>, the ACP node uses <t indent="0" pn="section-6.13.5.1-1">For autonomous operations of t
the first address from he ACP, as described in <xref target="self-creation" format="default" sectionFor
the N bit ACP prefix (N = 128 - number of Vbits of the ACP address) assi mat="of" derivedContent="Section 6"/>
gned to the node. and <xref target="acp-l2-switches" format="default" sectionFormat="of" d
erivedContent="Section 7"/>, the ACP node uses the first address from
the N bit ACP prefix assigned to the node. N = (128 - number of Vbits of
the ACP address).
This address is assigned with an address prefix of N or larger to a loop back interface.</t> This address is assigned with an address prefix of N or larger to a loop back interface.</t>
<t>Other addresses from the prefix can be used by the ACP of the nod <t indent="0" pn="section-6.13.5.1-2">Other addresses from the prefi
e as desired. x can be used by the ACP of the node as desired.
The autonomous operations of the ACP does not require additional global The autonomous operations of the ACP do not require additional global-sc
scope ope
IPv6 addresses, they are instead intended for ASA or non-autonomous fun ctions. IPv6 addresses, they are instead intended for ASA or non-autonomous fun ctions.
Non fully autonomic components of the ACP such as ACP connect interfaces Components of the ACP that are not fully autonomic, such as ACP connect
(see <xref target="acp-connect" format="default"/>) may also introduce a interfaces
dditional (see <xref target="acp-connect" format="default" sectionFormat="of" deri
global scope IPv6 addresses on other types of interfaces into the ACP.</ vedContent="Figure 14"/>), may also introduce additional
t> global-scope IPv6 addresses on other types of interfaces to the ACP.</t>
<t>[RFC-Editor: please remove this paragraph: Note to reviewers: <t indent="0" pn="section-6.13.5.1-3">The use of loopback interfaces
Please do not complain again about an obsolete RFC number in the followi for global-scope addresses is
ng paragraph. The text should common operational configuration practice on routers, for example, in In
make it clear that the reference was chosen to indicate a particular poi ternal BGP (IBGP)
nt in time, connections since BGP4 (see "<xref target="RFC1654" format="title" secti
but not to recommend/use a particularly obsolete protocol spec.]</t> onFormat="of" derivedContent="A Border Gateway Protocol 4 (BGP-4)"/>" <xref targ
<t>The use of loopback interfaces for global scope addresses is et="RFC1654" format="default" sectionFormat="of" derivedContent="RFC1654"/>) or
common operational configuration practice on routers, for example in IBG earlier.
P
connections since BGP4 (see <xref target="RFC1654" format="default"/>) o
r earlier.
The ACP adopts and automates this operational practice.</t> The ACP adopts and automates this operational practice.</t>
<t>A loopback interface for use with the ACP as described above is a <t indent="0" pn="section-6.13.5.1-4">A loopback interface for use w
n interface ith the ACP as described above is an interface
behaving according to <xref target="RFC6724" format="default"/> Section that behaves according to Section <xref target="RFC6724" section="4" sec
4., paragraph 2: tionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc67
24#section-4" derivedContent="RFC6724"/> of <xref target="RFC6724" format="defau
lt" sectionFormat="of" derivedContent="RFC6724">"Default Address Selection for I
nternet Protocol Version 6 (IPv6)"</xref>, paragraph 2.
Packets sent by the host of the node from the loopback interface Packets sent by the host of the node from the loopback interface
behave as if they are looped back by the interface so that behave as if they are looped back by the interface so that
they look as if they originated from the loopback interface, are they look as if they originated from the loopback interface, are
then received by the node and forwarded by it towards the destination.</ t> then received by the node and forwarded by it towards the destination.</ t>
<t>The word loopback only indicates this behavior, but not the actua <t indent="0" pn="section-6.13.5.1-5">The term "loopback only" indic
l name of the ates this behavior, but not the actual name of the
interface type choosen in an actual implementation. interface type chosen in an actual implementation.
A loopback interface for use with the ACP can be a virtual/software A loopback interface for use with the ACP can be a virtual and/or softwa
re
construct without any associated hardware, or it can be a hardware inter face construct without any associated hardware, or it can be a hardware inter face
operating in loopback mode.</t> operating in loopback mode.</t>
<t>A loopback interface used for the ACP MUST NOT have connectivity to other <t indent="0" pn="section-6.13.5.1-6">A loopback interface used for the ACP <bcp14>MUST NOT</bcp14> have connectivity to other
nodes.</t> nodes.</t>
<t>The following reviews the reasons for the choice of loopback addr <t indent="0" pn="section-6.13.5.1-7">The following list reviews the
esses reasons for the choice of loopback addresses
for ACP addresses is based on the IPv6 address architecture and common c for ACP addresses, which is based on the IPv6 address architecture and c
hallenges: ommon challenges:
</t> </t>
<ol type="1" spacing="compact"> <ol type="1" spacing="normal" indent="adaptive" start="1" pn="sectio
<li>IPv6 addresses are assigned to interfaces, not nodes. IPv6 con n-6.13.5.1-8">
tinues <li pn="section-6.13.5.1-8.1" derivedCounter="1.">IPv6 addresses a
re assigned to interfaces, not nodes. IPv6 continues
the IPv4 model that a subnet prefix is associated with one link, the IPv4 model that a subnet prefix is associated with one link,
see <xref target="RFC4291" format="default"/>, Section 2.1.</li> see Section <xref target="RFC4291" section="2.1" sectionFormat="bare"
<li>IPv6 implementations commonly do not allow assignment of the s format="default" derivedLink="https://rfc-editor.org/rfc/rfc4291#section-2.1" de
ame rivedContent="RFC4291"/> of <xref target="RFC4291" format="default" sectionForma
IPv6 global scope address in the same VRF to more t="of" derivedContent="RFC4291">"IP Version 6 Addressing Architecture"</xref>.</
li>
<li pn="section-6.13.5.1-8.2" derivedCounter="2.">IPv6 implementat
ions commonly do not allow assignment of the same
IPv6 global-scope address in the same VRF to more
than one interface.</li> than one interface.</li>
<li>Global scope addresses assigned to interfaces that are connect ing to other <li pn="section-6.13.5.1-8.3" derivedCounter="3.">Global-scope add resses assigned to interfaces that connect to other
nodes (external interfaces) may not be stable addresses for communicat ions nodes (external interfaces) may not be stable addresses for communicat ions
because any such interface could fail due to reasons external to the n ode. because any such interface could fail due to reasons external to the n ode.
This could render the addresses assigned to that interface unusable.</ li> This could render the addresses assigned to that interface unusable.</ li>
<li>If failure of the subnet does not result in bringing down the interface and making <li pn="section-6.13.5.1-8.4" derivedCounter="4.">If failure of th e subnet does not bring down the interface and make
the addresses unusable, it could result in unreachability of the the addresses unusable, it could result in unreachability of the
address because the shortest path to the node might go through one of the address because the shortest path to the node might go through one of the
other nodes on the same subnet which could equally consider the subnet to other nodes on the same subnet, which could equally consider the subne t to
be operational even though it is not.</li> be operational even though it is not.</li>
<li>Many OAM service implementations on routers cannot deal with m <li pn="section-6.13.5.1-8.5" derivedCounter="5.">Many OAM service
ore than one peer address, implementations on routers cannot deal with more than one peer address,
often because they do already expect that a single loopback address ca often because they already expect that a single loopback address can b
n be used, e used,
especially to provide a stable address under failure of external inter faces or links.</li> especially to provide a stable address under failure of external inter faces or links.</li>
<li>Even when an application supports multiple addresses to a peer <li pn="section-6.13.5.1-8.6" derivedCounter="6.">Even when an app
, it lication supports multiple addresses to a peer, it
can only use one address for a connection at a time with the most wide can only use one address at a time for a connection with the most wide
ly deployed ly deployed
transport protocols TCP and UDP. While <xref target="RFC6824" format=" transport protocols, TCP and UDP. While "<xref target="RFC6824" format
default"/> solves this problem, ="title" sectionFormat="of" derivedContent="TCP Extensions for Multipath Operati
it is not widely adopted for router OAM services implementations.</li> on with Multiple Addresses"/>" <xref target="RFC6824" format="default" sectionFo
<li>To completely autonomously assign global scope addresses to su rmat="of" derivedContent="RFC6824"/>/<xref target="RFC8684" format="default" sec
bnets tionFormat="of" derivedContent="RFC8684"/> solves this problem,
it is not widely adopted by implementations of router OAM services.</l
i>
<li pn="section-6.13.5.1-8.7" derivedCounter="7.">To completely au
tonomously assign global-scope addresses to subnets
connecting to other nodes, it would be necessary for every node to hav e connecting to other nodes, it would be necessary for every node to hav e
an amount of prefix address space in the order of the maximum number o an amount of prefix address space on the order of the maximum number o
f f
subnets that the node could connect to and then the node would have to subnets that the node could connect to, and then the node would have t
negotiate o negotiate
with adjacent nodes across those subnets whose address space to use fo with adjacent nodes across those subnets which address space to use fo
r each subnet.</li> r each subnet.</li>
<li>Using global scope addresses for subnets between nodes is <li pn="section-6.13.5.1-8.8" derivedCounter="8.">Using global-sco
pe addresses for subnets between nodes is
unnecessary if those subnets only connect routers, such as ACP secure channels, unnecessary if those subnets only connect routers, such as ACP secure channels,
because they can communicate to remote nodes via their global scope lo because they can communicate to remote nodes via their global-scope lo
opback addresses. opback addresses.
Using global scope addresses for those extern subnets is therefore was Using global-scope addresses for those external subnets is therefore w
teful asteful
for the address space and also unnecessarily increasing the size of ro for the address space and also unnecessarily increases the size of the
uting routing
and forwarding tables, which especially for the ACP is highly undesira and forwarding tables, which, especially for the ACP, is highly undesi
ble because rable because
it should attempt to minimize the per-node overhead of the ACP VRF.</l i> it should attempt to minimize the per-node overhead of the ACP VRF.</l i>
<li>For all these reasons, the ACP addressing schemes do not consi der <li pn="section-6.13.5.1-8.9" derivedCounter="9.">For all these re asons, the ACP addressing sub-schemes do not consider
ACP addresses for subnets connecting ACP nodes.</li> ACP addresses for subnets connecting ACP nodes.</li>
</ol> </ol>
<t>Note that <xref target="RFC8402" format="default"/> introduces th <t indent="0" pn="section-6.13.5.1-9">Note that "<xref target="RFC84
e term Node-SID to refer 02" format="title" sectionFormat="of" derivedContent="Segment Routing Architectu
to IGP prefix segments that identify a specific router, for example on a re"/>" <xref target="RFC8402" format="default" sectionFormat="of" derivedContent
loopback interface. ="RFC8402"/> introduces the term Node-SID to refer
to IGP prefix segments that identify a specific router, for example, on
a loopback interface.
An ACP loopback address prefix may similarly be called an ACP Node Ident ifier.</t> An ACP loopback address prefix may similarly be called an ACP Node Ident ifier.</t>
</section> </section>
<section anchor="ACP-virtual-interfaces" numbered="true" toc="default" <section anchor="ACP-virtual-interfaces" numbered="true" toc="include"
> removeInRFC="false" pn="section-6.13.5.2">
<name>ACP virtual interfaces</name> <name slugifiedName="name-acp-virtual-interfaces">ACP Virtual Interf
<t>Any ACP secure channel to another ACP node is aces</name>
<t indent="0" pn="section-6.13.5.2-1">Any ACP secure channel to anot
her ACP node is
mapped to ACP virtual interfaces in one of the following ways. mapped to ACP virtual interfaces in one of the following ways.
This is independent of the chosen secure channel protocol (IPsec, DTLS This is independent of the chosen secure channel protocol (IPsec, DTLS,
or other future protocol - standards or non-standards).</t> or other future protocol, either standardized or not).</t>
<t>Note that all the considerations described here are assuming poin <t indent="0" pn="section-6.13.5.2-2">Note that all the consideratio
t-to-point ns described here assume point-to-point
secure channel associations. Mapping multi-party secure channel associat secure channel associations. Mapping multiparty secure channel associati
ions such as ons, such as
<xref target="RFC6407" format="default"/> is out of scope.</t> "<xref target="RFC6407" format="title" sectionFormat="of" derivedContent
<section anchor="ACP-p2p-virtual-interfaces" numbered="true" toc="de ="The Group Domain of Interpretation"/>" <xref target="RFC6407" format="default"
fault"> sectionFormat="of" derivedContent="RFC6407"/>, is out of scope.</t>
<name>ACP point-to-point virtual interfaces</name> <section anchor="ACP-p2p-virtual-interfaces" numbered="true" toc="in
<t>In this option, each ACP secure channel is clude" removeInRFC="false" pn="section-6.13.5.2.1">
mapped into a separate point-to-point ACP virtual interface. If a <name slugifiedName="name-acp-point-to-point-virtual-">ACP Point-t
physical subnet has more than two ACP capable nodes (in the same domain) o-Point Virtual Interfaces</name>
, <t indent="0" pn="section-6.13.5.2.1-1">In this option, each ACP s
ecure channel is
mapped to a separate point-to-point ACP virtual interface. If a
physical subnet has more than two ACP-capable nodes (in the same domain)
,
this implementation approach will lead to a full mesh of ACP virtual this implementation approach will lead to a full mesh of ACP virtual
interfaces between them.</t> interfaces between them.</t>
<t>When the secure channel protocol determines a peer to be dead, this SHOULD <t indent="0" pn="section-6.13.5.2.1-2">When the secure channel pr otocol determines a peer to be dead, this <bcp14>SHOULD</bcp14>
result in indicating link breakage to trigger RPL DODAG repair, see result in indicating link breakage to trigger RPL DODAG repair, see
<xref target="rpl-dodag-repair" format="default"/>.</t> <xref target="rpl-dodag-repair" format="default" sectionFormat="of" deri vedContent="Section 6.12.1.7"/>.</t>
</section> </section>
<section anchor="ACP-ma-virtual-interfaces" numbered="true" toc="def <section anchor="ACP-ma-virtual-interfaces" numbered="true" toc="inc
ault"> lude" removeInRFC="false" pn="section-6.13.5.2.2">
<name>ACP multi-access virtual interfaces</name> <name slugifiedName="name-acp-multi-access-virtual-in">ACP Multi-A
<t>In a more advanced implementation approach, ccess Virtual Interfaces</name>
<t indent="0" pn="section-6.13.5.2.2-1">In a more advanced impleme
ntation approach,
the ACP will construct a single multi-access ACP virtual interface for the ACP will construct a single multi-access ACP virtual interface for
all ACP secure channels to ACP capable nodes reachable across the same all ACP secure channels to ACP-capable nodes reachable across the same
underlying (physical) subnet. IPv6 link-local multicast packets underlying (physical) subnet. IPv6 link-local multicast packets
sent into an ACP multi-access virtual interface are replicated to sent to an ACP multi-access virtual interface are replicated to
every ACP secure channel mapped into the ACP multicast-access virtual every ACP secure channel mapped to the ACP multi-access virtual
interface. IPv6 unicast packets sent into an ACP multi-access virtual interface. IPv6 unicast packets sent to an ACP multi-access virtual
interface are sent to the ACP secure channel that belongs to the interface are sent to the ACP secure channel that belongs to the
ACP neighbor that is the next-hop in the ACP forwarding table entry ACP neighbor that is the next hop in the ACP forwarding table entry
used to reach the packets destination address.</t> used to reach the packets' destination address.</t>
<t>When the secure channel protocol determines a peer to be dead f <t indent="0" pn="section-6.13.5.2.2-2">When the secure channel pr
or a otocol determines that a peer is dead for a
secure channel mapped into an ACP multi-access virtual interface, secure channel mapped to an ACP multi-access virtual interface,
this SHOULD result in signaling breakage of that peer to RPL, so it can this <bcp14>SHOULD</bcp14> result in signaling breakage of that peer to
trigger RPL, so it can trigger
RPL DODAG repair, see <xref target="rpl-dodag-repair" format="default"/> RPL DODAG repair, see <xref target="rpl-dodag-repair" format="default" s
.</t> ectionFormat="of" derivedContent="Section 6.12.1.7"/>.</t>
<t>There is no requirement for <t indent="0" pn="section-6.13.5.2.2-3">There is no requirement fo
r
all ACP nodes on the same multi-access subnet to use the same all ACP nodes on the same multi-access subnet to use the same
type of ACP virtual interface. This is purely a node local type of ACP virtual interface. This is purely a node-local
decision.</t> decision.</t>
<t>ACP nodes MUST perform standard IPv6 operations across ACP <t indent="0" pn="section-6.13.5.2.2-4">ACP nodes <bcp14>MUST</bcp
virtual interfaces including SLAAC (Stateless Address Auto-Configuration 14> perform standard IPv6 operations across ACP
) virtual interfaces including SLAAC
- <xref target="RFC4862" format="default"/>) to assign their IPv6 link l <xref target="RFC4862" format="default" sectionFormat="of" derivedConten
ocal address on the ACP t="RFC4862"/> to assign their IPv6 link-local address on the ACP
virtual interface and ND (Neighbor Discovery - <xref target="RFC4861" fo virtual interface and ND ("<xref target="RFC4861" format="title" section
rmat="default"/>) Format="of" derivedContent="Neighbor Discovery for IP version 6 (IPv6)"/>" <xref
target="RFC4861" format="default" sectionFormat="of" derivedContent="RFC4861"/>
)
to discover which IPv6 link-local neighbor address belongs to to discover which IPv6 link-local neighbor address belongs to
which ACP secure channel mapped to the ACP virtual interface. which ACP secure channel mapped to the ACP virtual interface.
This is independent of whether the ACP virtual interface is point-to-poi nt or multi-access.</t> This is independent of whether the ACP virtual interface is point-to-poi nt or multi-access.</t>
<t>"Optimistic Duplicate Address Detection (DAD)" according to <t indent="0" pn="section-6.13.5.2.2-5">Optimistic Duplicate Addre
<xref target="RFC4429" format="default"/> is RECOMMENDED because the lik ss Detection (DAD) according to
elihood for "<xref target="RFC4429" format="title" sectionFormat="of" derivedContent
="Optimistic Duplicate Address Detection (DAD) for IPv6"/>" <xref target="RFC442
9" format="default" sectionFormat="of" derivedContent="RFC4429"/> is <bcp14>RECO
MMENDED</bcp14> because the likelihood for
duplicates between ACP nodes is highly improbable as long as duplicates between ACP nodes is highly improbable as long as
the address can be formed from a globally unique local assigned identifi er the address can be formed from a globally unique, locally assigned ident ifier
(e.g., EUI-48/EUI-64, see below).</t> (e.g., EUI-48/EUI-64, see below).</t>
<t>ACP nodes MAY reduce the amount of link-local IPv6 multicast <t indent="0" pn="section-6.13.5.2.2-6">ACP nodes <bcp14>MAY</bcp1 4> reduce the amount of link-local IPv6 multicast
packets from ND by learning the IPv6 link-local neighbor address packets from ND by learning the IPv6 link-local neighbor address
to ACP secure channel mapping from other messages such as the source to ACP secure channel mapping from other messages, such as the source
address of IPv6 link-local multicast RPL messages - and therefore address of IPv6 link-local multicast RPL messages, and therefore
forego the need to send Neighbor Solicitation messages.</t> forego the need to send Neighbor Solicitation messages.</t>
<t>The ACP virtual interface IPv6 link local address can be derive <t indent="0" pn="section-6.13.5.2.2-7">The ACP virtual interface
d from IPv6 link-local address can be derived from
any appropriate local mechanism such as node local EUI-48 or EUI-64 any appropriate local mechanism, such as node-local EUI-48 or EUI-64.
("EUI" stands for "Extended Unique Identifier"). It <bcp14>MUST NOT</bcp14> depend on something that is attackable from t
It MUST NOT depend on something that is attackable from the Data-Plane s he data plane, such
uch
as the IPv6 link-local address of the underlying physical interface, whi ch as the IPv6 link-local address of the underlying physical interface, whi ch
can be attacked by SLAAC, or parameters of the secure channel encapsulat ion header can be attacked by SLAAC, or parameters of the secure channel encapsulat ion header
that may not be protected by the secure channel mechanism.</t> that may not be protected by the secure channel mechanism.</t>
<t>The link-layer address of an ACP virtual interface is the <t indent="0" pn="section-6.13.5.2.2-8">The link-layer address of an ACP virtual interface is the
address used for the underlying interface across which the secure address used for the underlying interface across which the secure
tunnels are built, typically Ethernet addresses. Because unicast IPv6 tunnels are built, typically Ethernet addresses. Because unicast IPv6
packets sent to an ACP virtual interface are not sent to a link-layer packets sent to an ACP virtual interface are not sent to a link-layer
destination address but rather an ACP secure channel, destination address but rather to an ACP secure channel,
the link-layer address fields SHOULD be ignored on reception and the link-layer address fields <bcp14>SHOULD</bcp14> be ignored on recept
ion, and
instead the ACP secure channel from which the message was instead the ACP secure channel from which the message was
received should be remembered.</t> received should be remembered.</t>
<t>Multi-access ACP virtual interfaces are preferable implementati <t indent="0" pn="section-6.13.5.2.2-9">Multi-access ACP virtual i
ons nterfaces are preferable implementations
when the underlying interface is a (broadcast) multi-access subnet becau when the underlying interface is a (broadcast) multi-access subnet becau
se they do se they
reflect the presence of the underlying multi-access subnet into the virt reflect the presence of the underlying multi-access subnet to the virtua
ual l
interfaces of the ACP. This makes it for example simpler to build servi interfaces of the ACP. This makes it, for example, simpler to build ser
ces vices
with topology awareness inside the ACP VRF in the same way as they could with topology awareness inside the ACP VRF in the same way as they could
have been built running natively on the multi-access interfaces.</t> have been built running natively on the multi-access interfaces.</t>
<t>Consider also the impact of point-to-point vs. multi-access vir <t indent="0" pn="section-6.13.5.2.2-10">Consider also the impact
tual interface of point-to-point vs. multi-access virtual interfaces
on the efficiency of flooding via link local multicasted messages:</t> on the efficiency of flooding via link-local multicast messages.</t>
<t>Assume a LAN with three ACP neighbors, Alice, Bob and Carol. <t indent="0" pn="section-6.13.5.2.2-11">Assume a LAN with three A
CP neighbors, Alice, Bob, and Carol.
Alice's ACP GRASP wants to send a link-local GRASP multicast message to Alice's ACP GRASP wants to send a link-local GRASP multicast message to
Bob and Carol. If Alice's ACP emulates the LAN as per-peer, point-to-po int Bob and Carol. If Alice's ACP emulates the LAN as per-peer, point-to-po int
virtual interfaces, one to Bob and one to Carol, Alice's ACP GRASP will virtual interfaces, one to Bob and one to Carol, Alice's ACP GRASP will
send two copies of multicast GRASP messages: One to Bob and one to Carol . send two copies of multicast GRASP messages: one to Bob and one to Carol .
If Alice's ACP emulates a LAN via a multipoint virtual interface, Alice' s ACP GRASP will send one packet If Alice's ACP emulates a LAN via a multipoint virtual interface, Alice' s ACP GRASP will send one packet
to that interface and the ACP multipoint virtual interface will replicat e the packet to each secure channel, to that interface, and the ACP multipoint virtual interface will replica te the packet to each secure channel,
one to Bob, one to Carol. The result is the same. The difference one to Bob, one to Carol. The result is the same. The difference
happens when Bob and Carol receive their packet. If they use ACP point- to-point happens when Bob and Carol receive their packets. If they use ACP point -to-point
virtual interfaces, their GRASP instance would forward the packet virtual interfaces, their GRASP instance would forward the packet
from Alice to each other as part of the GRASP flooding procedure. from Alice to each other as part of the GRASP flooding procedure.
These packets are unnecessary and would be discarded by GRASP These packets are unnecessary and would be discarded by GRASP
on receipt as duplicates (by use of the GRASP Session ID). on receipt as duplicates (by use of the GRASP Session ID).
If Bob and Carol's ACP would emulate a multi-access If Bob and Carol's ACP emulated a multi-access
virtual interface, then this would not happen, because GRASPs flooding p virtual interface, then this would not happen because GRASP's flooding p
rocedure rocedure
does not replicate back packets to the interface that they were received does not replicate packets back to the interface from which they were re
from.</t> ceived.</t>
<t>Note that link-local GRASP multicast messages are not sent <t indent="0" pn="section-6.13.5.2.2-12">Note that link-local GRAS
directly as IPv6 link-local multicast UDP messages into ACP virtual inte P multicast messages are not sent
rfaces, directly as IPv6 link-local multicast UDP messages to ACP virtual interf
but instead into ACP GRASP virtual interfaces, that are layered on top o aces,
f but instead to ACP GRASP virtual interfaces that are layered on top of
ACP virtual interfaces to add TCP reliability to link-local multicast ACP virtual interfaces to add TCP reliability to link-local multicast
GRASP messages. Nevertheless, these ACP GRASP virtual interfaces perfor m the GRASP messages. Nevertheless, these ACP GRASP virtual interfaces perfor m the
same replication of message and, therefore, result in the same impact on same replication of messages and therefore have the same impact on flood
flooding. ing.
See <xref target="GRASP-substrate" format="default"/> for more details.< See <xref target="GRASP-substrate" format="default" sectionFormat="of" d
/t> erivedContent="Section 6.9.2"/> for more details.</t>
<t>RPL does support operations and correct routing table construct <t indent="0" pn="section-6.13.5.2.2-13">RPL does support operatio
ion ns and correct routing table construction
across non-broadcast multi-access (NBMA) subnets. This is common when u sing many across non-broadcast multi-access (NBMA) subnets. This is common when u sing many
radio technologies. When such NBMA subnets are used, they MUST NOT be radio technologies. When such NBMA subnets are used, they <bcp14>MUST N OT</bcp14> be
represented as ACP multi-access virtual interfaces because the replicati on represented as ACP multi-access virtual interfaces because the replicati on
of IPv6 link-local multicast messages will not reach all of IPv6 link-local multicast messages will not reach all
NBMA subnet neighbors. In result, GRASP message flooding would fail. NBMA subnet neighbors. As a result, GRASP message flooding would fail.
Instead, each ACP secure channel across such an interface MUST be Instead, each ACP secure channel across such an interface <bcp14>MUST</b
represented as a ACP point-to-point virtual interface. See also <xref ta cp14> be
rget="future-rpl" format="default"/>.</t> represented as an ACP point-to-point virtual interface. See also <xref t
<t>Care needs to be taken when creating multi-access ACP virtual arget="future-rpl" format="default" sectionFormat="of" derivedContent="Appendix
A.9.4"/>.</t>
<t indent="0" pn="section-6.13.5.2.2-14">Care needs to be taken wh
en creating multi-access ACP virtual
interfaces across ACP secure channels between ACP nodes in different dom ains interfaces across ACP secure channels between ACP nodes in different dom ains
or routing subdomains. If for example future inter-domain ACP policies or routing subdomains. If, for example, future inter-domain ACP policies
are defined as "peer-to-peer" policies, it is easier to create ACP point -to-point are defined as "peer-to-peer" policies, it is easier to create ACP point -to-point
virtual interfaces for these inter-domain secure channels.</t> virtual interfaces for these inter-domain secure channels.</t>
</section> </section>
</section> </section>
</section> </section>
<!-- acp_interfaces -->
</section> </section>
<!-- acp_general -->
</section> </section>
<section anchor="acp-l2-switches" numbered="true" toc="include" removeInRFC=
<!-- self-creation --> "false" pn="section-7">
<section anchor="acp-l2-switches" numbered="true" toc="default"> <name slugifiedName="name-acp-support-on-l2-switches-">ACP Support on L2 S
<name>ACP support on L2 switches/ports (Normative)</name> witches/Ports (Normative)</name>
<section anchor="acp-l2-switches-why" numbered="true" toc="default"> <section anchor="acp-l2-switches-why" numbered="true" toc="include" remove
<name>Why (Benefits of ACP on L2 switches)</name> InRFC="false" pn="section-7.1">
<figure anchor="acp-example"> <name slugifiedName="name-why-benefits-of-acp-on-l2-s">Why (Benefits of
<name>Topology with L2 ACP switches</name> ACP on L2 Switches)</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <figure anchor="acp-example" align="left" suppress-title="false" pn="fig
ure-13">
<name slugifiedName="name-topology-with-l2-acp-switch">Topology with L
2 ACP Switches</name>
<artwork name="" type="" align="left" alt="" pn="section-7.1-1.1">
ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2
.../ \ \ ... .../ \ \ ...
ANrtrM ------ \ ------- ANrtrN ANrtrM ------ \ ------- ANrtrN
ANswitchM ... ANswitchM ...
]]></artwork> </artwork>
</figure> </figure>
<t>Consider a large L2 LAN with ANrtr1...ANrtrN connected via some topol <t indent="0" pn="section-7.1-2">Consider a large L2 LAN with routers AN
ogy of L2 switches. rtr1 through ANrtrN connected via some topology of L2 switches.
Examples include large enterprise campus networks with an L2 core, IoT networks Examples include large enterprise campus networks with an L2 core, IoT networks,
or broadband or broadband
aggregation networks which often have even a multi-level L2 switched topology.</ aggregation networks, which often have a multilevel L2-switched topology.</t>
t> <t indent="0" pn="section-7.1-3">If the discovery protocol used for the
<t>If the discovery protocol used for the ACP is operating at the subnet ACP operates at the subnet level, every ACP router
level, every ACP router will see all other ACP routers on the LAN as neighbors, and a full mesh of ACP c
will see all other ACP routers on the LAN as neighbors and a full mesh of ACP ch hannels will be built.
annels will be built.
If some or all of the AN switches are autonomic with the same discovery protocol , then the If some or all of the AN switches are autonomic with the same discovery protocol , then the
full mesh would include those switches as well.</t> full mesh would include those switches as well.</t>
<t>A full mesh of ACP connections can create fundamental scale challenge s. The number of <t indent="0" pn="section-7.1-4">A full mesh of ACP connections can crea te fundamental scale challenges. The number of
security associations of the secure channel protocols will likely not scale arbi trarily, security associations of the secure channel protocols will likely not scale arbi trarily,
especially when they leverage platform accelerated encryption/decryption. Likew especially when they leverage platform-accelerated encryption/decryption. Likew
ise, any ise, any
other ACP operations (such as routing) needs to scale to the number of direct AC other ACP operations (such as routing) need to scale to the number of direct ACP
P neighbors. An neighbors. An
ACP router with just 4 physical interfaces might be deployed into a LAN with hun ACP router with just four physical interfaces might be deployed into a LAN with
dreds of neighbors connected hundreds of neighbors connected
via switches. Introducing such a new unpredictable scaling factor requirement m via switches. Introducing such a new, unpredictable scaling factor requirement
akes it harder makes it harder
to support the ACP on arbitrary platforms and in arbitrary deployments.</t> to support the ACP on arbitrary platforms and in arbitrary deployments.</t>
<t>Predictable scaling requirements for ACP neighbors can most easily be <t indent="0" pn="section-7.1-5">Predictable scaling requirements for AC
achieved if in P neighbors can most easily be achieved if, in
topologies such as these, ACP capable L2 switches can ensure that discovery mess topologies such as these, ACP-capable L2 switches can ensure that discovery mess
ages terminate ages terminate
on them so that neighboring ACP routers and switches will only find the physical ly connected on them so that neighboring ACP routers and switches will only find the physical ly connected
ACP L2 switches as their candidate ACP neighbors. With such a discovery mechani sm in place, the ACP L2 switches as their candidate ACP neighbors. With such a discovery mechani sm in place, the
ACP and its security associations will only need to scale to the number of physi cal interfaces ACP and its security associations will only need to scale to the number of physi cal interfaces
instead of a potentially much larger number of "LAN-connected" neighbors. And t instead of a potentially much larger number of "LAN-connected" neighbors, and th
he ACP topology e ACP topology
will follow directly the physical topology, something which can then also be lev will follow directly the physical topology, something that can then also be leve
eraged raged
in management operations or by ASAs.</t> in management operations or by ASAs.</t>
<t>In the example above, consider ANswitch1 and ANswitchM are ACP capabl e, and ANswitch2 <t indent="0" pn="section-7.1-6">In the example above, consider that ANs witch1 and ANswitchM are ACP capable, and ANswitch2
is not ACP capable. The desired ACP topology is that ANrtr1 and ANrtrM only hav e an is not ACP capable. The desired ACP topology is that ANrtr1 and ANrtrM only hav e an
ACP connection to ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh ACP connection to ANswitch1, and that ANswitch1, ANrtr2, and ANrtrN have a full
of ACP mesh of ACP
connection amongst each other. ANswitch1 also has an ACP connection with ANswit connections amongst each other. ANswitch1 also has an ACP connection with ANswi
chM and tchM, and
ANswitchM has ACP connections to anything else behind it.</t> ANswitchM has ACP connections to anything else behind it.</t>
</section> </section>
<!-- switched-lans-why --> <section anchor="acp-l2-switches-how" numbered="true" toc="include" remove
<section anchor="acp-l2-switches-how" numbered="true" toc="default"> InRFC="false" pn="section-7.2">
<name>How (per L2 port DULL GRASP)</name> <name slugifiedName="name-how-per-l2-port-dull-grasp">How (per L2 Port D
<t>To support ACP on L2 switches or L2 switched ports of an L3 device, i ULL GRASP)</name>
t is necessary to <t indent="0" pn="section-7.2-1">To support ACP on L2 switches or L2-swi
tched ports of an L3 device, it is necessary to
make those L2 ports look like L3 interfaces for the ACP implementation. This pr imarily involves make those L2 ports look like L3 interfaces for the ACP implementation. This pr imarily involves
the creation of a separate DULL GRASP instance/domain on every such L2 port. Be cause GRASP the creation of a separate DULL GRASP instance/domain on every such L2 port. Be cause GRASP
has a dedicated link-local IPv6 multicast address (ALL_GRASP_NEIGHBORS), it is s ufficient that all packets has a dedicated link-local IPv6 multicast address (ALL_GRASP_NEIGHBORS), it is s ufficient that all packets
for this address are being extracted at the port level and passed to that DULL G for this address are extracted at the port level and passed to that DULL GRASP i
RASP instance. nstance.
Likewise the IPv6 link-local multicast packets sent by that DULL GRASP instance Likewise, the IPv6 link-local multicast packets sent by that DULL GRASP instance
need to be need to be
sent only towards the L2 port for this DULL GRASP instance (instead of being flo oded across sent only towards the L2 port for this DULL GRASP instance (instead of being flo oded across
all ports of the VLAN to which the port belongs).</t> all ports of the VLAN to which the port belongs).</t>
<t>When Ports/Interfaces across which the ACP is expected to operate in <t indent="0" pn="section-7.2-2">When the ports/interfaces across which
an ACP-aware L2-switch or L2/L3-switch/router are L2-bridged, packets for the AL the ACP is expected to operate in an ACP-aware L2 switch or L2/L3 switch/router
L_GRASP_NEIGHBORS multicast address MUST never be forward between these ports. I are L2-bridged, packets for the ALL_GRASP_NEIGHBORS multicast address <bcp14>MUS
f MLD snooping is used, it MUST be prohibited from bridging packets for the ALL_ T</bcp14> never be forwarded between these ports. If MLD snooping is used, it <b
GRASP_NEIGHBORS IPv6 multicast address.</t> cp14>MUST</bcp14> be prohibited from bridging packets for the ALL_GRASP_NEIGHBOR
<t>On hybrid L2/L3 switches, multiple L2 ports are assigned to a single S IPv6 multicast address.</t>
L3 <t indent="0" pn="section-7.2-3">On hybrid L2/L3 switches, multiple L2 p
orts are assigned to a single L3
VLAN interface. With the aforementioned changes for DULL GRASP, ACP can VLAN interface. With the aforementioned changes for DULL GRASP, ACP can
simply operate on the L3 VLAN interfaces, so no further (hardware) forwarding simply operate on the L3 VLAN interfaces, so no further (hardware) forwarding
changes are required to make ACP operate on L2 ports. This is possible because changes are required to make ACP operate on L2 ports. This is possible because
the ACP secure channel protocols only use link-local IPv6 unicast packets, the ACP secure channel protocols only use link-local IPv6 unicast packets,
and these packets will be sent to the correct L2 port towards the and these packets will be sent to the correct L2 port towards the
peer by the VLAN logic of the device.</t> peer by the VLAN logic of the device.</t>
<t>This is sufficient when p2p ACP virtual interfaces are established to <t indent="0" pn="section-7.2-4">This is sufficient when P2P ACP virtual interfaces are established to
every ACP peer. When it is desired to create multi-access ACP virtual interfaces every ACP peer. When it is desired to create multi-access ACP virtual interfaces
(see <xref target="ACP-ma-virtual-interfaces" format="default"/>), it is REQIURE D not to coalesce all (see <xref target="ACP-ma-virtual-interfaces" format="default" sectionFormat="of " derivedContent="Section 6.13.5.2.2"/>), it is <bcp14>REQUIRED</bcp14> not to c oalesce all
the ACP secure channels on the same L3 VLAN interface, but only all those on th e same L2 port.</t> the ACP secure channels on the same L3 VLAN interface, but only all those on th e same L2 port.</t>
<t>If VLAN tagging is used, then all the above described logic only appl ies to <t indent="0" pn="section-7.2-5">If VLAN tagging is used, then the logic described above only applies to
untagged GRASP packets. For the purpose of ACP neighbor discovery via GRASP, untagged GRASP packets. For the purpose of ACP neighbor discovery via GRASP,
no VLAN tagged packets SHOULD be sent or received. In a hybrid L2/L3 no VLAN-tagged packets <bcp14>SHOULD</bcp14> be sent or received. In a hybrid L2 /L3
switch, each VLAN would therefore only create ACP adjacencies across those switch, each VLAN would therefore only create ACP adjacencies across those
ports where the VLAN is carried untagged.</t> ports where the VLAN is carried untagged.</t>
<t>In result, the simple logic is that ACP secure channels would operate <t indent="0" pn="section-7.2-6">As a result, the simple logic is that A
over the same L3 interfaces that present a single flat bridged network CP secure channels would operate
over the same L3 interfaces that present a single, flat bridged network
across all routers, but because DULL GRASP is separated on a per-port basis, across all routers, but because DULL GRASP is separated on a per-port basis,
no full mesh of ACP secure channels is created, but only per-port ACP no full mesh of ACP secure channels is created, but only per-port ACP
secure channels to per-port L2-adjacent ACP node neighbors.</t> secure channels to per-port L2-adjacent ACP node neighbors.</t>
<t>For example, in the above picture, ANswitch1 would run separate DULL <t indent="0" pn="section-7.2-7">For example, in the above picture, ANsw
GRASP instances on its ports itch1 would run separate DULL GRASP instances on its ports
to ANrtr1, ANswitch2 and ANswitchI, even though all those three ports may be in to ANrtr1, ANswitch2, and ANswitchI, even though all three ports may be in the d
the data ata plane
plane in the same (V)LAN and perform L2 switching between these ports, ANswitch1 in the same (V)LAN and perform L2 switching between these ports, ANswitch1 would
would perform perform
ACP L3 routing between them.</t> ACP L3 routing between them.</t>
<t>The description in the previous paragraph was specifically meant to i <t indent="0" pn="section-7.2-8">The description in the previous paragra
llustrate that on hybrid ph is specifically meant to illustrate that, on hybrid
L3/L2 devices that are common in enterprise, IoT and broadband aggregation, ther L3/L2 devices that are common in enterprise, IoT, and broadband aggregation, the
e is only re is only
the GRASP packet extraction (by Ethernet address) and GRASP link-local multicast per the GRASP packet extraction (by Ethernet address) and GRASP link-local multicast per
L2-port packet injection that has to consider L2 ports at the hardware forwardin g level. L2-port packet injection that has to consider L2 ports at the hardware-forwardin g level.
The remaining operations are purely ACP control plane and setup of secure channe ls across the The remaining operations are purely ACP control plane and setup of secure channe ls across the
L3 interface. This hopefully makes support for per-L2 port ACP on those hybrid devices easy.</t> L3 interface. This hopefully makes support for per-L2 port ACP on those hybrid devices easy.</t>
<t>In devices without such a mix of L2 port/interfaces and L3 interfaces <t indent="0" pn="section-7.2-9">In devices without such a mix of L2 por
(to terminate any t/interfaces and L3 interfaces (to terminate any
transport layer connections), implementation details will differ. Logically mos transport-layer connections), implementation details will differ. Logically and
t simply every most simply every
L2 port is considered and used as a separate L3 subnet for all ACP operations. The fact that L2 port is considered and used as a separate L3 subnet for all ACP operations. The fact that
the ACP only requires IPv6 link-local unicast and multicast should make support for it on any the ACP only requires IPv6 link-local unicast and multicast should make support for it on any
type of L2 devices as simple as possible.</t> type of L2 devices as simple as possible.</t>
<t>A generic issue with ACP in L2 switched networks is the interaction w <t indent="0" pn="section-7.2-10">A generic issue with ACP in L2-switche
ith the Spanning Tree d networks is the interaction with the Spanning Tree
Protocol. Without further L2 enhancements, the ACP would run only across the ac Protocol (STP). Without further L2 enhancements, the ACP would run only across
tive STP the active STP
topology and the ACP would be interrupted and re-converge with STP changes. topology, and the ACP would be interrupted and reconverge with STP changes.
Ideally, ACP peering SHOULD be built also across ports that are blocked in STP s Ideally, ACP peering <bcp14>SHOULD</bcp14> be built also across ports that are b
o locked in STP so
that the ACP does not depend on STP and can continue to run unaffected across ST P topology that the ACP does not depend on STP and can continue to run unaffected across ST P topology
changes, where re-convergence can be quite slow. The above described simple imp lementation changes, where reconvergence can be quite slow. The above described simple impl ementation
options are not sufficient to achieve this.</t> options are not sufficient to achieve this.</t>
</section> </section>
<!-- switched-lans-how -->
</section> </section>
<!-- switched-lans --> <section anchor="workarounds" numbered="true" toc="include" removeInRFC="fal
<section anchor="workarounds" numbered="true" toc="default"> se" pn="section-8">
<name>Support for Non-ACP Components (Normative)</name> <name slugifiedName="name-support-for-non-acp-compone">Support for Non-ACP
<section anchor="ACPconnect" numbered="true" toc="default"> Components (Normative)</name>
<name>ACP Connect</name> <section anchor="ACPconnect" numbered="true" toc="include" removeInRFC="fa
<section anchor="NMS" numbered="true" toc="default"> lse" pn="section-8.1">
<name>Non-ACP Controller / NMS system</name> <name slugifiedName="name-acp-connect">ACP Connect</name>
<t>The Autonomic Control Plane can be used by management systems, such <section anchor="NMS" numbered="true" toc="include" removeInRFC="false"
as controllers or network management system (NMS) hosts (henceforth called simp pn="section-8.1.1">
ly "NMS hosts"), to connect to devices (or other type of nodes) through it. For <name slugifiedName="name-non-acp-controller-and-or-n">Non-ACP Control
this, an NMS host needs to have access to the ACP. The ACP is a self-protectin ler and/or Network Management System (NMS)</name>
g overlay network, which allows by default access only to trusted, autonomic sys <t indent="0" pn="section-8.1.1-1">The ACP can be used by management s
tems. Therefore, a traditional, non-ACP NMS system does not have access to the ystems, such as controllers or NMS hosts, to connect to devices (or other type o
ACP by default, such as any other external node.</t> f nodes) through it. For this, an NMS host needs to have access to the ACP. Th
<t>If the NMS host is not autonomic, i.e., it does not support autonom e ACP is a self-protecting overlay network, which allows access only to trusted,
ic negotiation of the ACP, then it can be brought into the ACP by explicit confi autonomic systems by default. Therefore, a traditional, non-ACP NMS does not h
guration. To support connections to adjacent non-ACP nodes, an ACP node SHOULD ave access to the ACP by default, such as any other external node.</t>
support "ACP connect" (sometimes also called "autonomic connect"):</t> <t indent="0" pn="section-8.1.1-2">If the NMS host is not autonomic, i
<t>"ACP connect" is an interface level configured workaround for conne .e., it does not support autonomic negotiation of the ACP, then it can be brough
ction of trusted non-ACP nodes to the ACP. The ACP node on which ACP connect is t into the ACP by explicit configuration. To support connections to adjacent no
configured is called an "ACP edge node". With ACP connect, the ACP is accessible n-ACP nodes, an ACP node <bcp14>SHOULD</bcp14> support "ACP connect" (sometimes
from those non-ACP nodes (such as NOC systems) on such an interface without tho also called "autonomic connect").</t>
se non-ACP nodes having to support any ACP discovery or ACP channel setup. This <t indent="0" pn="section-8.1.1-3">"ACP connect" is an interface-level
is also called "native" access to the ACP because to those NOC systems the inte , configured workaround for connection of trusted non-ACP nodes to the ACP. The
rface looks like a normal network interface without any ACP secure channel that ACP node on which ACP connect is configured is called an "ACP edge node". With A
is encapsulating the traffic.</t> CP connect, the ACP is accessible from those non-ACP nodes (such as NOC systems)
<figure anchor="acp-connect"> on such an interface without those non-ACP nodes having to support any ACP disc
<name>ACP connect</name> overy or ACP channel setup. This is also called "native" access to the ACP beca
<artwork name="" type="" align="left" alt=""><![CDATA[ use, to those NOC systems, the interface looks like a normal network interface w
ithout any ACP secure channel that is encapsulating the traffic.</t>
<figure anchor="acp-connect" align="left" suppress-title="false" pn="f
igure-14">
<name slugifiedName="name-acp-connect-2">ACP Connect</name>
<artwork name="" type="" align="left" alt="" pn="section-8.1.1-4.1">
Data-Plane "native" (no ACP) Data Plane "native" (no ACP)
. .
+--------+ +----------------+ . +-------------+ +--------+ +----------------+ . +-------------+
| ACP | |ACP Edge Node | . | | | ACP | |ACP Edge Node | . | |
| Node | | | v | | | Node | | | v | |
| |-------|...[ACP VRF]....+----------------| |+ | |-------|...[ACP VRF]....+----------------| |+
| | ^ |. | | NOC Device || | | ^ |. | | NOC Device ||
| | . | .[Data-Plane]..+----------------| "NMS hosts" || | | . | .[Data Plane]..+----------------| "NMS hosts" ||
| | . | [ ] | . ^ | || | | . | [ ] | . ^ | ||
+--------+ . +----------------+ . . +-------------+| +--------+ . +----------------+ . . +-------------+|
. . . +-------------+ . . . +-------------+
. . . . . .
Data-Plane "native" . ACP "native" (unencrypted) Data Plane "native" . ACP "native" (unencrypted)
+ ACP auto-negotiated . "ACP connect subnet" + ACP auto-negotiated . "ACP connect subnet"
and encrypted . and encrypted .
ACP connect interface ACP connect interface
e.g., "VRF ACP native" (config) e.g., "VRF ACP native" (config)
]]></artwork> </artwork>
</figure> </figure>
<t>ACP connect has security consequences: All systems and processes co <t indent="0" pn="section-8.1.1-5">ACP connect has security consequenc
nnected via ACP connect have access to all ACP nodes on the entire ACP, without es: all systems and processes connected via ACP connect have access to all ACP n
further authentication. Thus, the ACP connect interface and NOC systems connect odes on the entire ACP, without further authentication. Thus, the ACP connect i
ed to it needs to be physically controlled/secured. For this reason the mechani nterface and the NOC systems connected to it need to be physically controlled an
sms described here do explicitly not include options to allow for a non-ACP rout d/or secured. For this reason, the mechanisms described here explicitly do not
er to be connected across an ACP connect interface and addresses behind such a r include options to allow for a non-ACP router to be connected across an ACP conn
outer routed inside the ACP.</t> ect interface and addresses behind such a router routed inside the ACP.</t>
<t>Physical controlled/secured means that attackers can gain no access <t indent="0" pn="section-8.1.1-6">Physically controlled and/or secure
to the physical device hosting the ACP Edge Node, the physical interfaces and l d means that attackers cannot gain access to the physical device hosting the ACP
inks providing the ACP connect link nor the physical devices hosting the NOC Dev edge node, the physical interfaces and links providing the ACP connect link, no
ice. In a simple case, ACP Edge node and NOC Device are co-located in an access r the physical devices hosting the NOC device. In a simple case, ACP edge node a
controlled room, such as a NOC, to which attackers cannot gain physical access.< nd NOC device are colocated in an access-controlled room, such as a NOC, to whic
/t> h attackers cannot gain physical access.</t>
<t>An ACP connect interface provides exclusively access to only the AC <t indent="0" pn="section-8.1.1-7">An ACP connect interface provides e
P. This is likely insufficient for many NMS hosts. Instead, they would require xclusive access to only the ACP. This is likely insufficient for many NMS hosts
a second "Data-Plane" interface outside the ACP for connections between the NMS . Instead, they would require a second "data plane" interface outside the ACP f
host and administrators, or Internet based services, or for direct access to th or connections between the NMS host and administrators, or Internet-based servic
e Data-Plane. The document <xref target="RFC8368" format="default">"Using Auton es, or for direct access to the data plane. The document <xref target="RFC8368"
omic Control Plane for Stable Connectivity of Network OAM"</xref> explains in mo format="default" sectionFormat="of" derivedContent="RFC8368">"Using Autonomic C
re detail how the ACP can be integrated in a mixed NOC environment.</t> ontrol Plane for Stable Connectivity of Network OAM"</xref> explains in more det
<t>An ACP connect interface SHOULD use an IPv6 address/prefix ail how the ACP can be integrated in a mixed NOC environment.</t>
from the ACP Manual Addressing Sub-Scheme (<xref target="manual-scheme" format=" <t indent="0" pn="section-8.1.1-8">An ACP connect interface <bcp14>SHO
default"/>), letting the operator configure for example only the Subnet-ID and h ULD</bcp14> use an IPv6 address/prefix
aving the node automatically assign the remaining part of the prefix/address. I from the Manual Addressing Sub-Scheme (<xref target="manual-scheme" format="defa
t SHOULD NOT use a prefix that is also routed outside the ACP so that the addres ult" sectionFormat="of" derivedContent="Section 6.11.4"/>), letting the operator
ses clearly indicate whether it is used inside the ACP or not.</t> configure, for example, only the Subnet-ID and having the node automatically as
<t>The prefix of ACP connect subnets MUST be distributed by the ACP ed sign the remaining part of the prefix/address. It <bcp14>SHOULD NOT</bcp14> use
ge node into the ACP routing protocol RPL. The NMS hosts MUST connect to prefix a prefix that is also routed outside the ACP so that the addresses clearly indi
es in the ACP routing table via its ACP connect interface. In the simple case w cate whether it is used inside the ACP or not.</t>
here the ACP uses only one ULA prefix and all ACP connect subnets have prefixes <t indent="0" pn="section-8.1.1-9">The prefix of ACP connect subnets <
covered by that ULA prefix, NMS hosts can rely on <xref target="RFC6724" format= bcp14>MUST</bcp14> be
"default"/> to determine longest match prefix routes towards its different inter distributed by the ACP edge node into the ACP routing protocol, RPL.
faces, ACP and Data-Plane. With RFC6724, The NMS host will select the ACP connec The NMS host <bcp14>MUST</bcp14> connect to prefixes in the ACP
t interface for all addresses in the ACP because any ACP destination address is routing table via its ACP connect interface. In the simple case
longest matched by the address on the ACP connect interface. If the NMS hosts A where the ACP uses only one ULA prefix, and all ACP connect subnets
CP connect interface uses another prefix or if the ACP uses multiple ULA prefixe have prefixes covered by that ULA prefix, NMS hosts can rely on
s, then the NMS hosts require (static) routes towards the ACP interface for thes <xref target="RFC6724" format="default" sectionFormat="of" derivedConte
e prefixes.</t> nt="RFC6724"/> to determine longest match
<t> When an ACP Edge node receives a packet from an ACP connect interf prefix routes towards its different interfaces, ACP and
ace, the ACP Edge node data plane. With <xref target="RFC6724" format="default" sectionFormat=
MUST only forward the packet into the ACP if the packet has an IPv6 source addre "of" derivedContent="RFC6724"/>, the NMS host will select the ACP connect interf
ss from that interface (this is sometimes called "RPF filtering"). This filteri ace for all addresses in the ACP because any ACP destination address is longest
ng rule MAY be changed through administrative measures. The more any such admini matched by the address on the ACP connect interface. If the NMS host's ACP conn
strative action enable reachability of non ACP nodes to the ACP, the more this m ect interface uses another prefix, or if the ACP uses multiple ULA prefixes, the
ay cause security issues.</t> n the NMS host requires (static) routes towards the ACP interface for these pref
<t>To limit the security impact of ACP connect, nodes supporting it SH ixes.</t>
OULD implement a security <t indent="0" pn="section-8.1.1-10"> When an ACP edge node receives a
mechanism to allow configuration/use of ACP connect interfaces only on nodes exp packet from an ACP connect interface, the ACP edge node
licitly targeted <bcp14>MUST</bcp14> only forward the packet to the ACP if the packet has an IPv6
source address from that interface (this is sometimes called Reverse Path Forwa
rding (RPF) filtering). This filtering rule <bcp14>MAY</bcp14> be changed throu
gh administrative measures. The more any such administrative action enables reac
hability of non-ACP nodes to the ACP, the more this may cause security issues.</
t>
<t indent="0" pn="section-8.1.1-11">To limit the security impact of AC
P connect, nodes supporting it <bcp14>SHOULD</bcp14> implement a security
mechanism to allow configuration and/or use of ACP connect interfaces only on no
des explicitly targeted
to be deployed with it (those in physically secure locations such as a NOC). Fo r example, to be deployed with it (those in physically secure locations such as a NOC). Fo r example,
the registrar could disable the ability to enable ACP connect on devices during the registrar could disable the ability to enable ACP connect on devices during
enrollment enrollment,
and that property could only be changed through re-enrollment. See also <xref t and that property could only be changed through reenrollment. See also <xref ta
arget="role-assignments" format="default"/>.</t> rget="role-assignments" format="default" sectionFormat="of" derivedContent="Appe
<t>ACP Edge nodes SHOULD have a configurable option to prohibit packet ndix A.9.5"/>.</t>
s with RPI headers (see <xref target="rpl-Data-Plane" format="default"/> across <t indent="0" pn="section-8.1.1-12">ACP edge nodes <bcp14>SHOULD</bcp1
an ACP connect interface. These headers are outside the scope of the RPL profile 4> have a configurable option to prohibit packets with RPI headers (see <xref ta
in this specification but may be used in future extensions of this specificatio rget="rpl-Data-Plane" format="default" sectionFormat="of" derivedContent="Sectio
n.</t> n 6.12.1.13"/>) across an ACP connect interface. These headers are outside the s
cope of the RPL profile in this specification but may be used in future extensio
ns of this specification.</t>
</section> </section>
<!-- NMS --> <section anchor="software" numbered="true" toc="include" removeInRFC="fa
<section anchor="software" numbered="true" toc="default"> lse" pn="section-8.1.2">
<name>Software Components</name> <name slugifiedName="name-software-components">Software Components</na
<t>The previous section assumed that ACP Edge node and NOC devices are me>
separate physical devices and the ACP connect interface is a physical network c <t indent="0" pn="section-8.1.2-1">The previous section assumed that t
onnection. This section discusses the implication when these components are inst he ACP edge node and NOC devices are separate physical devices and that the ACP
ead software components running on a single physical device.</t> connect interface is a physical network connection. This section discusses the i
<t>The ACP connect mechanism cannot only be used to connect physically mplication when these components are instead software components running on a si
external systems (NMS hosts) to the ACP but also other applications, containers ngle physical device.</t>
or virtual machines. In fact, one possible way to eliminate the security issue <t indent="0" pn="section-8.1.2-2">The ACP connect mechanism can be us
of the external ACP connect interface is to collocate an ACP edge node and an N ed not only to connect physically external systems (NMS hosts) to the ACP but al
MS host by making one a virtual machine or container inside the other; and there so other applications, containers, or virtual machines. In fact, one possible w
fore converting the unprotected external ACP subnet into an internal virtual sub ay to eliminate the security issue of the external ACP connect interface is to c
net in a single device. This would ultimately result in a fully ACP enabled NMS olocate an ACP edge node and an NMS host by making one a virtual machine or cont
host with minimum impact to the NMS hosts software architecture. This approach ainer inside the other; therefore converting the unprotected external ACP subnet
is not limited to NMS hosts but could equally be applied to devices consisting into an internal virtual subnet in a single device. This would ultimately resu
of one or more VNF (virtual network functions): An internal virtual subnet conne lt in a fully ACP-enabled NMS host with minimum impact to the NMS host's softwar
cting out-of-band management interfaces of the VNFs to an ACP edge router VNF.</ e architecture. This approach is not limited to NMS hosts but could equally be
t> applied to devices consisting of one or more VNF (virtual network functions): an
<t>The core requirement is that the software components need to have a internal virtual subnet connecting out-of-band management interfaces of the VNF
network stack that permits access to the ACP and optionally also the Data-Plane s to an ACP edge router VNF.</t>
. Like in the physical setup for NMS hosts this can be realized via two interna <t indent="0" pn="section-8.1.2-3">The core requirement is that the so
l virtual subnets. One that is connecting to the ACP (which could be a containe ftware components need to have a network stack that permits access to the ACP an
r or virtual machine by itself), and one (or more) connecting into the Data-Plan d optionally also to the data plane. Like in the physical setup for NMS hosts,
e.</t> this can be realized via two internal virtual subnets: one that connects to the
<t>This "internal" use of ACP connect approach should not be considere ACP (which could be a container or virtual machine by itself), and one (or more)
d to be a "workaround" because in this case it is possible to build a correct se connecting to the data plane.</t>
curity model: It is not necessary to rely on unprovable external physical securi <t indent="0" pn="section-8.1.2-4">This "internal" use of the ACP conn
ty mechanisms as in the case of external NMS hosts. Instead, the orchestration ect approach should not be considered to be a "workaround" because, in this case
of the ACP, the virtual subnets and the software components can be done by trust , it is possible to build a correct security model: it is not necessary to rely
ed software that could be considered to be part of the ANI (or even an extended on unprovable, external physical security mechanisms as in the case of external
ACP). This software component is responsible for ensuring that only trusted sof NMS hosts. Instead, the orchestration of the ACP, the virtual subnets, and the
tware components will get access to that virtual subnet and that only even more software components can be done by trusted software that could be considered to
trusted software components will get access to both the ACP virtual subnet and t be part of the ANI (or even an extended ACP). This software component is respon
he Data-Plane (because those ACP users could leak traffic between ACP and Data-P sible for ensuring that only trusted software components will get access to that
lane). This trust could be established for example through cryptographic means virtual subnet and that only even more trusted software components will get acc
such as signed software packages.</t> ess to both the ACP virtual subnet and the data plane (because those ACP users c
ould leak traffic between ACP and data plane). This trust could be established,
for example, through cryptographic means such as signed software packages.</t>
</section> </section>
<!-- software --> <section anchor="ACautoconfig" numbered="true" toc="include" removeInRFC
<section anchor="ACautoconfig" numbered="true" toc="default"> ="false" pn="section-8.1.3">
<name>Auto Configuration</name> <name slugifiedName="name-autoconfiguration">Autoconfiguration</name>
<t>ACP edge nodes, NMS hosts and software components that as described <t indent="0" pn="section-8.1.3-1">ACP edge nodes, NMS hosts, and soft
in the previous section are meant to be composed via virtual interfaces SHOULD ware components that, as described in the previous section, are meant to be comp
support on the ACP connect subnet StateLess Address Autoconfiguration (SLAAC - < osed via virtual interfaces <bcp14>SHOULD</bcp14> support SLAAC <xref target="RF
xref target="RFC4862" format="default"/>) and route auto configuration according C4862" format="default" sectionFormat="of" derivedContent="RFC4862"/> on the ACP
to <xref target="RFC4191" format="default"/>.</t> connect subnet and route autoconfiguration according to "<xref target="RFC4191"
format="title" sectionFormat="of" derivedContent="Default Router Preferences an
<t>The ACP edge node acts as the router towards the ACP on the ACP con d More-Specific Routes"/>" <xref target="RFC4191" format="default" sectionFormat
nect subnet, ="of" derivedContent="RFC4191"/>.</t>
providing the (auto-)configured prefix for the ACP connect subnet and <t indent="0" pn="section-8.1.3-2">The ACP edge node acts as the route
(auto-)configured routes into the ACP to NMS hosts and/or software com r towards the ACP on the ACP connect subnet,
ponents.</t> providing the (auto)configured prefix for the ACP connect subnet and
(auto)configured routes to the ACP to NMS hosts and/or software compon
<t> The ACP edge node uses the Route Information Option (RIO) of RFC41 ents.</t>
91 to announce <t indent="0" pn="section-8.1.3-3"> The ACP edge node uses the Route I
aggregated prefixes for address prefixes used in the ACP (with normal nformation Option (RIO) of <xref target="RFC4191" format="default" sectionFormat
RIO lifetimes. ="of" derivedContent="RFC4191"/> to announce
aggregated prefixes for address prefixes used in the ACP (with normal
RIO lifetimes).
In addition, the ACP edge node also uses a RIO to announce the default route (::/0) with In addition, the ACP edge node also uses a RIO to announce the default route (::/0) with
a lifetime of 0.</t> a lifetime of 0.</t>
<t indent="0" pn="section-8.1.3-4">These RIOs allow the connecting of
<t>These RIOs allow to connect Type C hosts to the ACP via an ACP conn type C hosts to the ACP via an ACP connect subnet on one interface
ect subnet on one interface and another network (Data Plane and/or NMS network) on the same or ano
and another network (Data Plane / NMS network) on the same or another ther interface of the type C host, relying on
interface of the Type C host, relying on other routers other than the ACP edge node. The RIOs ensure that these hosts
routers than the ACP edge node. The RIOs ensure that these hosts will will only route the prefixes used in the ACP to
only route the prefixes used in the ACP to
the ACP edge node.</t> the ACP edge node.</t>
<t>Type A/B host ignore the RIOs and will consider the ACP node to be <t indent="0" pn="section-8.1.3-5">Type A and B hosts ignore the RIOs
their default router for and will consider the ACP node to be their default router for
all destination. This is sufficient when type A/B hosts only need to all destinations. This is sufficient when the type A or type B host o
connect to the ACP but not to other networks. nly needs to connect to the ACP but not to other networks.
Attaching Type A/B hosts to both the ACP and other networks, requires Attaching a type A or type B host to both the ACP and other networks
either explicit requires explicit ACP prefix route configuration on either the host or
ACP prefix route configuration on the Type A/B hosts or the combined A the combined ACP and data plane interface on the ACP edge node,
CP/Data-Plane interface on the ACP edge node, see <xref target="SingleIF" format="default" sectionFormat="of" derive
see <xref target="SingleIF" format="default"/>.</t> dContent="Section 8.1.4"/>.</t>
<t indent="0" pn="section-8.1.3-6">Aggregated prefix means that the AC
<t>Aggregated prefix means that the ACP edge node needs to only announ P edge node needs to only announce
ce
the /48 ULA prefixes used in the ACP but none of the actual /64 the /48 ULA prefixes used in the ACP but none of the actual /64
(Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub-Scheme) , (Manual Addressing Sub-Scheme), /127 (Zone Addressing Sub-Scheme),
/112 or /120 (Vlong Addressing Sub-Scheme) routes of actual ACP nodes . /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual ACP nodes .
If ACP interfaces are configured with non ULA prefixes, then those pr If ACP interfaces are configured with non-ULA prefixes, then those pr
efixes cannot be aggregated without further configured policy on the ACP edge no efixes cannot be aggregated without further configured policy on the ACP edge no
de. This explains the above recommendation to use ACP ULA prefix covered prefix de. This explains the above recommendation to use ACP ULA prefixes for ACP conn
es for ACP connect interfaces: They allow for a shorter list of prefixes to be s ect interfaces: they allow for a shorter list of prefixes to be signaled via <xr
ignaled via RFC4191 to NMS hosts and software components.</t> ef target="RFC4191" format="default" sectionFormat="of" derivedContent="RFC4191"
/> to NMS hosts and software components.</t>
<t>The ACP edge nodes that have a Vlong ACP address MAY allocate a sub <t indent="0" pn="section-8.1.3-7">The ACP edge nodes that have a Vlon
set of their /112 or /120 address prefix to ACP connect interface(s) to eliminat g ACP address <bcp14>MAY</bcp14> allocate a subset of their /112 or /120 address
e the need to non-autonomically configure/provision the address prefixes for suc prefix to ACP connect interface(s) to eliminate the need to non-autonomically c
h ACP connect interfaces.</t> onfigure and/or provision the address prefixes for such ACP connect interfaces.<
<!-- See <xref target="up4291"/> for considerations how this updates /t>
the IPv6 address architecture and ULA specification.</t> -->
</section> </section>
<!-- ACautoconfig --> <section anchor="SingleIF" numbered="true" toc="include" removeInRFC="fa
<section anchor="SingleIF" numbered="true" toc="default"> lse" pn="section-8.1.4">
<name>Combined ACP/Data-Plane Interface (VRF Select)</name> <name slugifiedName="name-combined-acp-and-data-plane">Combined ACP an
<figure anchor="vrf-select"> d Data Plane Interface (VRF Select)</name>
<name>VRF select</name> <figure anchor="vrf-select" align="left" suppress-title="false" pn="fi
<artwork name="" type="" align="left" alt=""><![CDATA[ gure-15">
<name slugifiedName="name-vrf-select">VRF Select</name>
<artwork name="" type="" align="left" alt="" pn="section-8.1.4-1.1">
Combined ACP and Data-Plane interface Combined ACP and data plane interface
. .
+--------+ +--------------------+ . +--------------+ +--------+ +--------------------+ . +--------------+
| ACP | |ACP Edge No | . | NMS Host(s) | | ACP | |ACP Edge No | . | NMS Host(s) |
| Node | | | . | / Software | | Node | | | . | / Software |
| | | [ACP ]. | . | |+ | | | [ACP ]. | . | |+
| | | .[VRF ] .[VRF ] | v | "ACP address"|| | | | .[VRF ] .[VRF ] | v | "ACP Address"||
| +-------+. .[Select].+--------+ "Date Plane || | +-------+. .[Select].+--------+ "Data Plane ||
| | ^ | .[Data ]. | | Address(es)"|| | | ^ | .[Data ]. | | Address(es)"||
| | . | [Plane] | | || | | . | [Plane] | | ||
| | . | [ ] | +--------------+| | | . | [ ] | +--------------+|
+--------+ . +--------------------+ +--------------+ +--------+ . +--------------------+ +--------------+
. .
Data-Plane "native" and + ACP auto-negotiated/encrypted Data plane "native" and + ACP auto-negotiated/encrypted
]]></artwork> </artwork>
</figure> </figure>
<t>Using two physical and/or virtual subnets (and therefore interfaces <t indent="0" pn="section-8.1.4-2">Using two physical and/or virtual s
) into NMS Hosts (as per <xref target="NMS" format="default"/>) or Software (as ubnets (and therefore interfaces) to NMS hosts (as per <xref target="NMS" format
per <xref target="software" format="default"/>) may be seen as additional comple ="default" sectionFormat="of" derivedContent="Section 8.1.1"/>) or software (as
xity, for example with legacy NMS Hosts that support only one IP interface, or i per <xref target="software" format="default" sectionFormat="of" derivedContent="
t may be insufficient to support <xref target="RFC4191" format="default"/> Type Section 8.1.2"/>) may be seen as additional complexity, for example, with legacy
A or B host (see <xref target="ACautoconfig" format="default"/>).</t> NMS hosts that support only one IP interface, or it may be insufficient to supp
<t>To provide a single subnet into both ACP and Data-Plane, the ACP Ed ort type A or type B hosts <xref target="RFC4191" format="default" sectionFormat
ge node needs to de-multiplex packets from NMS hosts into ACP VRF and Data-Plane ="of" derivedContent="RFC4191"/> (see <xref target="ACautoconfig" format="defaul
. This is sometimes called "VRF select". If the ACP VRF has no overlapping IPv t" sectionFormat="of" derivedContent="Section 8.1.3"/>).</t>
6 addresses with the Data-Plane (it should have no overlapping addresses), then <t indent="0" pn="section-8.1.4-3">To provide a single subnet to both
this function can use the IPv6 Destination address. The problem is Source Addre the ACP and Data plane, the ACP edge node needs to demultiplex packets from NMS
ss Selection on the NMS Host(s) according to RFC6724.</t> hosts into ACP VRF and data plane. This is sometimes called "VRF select". If t
<t>Consider the simple case: The ACP uses only one ULA prefix, the ACP he ACP VRF has no overlapping IPv6 addresses with the data plane (it should have
IPv6 prefix for the Combined ACP and Data-Plane interface is covered by that UL no overlapping addresses), then this function can use the IPv6 destination addr
A prefix. The ACP edge node announces both the ACP IPv6 prefix and one (or more ess. The problem is source address selection on the NMS host(s) according to <x
) prefixes for the Data-Plane. Without further policy configurations on the NMS ref target="RFC6724" format="default" sectionFormat="of" derivedContent="RFC6724
Host(s), it may select its ACP address as a source address for Data-Plane ULA d "/>.</t>
estinations because of Rule 8 of RFC6724. The ACP edge node can pass on the pac <t indent="0" pn="section-8.1.4-4">Consider the simple case: the ACP u
ket to the Data-Plane, but the ACP source address should not be used for Data-Pl ses only one ULA prefix, and the ACP IPv6 prefix for the combined ACP and data p
ane traffic, and return traffic may fail.</t> lane interface is covered by that ULA prefix. The ACP edge node announces both
<t>If the ACP carries multiple ULA prefixes or non-ULA ACP connect pre the ACP IPv6 prefix and one (or more) prefixes for the data plane. Without furt
fixes, then the correct source address selection becomes even more problematic.< her policy configurations on the NMS host(s), it may select its ACP address as a
/t> source address for data plane ULA destinations because of Rule 8 (<xref target=
<t>With separate ACP connect and Data-Plane subnets and RFC4191 prefix "RFC6724" section="5" sectionFormat="of" format="default" derivedLink="https://r
announcements that are to be routed across the ACP connect interface, RFC6724 s fc-editor.org/rfc/rfc6724#section-5" derivedContent="RFC6724"/>). The ACP edge
ource address selection Rule 5 (use address of outgoing interface) will be used, node can pass on the packet to the data plane, but the ACP source address should
so that above problems do not occur, even in more complex cases of multiple ULA not be used for data plane traffic, and return traffic may fail.</t>
and non-ULA prefixes in the ACP routing table.</t> <t indent="0" pn="section-8.1.4-5">If the ACP carries multiple ULA pre
<t>To achieve the same behavior with a Combined ACP and Data-Plane int fixes or non-ULA ACP connect prefixes, then the correct source address selection
erface, the ACP Edge Node needs to behave as two separate routers on the interfa becomes even more problematic.</t>
ce: One link-local IPv6 address/router for its ACP reachability, and one link-lo <t indent="0" pn="section-8.1.4-6">With separate ACP connect and data
cal IPv6 address/router for its Data-Plane reachability. The Router Advertiseme plane subnets and prefix announcements <xref target="RFC4191" format="default" s
nts for both are as described above (<xref target="ACautoconfig" format="default ectionFormat="of" derivedContent="RFC4191"/> that are to be routed across the AC
"/>): For the ACP, the ACP prefix is announced together with RFC4191 option for P connect interface, the source address selection of Rule 5 (use address of outg
the prefixes routed across the ACP and lifetime=0 to disqualify this next-hop as oing interface) (<xref target="RFC6724" section="5" sectionFormat="of" format="d
a default router. For the Data-Plane, the Data-Plane prefix(es) are announced efault" derivedLink="https://rfc-editor.org/rfc/rfc6724#section-5" derivedConten
together with whatever dafault router parameters are used for the Data-Plane.</t t="RFC6724"/>) will be used, so that above problems do not occur, even in more c
> omplex cases of multiple ULA and non-ULA prefixes in the ACP routing table.</t>
<t>In result, RFC6724 source address selection Rule 5.5 may result in <t indent="0" pn="section-8.1.4-7">To achieve the same behavior with a
the same correct source address selection behavior of NMS hosts without further combined ACP and data plane interface, the ACP edge node needs to behave as two
configuration on it as the separate ACP connect and Data-Plane interfaces. As d separate routers on the interface: one link-local IPv6 address/router for its A
escribed in the text for Rule 5.5, this is only a MAY, because IPv6 hosts are no CP reachability, and one link-local IPv6 address/router for its data plane reach
t required to track next-hop information. If an NMS Host does not do this, then ability. The Router Advertisements for both are as described in <xref target="A
separate ACP connect and Data-Plane interfaces are the preferable method of att Cautoconfig" format="default" sectionFormat="of" derivedContent="Section 8.1.3"/
achment. Hosts implementing <xref target="RFC8028" format="default"/> should (i >: for the ACP, the ACP prefix is announced together with the prefix option <xre
nstead of may) implement <xref target="RFC6724" format="default"/> Rule 5.5, so f target="RFC4191" format="default" sectionFormat="of" derivedContent="RFC4191"/
it is preferred for hosts to support <xref target="RFC8028" format="default"/>.< > routed across the ACP, and the lifetime is set to zero to disqualify this next
/t> hop as a default router. For the data plane, the data plane prefix(es) are ann
<t>ACP edge nodes MAY support the Combined ACP and Data-Plane interfac ounced together with whatever default router parameters are used for the data pl
e.</t> ane.</t>
<t indent="0" pn="section-8.1.4-8">As a result, source address selecti
on Rule 5.5 (<xref target="RFC6724" section="5" sectionFormat="of" format="defau
lt" derivedLink="https://rfc-editor.org/rfc/rfc6724#section-5" derivedContent="R
FC6724"/>) may result in the same correct source address selection behavior of N
MS hosts without further configuration as the separate ACP connect and data plan
e interfaces on the host. As described in the text for Rule 5.5 (<xref target="
RFC6724" section="5" sectionFormat="of" format="default" derivedLink="https://rf
c-editor.org/rfc/rfc6724#section-5" derivedContent="RFC6724"/>), this is only a
<bcp14>MAY</bcp14> because IPv6 hosts are not required to track next-hop informa
tion. If an NMS host does not do this, then separate ACP connect and data plane
interfaces are the preferable method of attachment. Hosts implementing "<xref
target="RFC8028" format="title" sectionFormat="of" derivedContent="First-Hop Rou
ter Selection by Hosts in a Multi-Prefix Network"/>" <xref target="RFC8028" form
at="default" sectionFormat="of" derivedContent="RFC8028"/> should (instead of ma
y) implement Rule 5.5 (<xref target="RFC6724" section="5" sectionFormat="of" for
mat="default" derivedLink="https://rfc-editor.org/rfc/rfc6724#section-5" derived
Content="RFC6724"/>), so it is preferred for hosts to support <xref target="RFC8
028" format="default" sectionFormat="of" derivedContent="RFC8028"/>.</t>
<t indent="0" pn="section-8.1.4-9">ACP edge nodes <bcp14>MAY</bcp14> s
upport the combined ACP and data plane interface.</t>
</section> </section>
<!-- SingleIF --> <section anchor="ACgrasp" numbered="true" toc="include" removeInRFC="fal
<section anchor="ACgrasp" numbered="true" toc="default"> se" pn="section-8.1.5">
<name>Use of GRASP</name> <name slugifiedName="name-use-of-grasp">Use of GRASP</name>
<t>GRASP can and should be possible to use across ACP connect interfac <t indent="0" pn="section-8.1.5-1">GRASP can and should be possible to
es, especially in use across ACP connect interfaces, especially in
the architectural correct solution when it is used as a mechanism to connect Sof the architecturally correct solution when it is used as a mechanism to connect s
tware oftware
(e.g., ASA or legacy NMS applications) to the ACP.</t> (e.g., ASA or legacy NMS applications) to the ACP.</t>
<t>Given how the ACP is the security and transport substrate for GRASP <t indent="0" pn="section-8.1.5-2">Given how the ACP is the security a
, the requirements nd transport substrate for GRASP, the requirements
for devices connected via ACP connect is that those are equivalently (if not bet are that those devices connected via ACP connect are equivalently (if not better
ter) )
secured against attacks than ACP nodes that do not use ACP connect and run only secured against attacks than ACP nodes that do not use ACP connect, and they run
software that is equally (if not better) protected, known (or trusted) not to be only
malicious software that is equally (if not better) protected, known (or trusted) not to be
malicious,
and accordingly designed to isolate access to the ACP against external equipment .</t> and accordingly designed to isolate access to the ACP against external equipment .</t>
<t>The difference in security is that cryptographic security of the <t indent="0" pn="section-8.1.5-3">The difference in security is that
ACP secure channel is replaced by required physical security/control of the netw cryptographic security of the
ork connection ACP secure channel is replaced by required physical security and/or control of t
he network connection
between an ACP edge node and the NMS or other host reachable via the ACP connect between an ACP edge node and the NMS or other host reachable via the ACP connect
interface. See <xref target="NMS" format="default"/>.</t> interface. See <xref target="NMS" format="default" sectionFormat="of" derivedCon
<t>When using "Combined ACP and Data-Plane Interfaces", care has to be tent="Section 8.1.1"/>.</t>
taken that <t indent="0" pn="section-8.1.5-4">When using the combined ACP and dat
only GRASP messages intended for the ACP GRASP domain received from Software or a plane interface, care has to be taken that
NMS Hosts are forwarded by ACP edge nodes. Currently there is no definition for only GRASP messages received from software or
NMS hosts and intended for the ACP GRASP domain are forwarded by ACP edge nodes.
Currently there is no definition for
a GRASP security and transport substrate beside the ACP, so there is no definiti on a GRASP security and transport substrate beside the ACP, so there is no definiti on
how such Software/NMS Host could participate in two separate GRASP Domains acros how such software/NMS host could participate in two separate GRASP domains acros
s s
the same subnet (ACP and Data-Plane domains). At current it is assumed that the same subnet (ACP and data plane domains). Currently it is assumed that
all GRASP packets on a Combined ACP and Data-Plane interface belong to the GRASP all GRASP packets on a combined ACP and data plane interface belong to the GRASP
ACP Domain. ACP domain.
They SHOULD all use the ACP IPv6 addresses of the Software/NMS Hosts. The link- They <bcp14>SHOULD</bcp14> all use the ACP IPv6 addresses of the software/NMS ho
local sts. The link-local
IPv6 addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and M_FLOOD mes IPv6 addresses of software/NMS hosts (used for GRASP M_DISCOVERY and M_FLOOD mes
sages) sages)
are also assumed to belong to the ACP address space.</t> are also assumed to belong to the ACP address space.</t>
</section> </section>
<!-- ACgrasp -->
</section> </section>
<!-- ACP connect --> <section anchor="remote-acp-neighbors" numbered="true" toc="include" remov
<section anchor="remote-acp-neighbors" numbered="true" toc="default"> eInRFC="false" pn="section-8.2">
<name>Connecting ACP islands over Non-ACP L3 networks (Remote ACP neighb <name slugifiedName="name-connecting-acp-islands-over">Connecting ACP Is
ors)</name> lands over Non-ACP L3 Networks (Remote ACP Neighbors)</name>
<t>Not all nodes in a network may support the ACP. If non-ACP Layer-2 d <t indent="0" pn="section-8.2-1">Not all nodes in a network may support
evices are between ACP nodes, the ACP will work across it since it is IP based. the ACP. If non-ACP L2 devices are between ACP nodes, the ACP will work across
However, the autonomic discovery of ACP neighbors via DULL GRASP is only intend them since it is IP based. However, the autonomic discovery of ACP neighbors vi
ed to work across L2 connections, so it is not sufficient to autonomically creat a DULL GRASP is only intended to work across L2 connections, so it is not suffic
e ACP connections across non-ACP Layer-3 devices.</t> ient to autonomically create ACP connections across non-ACP L3 devices.</t>
<section anchor="conf-remote" numbered="true" toc="default"> <section anchor="conf-remote" numbered="true" toc="include" removeInRFC=
<name>Configured Remote ACP neighbor</name> "false" pn="section-8.2.1">
<t>On the ACP node, remote ACP neighbors are configured explicitly. <name slugifiedName="name-configured-remote-acp-neigh">Configured Remo
The parameters of such a "connection" are described in the following ABNF.</ te ACP Neighbor</name>
t> <t indent="0" pn="section-8.2.1-1">On the ACP node, remote ACP neighbo
<figure anchor="abnf"> rs are configured explicitly.
<name>Parameters for remote ACP neighbors</name> The parameters of such a "connection" are described in the following ABNF.
<artwork name="" type="" align="left" alt=""><![CDATA[ The syntax shown is non-normative (as there are no standards for
connection = [ method , local-addr, remote-addr, ?pmtu ] configuration) but only meant to illustrate the parameters and which
method = [ "IKEv2", ?port ] ones can be optional.</t>
method =/ [ "DTLS", port ] <figure anchor="abnf" align="left" suppress-title="false" pn="figure-1
local-addr = [ address , ?vrf ] 6">
remote-addr = [ address ] <name slugifiedName="name-parameters-for-remote-acp-n">Parameters fo
address = ("any" | ipv4-address | ipv6-address ) r Remote ACP Neighbors</name>
vrf = tstr ; Name of a VRF on this node with local-address <sourcecode name="" type="abnf" markers="false" pn="section-8.2.1-2.
]]></artwork> 1">
connection = method "," local-addr "," remote-addr [ "," pmtu ]
method = "any"
/ ( "IKEv2" [ ":" port ] )
/ ( "DTLS" [ ":" port ] )
port = 1*DIGIT
local-addr = [ address [ ":" vrf ] ]
remote-addr = address
address = "any"
/ IPv4address / IPv6address ; From [RFC5954]
vrf = system-dependent ; Name of VRF for local-address
</sourcecode>
</figure> </figure>
<t>Explicit configuration of a remote-peer according to this <t indent="0" pn="section-8.2.1-3">Explicit configuration of a remote peer according to this
ABNF provides all the information to build a secure channel without requiring a tunnel ABNF provides all the information to build a secure channel without requiring a tunnel
to that peer and running DULL GRASP inside of it.</t> to that peer and running DULL GRASP inside of it.</t>
<t>The configuration includes the parameters otherwise signaled <t indent="0" pn="section-8.2.1-4">The configuration includes the para
via DULL GRASP: local address, remote (peer) locator and meters otherwise signaled
via DULL GRASP: local address, remote (peer) locator, and
method. The differences over DULL GRASP local neighbor method. The differences over DULL GRASP local neighbor
discovery and secure channel creation are as follows:</t> discovery and secure channel creation are as follows:</t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>The local and remote address can be IPv4 or IPv6 and are typical -8.2.1-5">
ly global scope addresses.</li> <li pn="section-8.2.1-5.1">The local and remote address can be IPv4
<li>The VRF across which the connection is built (and in which local or IPv6 and are typically global-scope addresses.</li>
-addr exists) can to be specified. If vrf is not specified, it is the default V <li pn="section-8.2.1-5.2">The VRF across which the connection is bu
RF on the node. In DULL GRASP the VRF is implied by the interface across which ilt (and in which local-addr exists) can be specified. If vrf is not specified,
DULL GRASP operates.</li> it is the default VRF on the node. In DULL GRASP, the VRF is implied by the in
<li>If local address is "any", the local address used when initiatin terface across which DULL GRASP operates.</li>
g a secure channel connection is decided by source address selection (<xref targ <li pn="section-8.2.1-5.3">If local address is "any", the local addr
et="RFC6724" format="default"/> for IPv6). As a responder, the connection listen ess used when initiating a secure channel connection is decided by source addres
s on all addresses of the node in the selected VRF.</li> s selection (<xref target="RFC6724" format="default" sectionFormat="of" derivedC
<li>Configuration of port is only required for methods where no defa ontent="RFC6724"/> for IPv6). As a responder, the connection listens on all addr
ults exist (e.g., "DTLS").</li> esses of the node in the selected VRF.</li>
<li>If remote address is "any", the connection is only a responder. <li pn="section-8.2.1-5.4">Configuration of port is only required fo
It is a "hub" that can be used by multiple remote peers to connect simultaneousl r methods where no defaults exist (e.g., "DTLS").</li>
y - without having to know or configure their addresses. Example: Hub site for r <li pn="section-8.2.1-5.5">If the remote address is "any", the conne
emote "spoke" sites reachable over the Internet.</li> ction is only a responder. It is a "hub" that can be used by multiple remote pee
<li>Pmtu should be configurable to overcome issues/limitations of Pa rs to connect simultaneously -- without having to know or configure their addres
th MTU Discovery (PMTUD).</li> ses, for example, a hub site for remote "spoke" sites reachable over the Interne
<li>IKEv2/IPsec to remote peers should support the optional NAT Trav t.</li>
ersal (NAT-T) procedures.</li> <li pn="section-8.2.1-5.6">The pmtu parameter should be configurable
to overcome issues or limitations of Path MTU Discovery (PMTUD).</li>
<li pn="section-8.2.1-5.7">IKEv2/IPsec to remote peers should suppor
t the optional NAT Traversal (NAT-T) procedures.</li>
</ul> </ul>
</section> </section>
<section anchor="conf-tunnel" numbered="true" toc="default"> <section anchor="conf-tunnel" numbered="true" toc="include" removeInRFC=
<name>Tunneled Remote ACP Neighbor</name> "false" pn="section-8.2.2">
<name slugifiedName="name-tunneled-remote-acp-neighbo">Tunneled Remote
<t>An IPinIP, GRE or other form of pre-existing tunnel is configured ACP Neighbor</name>
between two remote ACP peers and the virtual interfaces representing <t indent="0" pn="section-8.2.2-1">An IP-in-IP, GRE, or other form of
preexisting tunnel is configured
between two remote ACP peers, and the virtual interfaces representing
the tunnel are configured for "ACP enable". This will enable IPv6 the tunnel are configured for "ACP enable". This will enable IPv6
link local addresses and DULL on this tunnel. In result, the tunnel link-local addresses and DULL on this tunnel. As a result, the tunnel
is used for normal "L2 adjacent" candidate ACP neighbor discovery is used for normal "L2 adjacent" candidate ACP neighbor discovery
with DULL and secure channel setup procedures described in this document .</t> with DULL and secure channel setup procedures described in this document .</t>
<t indent="0" pn="section-8.2.2-2">Tunneled Remote ACP Neighbor requir
<t>Tunneled Remote ACP Neighbor requires two encapsulations: es two encapsulations:
the configured tunnel and the secure channel inside of that tunnel. the configured tunnel and the secure channel inside of that tunnel.
This makes it in general less desirable than Configured Remote ACP Neigh bor. This makes it in general less desirable than Configured Remote ACP Neigh bor.
Benefits of tunnels are that it may be easier to implement because Benefits of tunnels are that it may be easier to implement because
there is no change to the ACP functionality - just running it over there is no change to the ACP functionality - just running it over
a virtual (tunnel) interface instead of only native interfaces. a virtual (tunnel) interface instead of only native interfaces.
The tunnel itself may also provide PMTUD while the secure channel The tunnel itself may also provide PMTUD while the secure channel
method may not. Or the tunnel mechanism is permitted/possible through s ome method may not. Or the tunnel mechanism is permitted/possible through s ome
firewall while the secure channel method may not.</t> firewall while the secure channel method may not.</t>
<t indent="0" pn="section-8.2.2-3">Tunneling using an insecure tunnel
<t>Tunneling using an insecure tunnel encapsulation increases on average encapsulation increases, on average,
the risk of a MITM downgrade attack somewhere along the underlay path the risk of a MITM downgrade attack somewhere along the underlay path.
that blocks all but the most easily attacked ACP secure channel option. In such an attack, the MITM filters packets for all but the most easily
ACP nodes supporting tunneled remote ACP Neighbors SHOULD support attacked ACP secure channel option to force use of that option.
ACP nodes supporting Tunneled Remote ACP Neighbors <bcp14>SHOULD</bcp14>
support
configuration on such tunnel interfaces to restrict or explicitly configuration on such tunnel interfaces to restrict or explicitly
select the available ACP secure channel protocols select the available ACP secure channel protocols
(if the ACP node supports more than one ACP secure channel protocol in t he first place).</t> (if the ACP node supports more than one ACP secure channel protocol in t he first place).</t>
</section> </section>
<section anchor="conf-summary" numbered="true" toc="default"> <section anchor="conf-summary" numbered="true" toc="include" removeInRFC
<name>Summary</name> ="false" pn="section-8.2.3">
<t>Configured/Tunneled Remote ACP neighbors are less "indestructible" <name slugifiedName="name-summary">Summary</name>
than L2 adjacent ACP neighbors based on link local addressing, since <t indent="0" pn="section-8.2.3-1">Configured and Tunneled Remote ACP
they depend on more correct Data-Plane operations, such as routing and g Neighbors are less "indestructible"
lobal addressing.</t> than L2 adjacent ACP neighbors based on link-local addressing, since
<t>Nevertheless, these options may be crucial to incrementally deploy they depend on more correct data plane operations, such as routing and g
lobal addressing.</t>
<t indent="0" pn="section-8.2.3-2">Nevertheless, these options may be
crucial to incrementally deploying
the ACP, especially if it is meant to connect islands across the Interne t. the ACP, especially if it is meant to connect islands across the Interne t.
Implementations SHOULD support at least Tunneled Remote ACP Neighbors Implementations <bcp14>SHOULD</bcp14> support at least Tunneled Remote A
via GRE tunnels - which is likely the most common router-to-router CP Neighbors
via GRE tunnels, which is likely the most common router-to-router
tunneling protocol in use today.</t> tunneling protocol in use today.</t>
</section> </section>
</section> </section>
<!-- remote-acp-neighbors-->
</section> </section>
<!-- workarounds --> <section anchor="operational" numbered="true" toc="include" removeInRFC="fal
<section anchor="operational" numbered="true" toc="default"> se" pn="section-9">
<name>ACP Operations (Informative)</name> <name slugifiedName="name-acp-operations-informative">ACP Operations (Info
<t>The following sections document important operational aspects of the AC rmative)</name>
P. They are not normative because they do not impact the interoperability betwee <t indent="0" pn="section-9-1">The following sections document important o
n components of the ACP, but they include recommendations/requirements for the i perational aspects of the ACP. They are not normative because they do not impact
nternal operational model beneficial or necessary to achieve the desired use-cas the interoperability between components of the ACP, but they include recommenda
e benefits of the ACP (see <xref target="usage" format="default"/>).</t> tions and/or requirements for the internal operational model that are beneficial
<ul spacing="compact"> or necessary to achieve the desired use-case benefits of the ACP (see <xref tar
<li><xref target="diagnostics" format="default"/> describes recommended get="usage" format="default" sectionFormat="of" derivedContent="Section 3"/>).</
operator diagnostics capabilities of ACP nodes.</li> t>
<li><xref target="registrar-considerations" format="default"/> describes <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9-2
high level how an ACP registrar needs to work, what its configuration parameter ">
s are and specific issues impacting the choices of deployment design due to rene <li pn="section-9-2.1">
wal and revocation issues. It describes a model where ACP Registrars have their <xref target="diagnostics" format="default" sectionFormat="of" derived
own sub-CA to provide the most distributed deployment option for ACP Registrars, Content="Section 9.1"/> describes the recommended capabilities of operator diagn
and it describes considerations for centralized policy control of ACP Registrar ostics of ACP nodes.</li>
operations.</li> <li pn="section-9-2.2">
<li><xref target="enabling-acp" format="default"/> describes suggested A <xref target="registrar-considerations" format="default" sectionFormat
CP node behavior and operational interfaces (configuration options) to manage th ="of" derivedContent="Section 9.2"/> describes at a high level how an ACP regist
e ACP in so-called greenfield devices (previously unconfigured) and brownfield d rar needs to work, what its configuration parameters are, and specific issues im
evices (preconfigured).</li> pacting the choices of deployment design due to renewal and revocation issues. I
t describes a model where ACP registrars have their own sub-CA to provide the mo
st distributed deployment option for ACP registrars, and it describes considerat
ions for centralized policy control of ACP registrar operations.</li>
<li pn="section-9-2.3">
<xref target="enabling-acp" format="default" sectionFormat="of" derive
dContent="Section 9.3"/> describes suggested ACP node behavior and operational i
nterfaces (configuration options) to manage the ACP in so-called greenfield devi
ces (previously unconfigured) and brownfield devices (preconfigured).</li>
</ul> </ul>
<t>The recommendations and suggestions of this chapter were derived from o <t indent="0" pn="section-9-3">The recommendations and suggestions of this
perational experience gained with a commercially available pre-standard ACP impl chapter were derived from operational experience gained with a commercially ava
ementation.</t> ilable pre-standard ACP implementation.</t>
<section anchor="diagnostics" numbered="true" toc="default"> <section anchor="diagnostics" numbered="true" toc="include" removeInRFC="f
<name>ACP (and BRSKI) Diagnostics</name> alse" pn="section-9.1">
<t>Even though ACP and ANI in general are taking out many manual configu <name slugifiedName="name-acp-and-brski-diagnostics">ACP (and BRSKI) Dia
ration mistakes gnostics</name>
<t indent="0" pn="section-9.1-1">Even though ACP and ANI in general are
removing many manual configuration mistakes
through their automation, it is important to provide good diagnostics for them.< /t> through their automation, it is important to provide good diagnostics for them.< /t>
<t>Basic standardized diagnostics would require support for (yang) model <t indent="0" pn="section-9.1-2">Basic standardized diagnostics would re
s representing the quire support for (YANG) models representing the
complete (auto-)configuration and operational state of all components: GRASP, complete (auto)configuration and operational state of all components: GRASP,
ACP and the infrastructure used by them: TLS/DTLS, IPsec, certificates, TA, time ACP, and the infrastructure used by them, such as TLS/DTLS, IPsec, certificates,
, TA, time,
VRF and so on. While necessary, this is not sufficient:</t> VRF, and so on. While necessary, this is not sufficient.</t>
<t>Simply representing the state of components does not allow operators <t indent="0" pn="section-9.1-3">Simply representing the state of compon
to quickly take ents does not allow operators to quickly take
action - unless they do understand how to interpret the data, and that can mean action -- unless they understand how to interpret the data, which can mean a
a
requirement for deep understanding of all components and how they interact in th e ACP/ANI.</t> requirement for deep understanding of all components and how they interact in th e ACP/ANI.</t>
<t>Diagnostic supports should help to quickly answer the questions opera <t indent="0" pn="section-9.1-4">Diagnostic supports should help to quic
tors kly answer the questions operators
are expected to ask, such as "is the ACP working correctly?", or "why is there n are expected to ask, such as "Is the ACP working correctly?" or "Why is there no
o
ACP connection to a known neighboring node?"</t> ACP connection to a known neighboring node?"</t>
<t>In current network management approaches, the logic to answer these <t indent="0" pn="section-9.1-5">In current network management approache
questions is most often built as centralized diagnostics software that leverages s, the logic to answer these
questions is most often built into centralized diagnostics software that leverag
es
the above mentioned data models. While this approach is feasible for components the above mentioned data models. While this approach is feasible for components
utilizing the ANI, it is not sufficient to diagnose the ANI itself:</t> utilizing the ANI, it is not sufficient to diagnose the ANI itself:</t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
<li>Developing the logic to identify common issues requires operationa .1-6">
l experience <li pn="section-9.1-6.1">Developing the logic to identify common issue
s requires operational experience
with the components of the ANI. Letting each management system define its with the components of the ANI. Letting each management system define its
own analysis is inefficient.</li> own analysis is inefficient.</li>
<li>When the ANI is not operating correctly, it may not be possible to <li pn="section-9.1-6.2">When the ANI is not operating correctly, it m
run diagnostics ay not be possible to run diagnostics
from remote because of missing connectivity. The ANI should therefore have diag remotely because of missing connectivity. The ANI should therefore have diagnos
nostic tic
capabilities available locally on the nodes themselves.</li> capabilities available locally on the nodes themselves.</li>
<li>Certain operations are difficult or impossible to monitor in real- time, such as <li pn="section-9.1-6.3">Certain operations are difficult or impossibl e to monitor in real time, such as
initial bootstrap issues in a network location where no capabilities exist to at tach initial bootstrap issues in a network location where no capabilities exist to at tach
local diagnostics. Therefore, it is important to also define means of capturing local diagnostics. Therefore, it is important to also define how to capture (lo
(logging) g)
diagnostics locally for later retrieval. Ideally, these captures are also non-v diagnostics locally for later retrieval. Ideally, these captures are also nonvo
olatile so latile so
that they can survive extended power-off conditions - for example when a device that they can survive extended power-off conditions, for example, when a device
that fails to be brought up zero-touch is being sent back for diagnostics at a that fails to be brought up zero-touch is sent for diagnostics at a
more appropriate location.</li> more appropriate location.</li>
</ul> </ul>
<t>The simplest form of diagnostics answering questions such as the abov e <t indent="0" pn="section-9.1-7">The simplest form of diagnostics for an swering questions such as the above
is to represent the relevant information sequentially in dependency order, is to represent the relevant information sequentially in dependency order,
so that the first non-expected/non-operational item is the most likely root so that the first unexpected and/or nonoperational item is the most likely root
cause. Or just log/highlight that item. For example:</t> cause, or just log and/or highlight that item. For example:</t>
<t>Q: Is ACP operational to accept neighbor connections: <t indent="0" pn="section-9.1-8">Question: Is the ACP operational to acc
ept neighbor connections?
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
<li>Check if any potentially necessary configuration to make ACP/ANI o .1-9">
perational are correct (see <xref target="enabling-acp" format="default"/> for a <li pn="section-9.1-9.1">Check if the necessary configurations to make
discussion of such commands).</li> ACP/ANI operational are correct (see <xref target="enabling-acp" format="defaul
<li>Does the system time look reasonable, or could it be the default s t" sectionFormat="of" derivedContent="Section 9.3"/> for a discussion of such co
ystem time after clock chip battery failure (certificate checks depend on reason mmands).</li>
able notion of time)?.</li> <li pn="section-9.1-9.2">Does the system time look reasonable, or coul
<li>Does the node have keying material - domain certificate, TA certif d it be the default system time after battery failure of the clock chip? Certifi
icates, ...></li> cate checks depend on reasonable notion of time.</li>
<li>If no keying material and ANI is supported/enabled, <li pn="section-9.1-9.3">Does the node have keying material, such as d
omain certificate, TA certificates, etc.?</li>
<li pn="section-9.1-9.4">If there is no keying material and the ANI is
supported/enabled,
check the state of BRSKI (not detailed in this example).</li> check the state of BRSKI (not detailed in this example).</li>
<li> <li pn="section-9.1-9.5">
<t>Check the validity of the domain certificate: <t indent="0" pn="section-9.1-9.5.1">Check the validity of the domai
</t> n certificate:
<ul spacing="compact"> </t>
<li>Does the certificate validate against the TA?</li> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>Has it been revoked?</li> on-9.1-9.5.2">
<li>Was the last scheduled attempt to retrieve a CRL successful (e <li pn="section-9.1-9.5.2.1">Does the certificate validate against
.g., do we know that our CRL information is up to date).</li> the TA?</li>
<li>Is the certificate valid: validity start time in the past, exp <li pn="section-9.1-9.5.2.2">Has it been revoked?</li>
iration time in the future?</li> <li pn="section-9.1-9.5.2.3">Was the last scheduled attempt to ret
<li>Does the certificate have a correctly formatted acp-node-name rieve a CRL successful? (e.g., do we know that our CRL information is up to date
field?</li> ?)</li>
<li pn="section-9.1-9.5.2.4">Is the certificate valid? The validit
y start time is in the past, and the expiration time is in the future?</li>
<li pn="section-9.1-9.5.2.5">Does the certificate have a correctly
formatted acp-node-name field?</li>
</ul> </ul>
</li> </li>
<li>Was the ACP VRF successfully created?</li> <li pn="section-9.1-9.6">Was the ACP VRF successfully created?</li>
<li>Is ACP enabled on one or more interfaces that are up and running?< <li pn="section-9.1-9.7">Is ACP enabled on one or more interfaces that
/li> are up and running?</li>
</ul> </ul>
<t>If all this looks good, the ACP should be running locally "fine" - bu <t indent="0" pn="section-9.1-10">If all of the above looks good, the AC
t we did not check any ACP neighbor relationships.</t> P should be running "fine" locally, but we did not check any ACP neighbor relati
<t>Question: why does the node not create a working ACP connection to a onships.</t>
neighbor on an interface? <t indent="0" pn="section-9.1-11">Question: Why does the node not create
a working ACP connection to a neighbor on an interface?
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
<li>Is the interface physically up? Does it have an IPv6 link-local ad .1-12">
dress?</li> <li pn="section-9.1-12.1">Is the interface physically up? Does it have
<li>Is it enabled for ACP?</li> an IPv6 link-local address?</li>
<li>Do we successfully send DULL GRASP messages to the interface (link <li pn="section-9.1-12.2">Is it enabled for ACP?</li>
layer errors)?</li> <li pn="section-9.1-12.3">Do we successfully send DULL GRASP messages
<li>Do we receive DULL GRASP messages on the interface? If not, some i to the interface? (Are there link-layer errors?)</li>
ntervening L2 equipment performing bad MLD snooping could have caused problems. <li pn="section-9.1-12.4">Do we receive DULL GRASP messages on the int
Provide e.g., diagnostics of the MLD querier IPv6 and MAC address.</li> erface? If not, some intervening L2 equipment performing bad MLD snooping could
<li>Do we see the ACP objective in any DULL GRASP message from that in have caused problems. Provide, e.g., diagnostics of the MLD querier IPv6 and MA
terface? Diagnose the supported secure channel methods.</li> C address.</li>
<li>Do we know the MAC address of the neighbor with the ACP objective? <li pn="section-9.1-12.5">Do we see the ACP objective in any DULL GRAS
If not, diagnose SLAAC/ND state.</li> P message from that interface? Diagnose the supported secure channel methods.</l
<li>When did we last attempt to build an ACP secure channel to the nei i>
ghbor?</li> <li pn="section-9.1-12.6">Do we know the MAC address of the neighbor w
<li> ith the ACP objective? If not, diagnose SLAAC/ND state.</li>
<t>If it failed, why: <li pn="section-9.1-12.7">When did we last attempt to build an ACP sec
</t> ure channel to the neighbor?</li>
<ul spacing="compact"> <li pn="section-9.1-12.8">
<li>Did the neighbor close the connection on us or did we close th <t indent="0" pn="section-9.1-12.8.1">If it failed:
e connection on it because the domain certificate membership failed?</li>
<li>If the neighbor closed the connection on us, provide any error
diagnostics from the secure channel protocol.</li>
<li>
<t>If we failed the attempt, display our local reason:
</t>
<ul spacing="compact">
<li>There was no common secure channel protocol supported by t
he two neighbors (this could not happen on nodes supporting this specification b
ecause it mandates common support for IPsec).</li>
<li>
<t>The ACP certificate membership check (<xref target="certc
heck" format="default"/>) fails:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
<li>The neighbor's certificate is not signed directly or i on-9.1-12.8.2">
ndirectly by one of the nodes TA. Provide diagnostics which TA it has (can iden <li pn="section-9.1-12.8.2.1">Did the neighbor close the connectio
tify whom the device belongs to).</li> n on us, or did we close the connection on it because the domain certificate mem
<li>The neighbor's certificate does not have the same doma bership failed?</li>
in (or no domain at all). Diagnose domain-name and potentially other cert info. <li pn="section-9.1-12.8.2.2">If the neighbor closed the connectio
</li> n on us, provide any error diagnostics from the secure channel protocol.</li>
<li>The neighbor's certificate has been revoked or could n <li pn="section-9.1-12.8.2.3">
ot be authenticated by OCSP. </li> <t indent="0" pn="section-9.1-12.8.2.3.1">If we failed the attem
<li>The neighbor's certificate has expired - or is not yet pt, display our local reason:
valid.</li> </t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="s
ection-9.1-12.8.2.3.2">
<li pn="section-9.1-12.8.2.3.2.1">There was no common secure c
hannel protocol supported by the two neighbors (this could not happen on nodes s
upporting this specification because it mandates common support for IPsec).</li>
<li pn="section-9.1-12.8.2.3.2.2">
<t indent="0" pn="section-9.1-12.8.2.3.2.2.1">Did the ACP ce
rtificate membership check (<xref target="certcheck" format="default" sectionFor
mat="of" derivedContent="Section 6.2.3"/>) fail?
</t>
<ul spacing="normal" bare="false" empty="false" indent="3" p
n="section-9.1-12.8.2.3.2.2.2">
<li pn="section-9.1-12.8.2.3.2.2.2.1">The neighbor's certi
ficate is not signed directly or indirectly by one of the node's TA. Provide di
agnostics which TA it has (can identify whom the device belongs to).</li>
<li pn="section-9.1-12.8.2.3.2.2.2.2">The neighbor's certi
ficate does not have the same domain (or no domain at all). Diagnose acp-domain
-name and potentially other cert info.</li>
<li pn="section-9.1-12.8.2.3.2.2.2.3">The neighbor's certi
ficate has been revoked or could not be authenticated by OCSP. </li>
<li pn="section-9.1-12.8.2.3.2.2.2.4">The neighbor's certi
ficate has expired, or it is not yet valid.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</li> </li>
<li>Any other connection issues in e.g., IKEv2 / IPsec, DTLS?.</li > <li pn="section-9.1-12.8.2.4">Are there any other connection issue s, e.g., IKEv2/IPsec, DTLS?</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t>Question: Is the ACP operating correctly across its secure channels? <t indent="0" pn="section-9.1-13">Question: Is the ACP operating correct ly across its secure channels?
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
<li>Are there one or more active ACP neighbors with secure channels?</ .1-14">
li> <li pn="section-9.1-14.1">Are there one or more active ACP neighbors w
<li>Is the RPL routing protocol for the ACP running?</li> ith secure channels?</li>
<li>Is there a default route to the root in the ACP routing table?</li <li pn="section-9.1-14.2">Is RPL for the ACP running?</li>
> <li pn="section-9.1-14.3">Is there a default route to the root in the
<li>Is there for each direct ACP neighbor not reachable over the ACP v ACP routing table?</li>
irtual interface to the root a route in the ACP routing table?</li> <li pn="section-9.1-14.4">Is there, for each direct ACP neighbor not r
<li>Is ACP GRASP running?</li> eachable over the ACP virtual interface to the root, a route in the ACP routing
<li>Is at least one SRV.est objective cached (to support certificate r table?</li>
enewal)?</li> <li pn="section-9.1-14.5">Is ACP GRASP running?</li>
<li>Is there at least one BRSKI registrar objective cached (in case BR <li pn="section-9.1-14.6">Is at least one "SRV.est" objective cached (
SKI is supported)</li> to support certificate renewal)?</li>
<li>Is BRSKI proxy operating normally on all interfaces where ACP is o <li pn="section-9.1-14.7">Is there at least one BRSKI registrar object
perating?</li> ive cached? (If BRSKI is supported.)</li>
<li>...</li> <li pn="section-9.1-14.8">Is the BRSKI proxy operating normally on all
interfaces where ACP is operating?</li>
</ul> </ul>
<t>These lists are not necessarily complete, but illustrate the principl <t indent="0" pn="section-9.1-15">These lists are not necessarily comple
e and show that there are variety of issues ranging from normal operational caus te, but they illustrate the principle and show that there are variety of issues
es (a neighbor in another ACP domain) over problems in the credentials managemen ranging from normal operational causes (a neighbor in another ACP domain) to pro
t (certificate lifetimes), explicit security actions (revocation) or unexpected blems in the credentials management (certificate lifetimes), to explicit securit
connectivity issues (intervening L2 equipment).</t> y actions (revocation) or unexpected connectivity issues (intervening L2 equipme
<t>The items so far are illustrating how the ANI operations can nt).</t>
<t indent="0" pn="section-9.1-16">The items so far illustrate how the AN
I operations can
be diagnosed with passive observation of the operational state be diagnosed with passive observation of the operational state
of its components including historic/cached/counted events. This is of its components including historic, cached, and/or counted events. This is
not necessary sufficient to provide good enough diagnostics overall:</t> not necessarily sufficient to provide good enough diagnostics overall.</t>
<t>The components of ACP and BRSKI are designed with security in mind <t indent="0" pn="section-9.1-17">The components of ACP and BRSKI are de
signed with security in mind,
but they do not attempt to provide diagnostics for building the but they do not attempt to provide diagnostics for building the
network itself. Consider two examples: network itself. Consider two examples:
</t> </t>
<ol type="1" spacing="compact"> <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-9.
<li>BRSKI does not allow for a neighboring 1-18">
device to identify the pledges IDevID certificate. Only the selected <li pn="section-9.1-18.1" derivedCounter="1.">BRSKI does not allow for
a neighboring
device to identify the pledge's IDevID certificate. Only the selected
BRSKI registrar can do this, but it may be difficult to disseminate BRSKI registrar can do this, but it may be difficult to disseminate
information about undesired pledges from those BRSKI registrars to locations /nodes information from those BRSKI registrars about undesired pledges to locations and/or nodes
where information about those pledges is desired.</li> where information about those pledges is desired.</li>
<li>LLDP disseminates information about nodes to their immediate neigh <li pn="section-9.1-18.2" derivedCounter="2.">LLDP disseminates inform
bors, ation about nodes,
such as node model/type/software and interface name/number of the such as node model, type, and/or software and interface name and/or number o
connection. This information is often helpful or even necessary f the
in network diagnostics. It can equally be considered to be too insecure connection, to their immediate neighbors. This information is often helpful
or even necessary
in network diagnostics. It can equally be considered too insecure
to make this information available unprotected to all possible neighbors.</l i> to make this information available unprotected to all possible neighbors.</l i>
</ol> </ol>
<t>An "interested adjacent party" can always determine the IDevID certif icate of a BRSKI pledge <t indent="0" pn="section-9.1-19">An "interested adjacent party" can alw ays determine the IDevID certificate of a BRSKI pledge
by behaving like a BRSKI proxy/registrar. Therefore, the IDevID certificate of a BRSKI pledge by behaving like a BRSKI proxy/registrar. Therefore, the IDevID certificate of a BRSKI pledge
is not meant to be protected - it just has to be queried and is not is not meant to be protected -- it just has to be queried and is not
signaled unsolicited (as it would be in LLDP) so that other observers signaled unsolicited (as it would be in LLDP) so that other observers
on the same subnet can determine who is an "interested adjacent party".</t> on the same subnet can determine who is an "interested adjacent party".</t>
<section anchor="ta-troubleshoot" numbered="true" toc="default"> <section anchor="ta-troubleshoot" numbered="true" toc="include" removeIn
<name>Secure Channel Peer diagnostics</name> RFC="false" pn="section-9.1.1">
<t>When using mutual certificate authentication, the TA certificate is <name slugifiedName="name-secure-channel-peer-diagnos">Secure Channel
not required Peer Diagnostics</name>
<t indent="0" pn="section-9.1.1-1">When using mutual certificate authe
ntication, the TA certificate is not required
to be signaled explicitly because its hash is sufficient for certificate to be signaled explicitly because its hash is sufficient for certificate
chain validation. In the case of ACP secure channel setup this leads chain validation. In the case of ACP secure channel setup, this leads
to limited diagnostics when authentication fails because of TA mismatch. to limited diagnostics when authentication fails because of TA mismatch.
For this reason, <xref target="common-requirements" format="default"/> recommend s to also include the TA certificate in the For this reason, <xref target="common-requirements" format="default" sectionForm at="of" derivedContent="Section 6.8.2"/> recommends also including the TA certif icate in the
secure channel signaling. This should be possible secure channel signaling. This should be possible
to do without protocol modifications in the security association protocols used to do without modifying the security association protocols used by the
by the ACP. For example, while <xref target="RFC7296" format="default" sectionFormat="o
ACP. For example, while <xref target="RFC7296" format="default"/> does not menti f" derivedContent="RFC7296"/> does not mention this, it
on this, it
also does not prohibit it.</t> also does not prohibit it.</t>
<t>One common deployment use case where the diagnostic through the sig <t indent="0" pn="section-9.1.1-2">One common use case where diagnosti
naled cs through the signaled
TA of a candidate peer is very helpful are multi-tenant environments such as TA of a candidate peer are very helpful is the multi-tenant environment, such as
office buildings, where different tenants run their own networks and ACPs. an office building, where different tenants run their own networks and ACPs.
Each tenant is given supposedly disjoint L2 connectivity through the building in frastructure. Each tenant is given supposedly disjoint L2 connectivity through the building in frastructure.
In these environments there are various common errors through which a device may In these environments, there are various common errors through which a device ma
receive L2 connectivity into the wrong tenants network.</t> y
<t>While the ACP itself is not impact by this, the Data-Plane to be bu receive L2 connectivity into the wrong tenant's network.</t>
ilt later may be <t indent="0" pn="section-9.1.1-3">While the ACP itself is not impacte
d by this, the data plane to be built later may be
impacted. Therefore, it is important to be able to diagnose such undesirable impacted. Therefore, it is important to be able to diagnose such undesirable
connectivity from the ACP so that any autonomic or non-autonomic mechanisms connectivity from the ACP so that any autonomic or non-autonomic mechanisms
to configure the Data-Plane can accordingly treat such interfaces. to configure the data plane can treat such interfaces accordingly.
The information in the TA of the peer can then ease The information in the TA of the peer can then ease
troubleshooting of such issues.</t> troubleshooting of such issues.</t>
<t>Another example case is the intended or accidental re-activation of <t indent="0" pn="section-9.1.1-4">Another use case is the intended or
equipment accidental reactivation of equipment,
whose TA certificate has long expired, such as redundant gear taken from storage such as redundant gear taken from storage, whose TA certificate has long expired
after years.</t> .</t>
<t>A third example case is when in a mergers &amp; acquisition case AC <t indent="0" pn="section-9.1.1-5">A third use case is when, in a merg
P nodes have not er and acquisition case, ACP nodes have not
been correctly provisioned with the mutual TA of previously disjoint ACP. This been correctly provisioned with the mutual TA of a previously disjoint ACP. This
is assuming that the ACP domain names where already aligned so that the ACP assumes that the ACP domain names were already aligned so that the ACP
domain membership check is only failing on the TA.</t> domain membership check is only failing on the TA.</t>
<t>A fourth example case is when multiple registrars where set up for <t indent="0" pn="section-9.1.1-6">A fourth use case is when multiple
the same registrars are set up for the same
ACP but without correctly setting up the same TA. For example, when registrars ACP but are not correctly set up with the same TA. For example, when registrars
support to also be CA themselves but are misconfigured to become TA instead support also being CAs themselves but are misconfigured to become TAs instead
of intermediate CA.</t> of intermediate CAs.</t>
</section> </section>
</section> </section>
<section anchor="registrar-considerations" numbered="true" toc="default"> <section anchor="registrar-considerations" numbered="true" toc="include" r
<name>ACP Registrars</name> emoveInRFC="false" pn="section-9.2">
<t>As described in <xref target="acp-registrars" format="default"/>, the <name slugifiedName="name-acp-registrars-2">ACP Registrars</name>
ACP addressing <t indent="0" pn="section-9.2-1">As described in <xref target="acp-regis
mechanism is designed to enable lightweight, distributed and uncoordinated trars" format="default" sectionFormat="of" derivedContent="Section 6.11.7"/>, th
ACP registrars that are providing ACP address prefixes to candidate ACP e ACP addressing
mechanism is designed to enable lightweight, distributed, and uncoordinated
ACP registrars that provide ACP address prefixes to candidate ACP
nodes by enrolling them with an ACP certificate into an ACP domain via nodes by enrolling them with an ACP certificate into an ACP domain via
any appropriate mechanism/protocol, automated or not.</t> any appropriate mechanism and/or protocol, automated or not.</t>
<t>This section discusses informatively more details and options for ACP <t indent="0" pn="section-9.2-2">This section discusses informatively mo
registrars.</t> re details and options for ACP registrars.</t>
<section anchor="reg-interact" numbered="true" toc="default"> <section anchor="reg-interact" numbered="true" toc="include" removeInRFC
<name>Registrar interactions</name> ="false" pn="section-9.2.1">
<t>This section summarizes and discusses the interactions with other e <name slugifiedName="name-registrar-interactions">Registrar Interactio
ntities required ns</name>
<t indent="0" pn="section-9.2.1-1">This section summarizes and discuss
es the interactions with other entities required
by an ACP registrar.</t> by an ACP registrar.</t>
<t>In a simple instance of an ACP network, no central NOC component be side <t indent="0" pn="section-9.2.1-2">In a simple instance of an ACP netw ork, no central NOC component beside
a TA is required. Typically, this is a root CA. One or more uncoordinated actin g a TA is required. Typically, this is a root CA. One or more uncoordinated actin g
ACP registrar can be set up, performing the following interactions:</t> ACP registrars can be set up, performing the following interactions.</t>
<t>To orchestrate enrolling a candidate ACP node autonomically, <t indent="0" pn="section-9.2.1-3">To orchestrate enrolling a candidat
the ACP registrar can rely on the ACP and use Proxies to reach the candidate ACP e ACP node autonomically,
node, the ACP registrar can rely on the ACP and use proxies to reach the candidate ACP
therefore allowing minimum pre-existing (auto-)configured network services node,
therefore allowing minimal, preexisting (auto)configured network services
on the candidate ACP node. BRSKI defines the BRSKI proxy, a design that can be on the candidate ACP node. BRSKI defines the BRSKI proxy, a design that can be
adopted for various protocols that Pledges/candidate ACP nodes could want to use adopted for various protocols that pledges and/or candidate ACP nodes could want
, to use,
for example BRSKI over CoAP (Constrained Application Protocol), or proxying of for example, BRSKI over CoAP (Constrained Application Protocol) or the proxying
of
NETCONF.</t> NETCONF.</t>
<t>To reach a TA that has no ACP connectivity, the ACP registrar would <t indent="0" pn="section-9.2.1-4">To reach a TA that has no ACP conne
use ctivity, the ACP registrar uses
the Data-Plane. ACP and Data-Plane in an ACP registrar could (and by default the data plane. The ACP and data plane in an ACP registrar could (and by default
should be) completely isolated from each other at the network level. should) be completely isolated from each other at the network level.
Only applications such as the ACP registrar would need the ability for Only applications such as the ACP registrar would need the ability for
their transport stacks to access both.</t> their transport stacks to access both.</t>
<t>In non-autonomic enrollment options, the Data-Plane <t indent="0" pn="section-9.2.1-5">In non-autonomic enrollment options
between a ACP registrar and the candidate ACP node needs to be configured , the data plane
between an ACP registrar and the candidate ACP node needs to be configured
first. This includes the ACP registrar and the candidate ACP node. first. This includes the ACP registrar and the candidate ACP node.
Then any appropriate set of protocols can be used between ACP registrar and Then any appropriate set of protocols can be used between the ACP registrar and
candidate ACP node to discover the other side, and then connect the candidate ACP node to discover the other side, and then connect
and enroll (configure) the candidate ACP node with an ACP certificate. and enroll (configure) the candidate ACP node with an ACP certificate.
NETCONF ZeroTouch (<xref target="RFC8572" format="default"/>) For example, NETCONF Zero Touch ("<xref target="RFC8572" format="title" sectionF
is an example protocol that could be used for this. BRSKI using optional ormat="of" derivedContent="Secure Zero Touch Provisioning (SZTP)"/>" <xref targe
t="RFC8572" format="default" sectionFormat="of" derivedContent="RFC8572"/>)
is a protocol that could be used for this. BRSKI using optional
discovery mechanisms is equally a possibility for candidate ACP nodes discovery mechanisms is equally a possibility for candidate ACP nodes
attempting to be enrolled across non-ACP networks, such as the Internet.</t> attempting to be enrolled across non-ACP networks, such as the Internet.</t>
<t>When candidate ACP nodes have secure bootstrap, such as BRSKI Pledg <t indent="0" pn="section-9.2.1-6">When a candidate ACP node, such as
es, a BRSKI pledge, has secure bootstrap,
they will not trust to be configured/enrolled across the network, unless it will not trust being configured and/or enrolled across the network unless
being presented with a voucher (see <xref target="RFC8366" format="default"/>) a it is presented with a voucher (see "<xref target="RFC8366" format="title" secti
uthorizing onFormat="of" derivedContent="A Voucher Artifact for Bootstrapping Protocols"/>"
<xref target="RFC8366" format="default" sectionFormat="of" derivedContent="RFC8
366"/>) authorizing
the network to take possession of the node. An ACP registrar will then need a the network to take possession of the node. An ACP registrar will then need a
method to retrieve such a voucher, either offline, or online from a MASA method to retrieve such a voucher, either offline or online from a MASA
(Manufacturer Authorized Signing Authority). BRSKI and NETCONF (Manufacturer Authorized Signing Authority). BRSKI and NETCONF
ZeroTouch are two protocols that include capabilities to present the voucher Zero Touch are two protocols that include capabilities to present the voucher
to the candidate ACP node.</t> to the candidate ACP node.</t>
<t>An ACP registrar could operate EST for ACP certificate renewal and/ <t indent="0" pn="section-9.2.1-7">An ACP registrar could operate EST
or for ACP certificate renewal and/or
act as a CRL Distribution point. A node performing these act as a CRL Distribution Point. A node performing these
services does not need to support performing (initial) enrollment, but services does not need to support performing (initial) enrollment, but
it does require the same above described connectivity as an ACP it does require the same above described connectivity as an ACP
registrar: via the ACP to ACP nodes and via the Data-Plane to the TA registrar: via the ACP to the ACP nodes and via the data plane to the TA
and other sources of CRL information.</t> and other sources of CRL information.</t>
</section> </section>
<section anchor="reg-config" numbered="true" toc="default"> <section anchor="reg-config" numbered="true" toc="include" removeInRFC="
<name>Registrar Parameter</name> false" pn="section-9.2.2">
<t>The interactions of an ACP registrar outlined <xref target="acp-reg <name slugifiedName="name-registrar-parameters">Registrar Parameters</
istrars" format="default"/> and name>
<xref target="reg-interact" format="default"/> above depend on the following par <t indent="0" pn="section-9.2.2-1">The interactions of an ACP registra
ameters: r outlined in <xref target="acp-registrars" format="default" sectionFormat="of"
derivedContent="Section 6.11.7"/> and
<xref target="reg-interact" format="default" sectionFormat="of" derivedContent="
Section 9.2.1"/> depend on the following parameters:
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>A URL to the TA and credentials so that the ACP -9.2.2-2">
<li pn="section-9.2.2-2.1">A URL to the TA and credentials so that t
he ACP
registrar can let the TA sign candidate ACP node certificates.</li> registrar can let the TA sign candidate ACP node certificates.</li>
<li>The ACP domain-name.</li> <li pn="section-9.2.2-2.2">The ACP domain name.</li>
<li>The Registrar-ID to use. This could default to a MAC address of <li pn="section-9.2.2-2.3">The Registrar-ID to use. This could defau
the ACP registrar.</li> lt to a MAC address of the ACP registrar.</li>
<li pn="section-9.2.2-2.4">For recovery, the next usable Node-IDs fo
<li>For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub r the Zone Addressing Sub-Scheme (Zone-ID 0)
-addressing scheme, and for the Vlong Addressing Sub-Scheme (/112 and /120). These IDs would on
for Vlong /112 and for Vlong /120 sub-addressing scheme. These IDs would on ly need
ly need
to be provisioned after recovering from a crash. Some other mechanism would to be provisioned after recovering from a crash. Some other mechanism would
be required to remember these IDs in a backup location or to recover them be required to remember these IDs in a backup location or to recover them
from the set of currently known ACP nodes.</li> from the set of currently known ACP nodes.</li>
<li pn="section-9.2.2-2.5">Policies on whether the candidate ACP nod
<li>Policies if candidate ACP nodes should receive a domain certific es should receive a domain certificate or not,
ate or not, for example, based on the device's IDevID certificate as in BRSKI. The ACP
for example based on the devices IDevID certificate as in BRSKI. The ACP re registrar may
gistrar may have whitelist or blacklist based on a device's "serialNumber" attribute <xref t
a whitelist or blacklist of devices <xref target="X.520" format="default"/> arget="X.520" format="default" sectionFormat="of" derivedContent="X.520"/> in th
"serialNumbers" attribute in the subject field distinguished name encoding fro e subject field distinguished name encoding of its IDevID certificate.</li>
m their IDevID certificate.</li> <li pn="section-9.2.2-2.6">Policies on what type of address prefix t
o assign to a candidate ACP device,
<li>Policies what type of address prefix to assign to a candidate AC likely based on the same information.</li>
P devices, <li pn="section-9.2.2-2.7">For BRSKI or other mechanisms using vouch
based on likely the same information.</li> ers: parameters to determine
<li>For BRSKI or other mechanisms using vouchers: Parameters to dete how to retrieve vouchers for specific types of secure bootstrap candidate
rmine
how to retrieve vouchers for specific type of secure bootstrap candidate
ACP nodes (such as MASA URLs), unless this information is automatically ACP nodes (such as MASA URLs), unless this information is automatically
learned such as from the IDevID certificate of candidate ACP nodes (as defi ned in BRSKI).</li> learned, such as from the IDevID certificate of candidate ACP nodes (as def ined in BRSKI).</li>
</ul> </ul>
</section> </section>
<section anchor="cert-renewal" numbered="true" toc="default"> <section anchor="cert-renewal" numbered="true" toc="include" removeInRFC
<name>Certificate renewal and limitations</name> ="false" pn="section-9.2.3">
<t>When an ACP node renews/rekeys its certificate, it may end up doing <name slugifiedName="name-certificate-renewal-and-lim">Certificate Ren
so via ewal and Limitations</name>
<t indent="0" pn="section-9.2.3-1">When an ACP node renews and/or reke
ys its certificate, it may end up doing so via
a different registrar (e.g., EST server) than the one it originally received a different registrar (e.g., EST server) than the one it originally received
its ACP certificate from, for example because that original ACP registrar its ACP certificate from, for example, because that original ACP registrar
is gone. The ACP registrar through which the renewal/rekeying is performed is gone. The ACP registrar through which the renewal/rekeying is performed
would by default trust the acp-node-name from the ACP nodes current would by default trust the acp-node-name from the ACP node's current
ACP certificate and maintain this information so that the ACP node ACP certificate and maintain this information so that the ACP node
maintains its ACP address prefix. In EST renewal/rekeying, the ACP nodes current maintains its ACP address prefix. In EST renewal/rekeying, the ACP node's curren t
ACP certificate is signaled during the TLS handshake.</t> ACP certificate is signaled during the TLS handshake.</t>
<t>This simple scenario has two limitations: <t indent="0" pn="section-9.2.3-2">This simple scenario has two limita tions:
</t> </t>
<ol type="1" spacing="compact"> <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-
<li>The ACP registrars cannot directly assign certificates to nodes 9.2.3-3">
and <li pn="section-9.2.3-3.1" derivedCounter="1.">The ACP registrar can
not directly assign certificates to nodes and
therefore needs an "online" connection to the TA.</li> therefore needs an "online" connection to the TA.</li>
<li>Recovery from a compromised ACP registrar is difficult. <li pn="section-9.2.3-3.2" derivedCounter="2.">Recovery from a compr
When an ACP registrar is compromised, it can insert for example omised ACP registrar is difficult.
a conflicting acp-node-name and create thereby an attack When an ACP registrar is compromised, it can insert, for example,
a conflicting acp-node-name and thereby create an attack
against other ACP nodes through the ACP routing protocol.</li> against other ACP nodes through the ACP routing protocol.</li>
</ol> </ol>
<t>Even when such a malicious ACP registrar is detected, resolving the <t indent="0" pn="section-9.2.3-4">Even when such a malicious ACP regi strar is detected, resolving the
problem may be difficult because it would require identifying all the problem may be difficult because it would require identifying all the
wrong ACP certificates assigned via the ACP registrar after it wrong ACP certificates assigned via the ACP registrar after it
was compromised. And without additional centralized tracking of assigned was compromised. Without additional centralized tracking of assigned
certificates there is no way to do this.</t> certificates, there is no way to do this.</t>
</section> </section>
<section anchor="sub-ca" numbered="true" toc="default"> <section anchor="sub-ca" numbered="true" toc="include" removeInRFC="fals
<name>ACP Registrars with sub-CA</name> e" pn="section-9.2.4">
<t>In situations, where either of the above two limitations are an iss <name slugifiedName="name-acp-registrars-with-sub-ca">ACP Registrars w
ue, ith Sub-CA</name>
<t indent="0" pn="section-9.2.4-1">In situations where either of the a
bove two limitations are an issue,
ACP registrars could also be sub-CAs. This removes the need for ACP registrars could also be sub-CAs. This removes the need for
connectivity to a TA whenever an ACP node is enrolled, and reduces connectivity to a TA whenever an ACP node is enrolled, and it reduces
the need for connectivity of such an ACP registrar to a TA to only the need for connectivity of such an ACP registrar to a TA to only
those times when it needs to renew its own certificate. The ACP registrar those times when it needs to renew its own certificate. The ACP registrar
would also now use its own (sub-CA) certificate to enroll and sign the would also now use its own (sub-CA) certificate to enroll and sign the
ACP nodes certificates, and therefore it is only necessary to revoke ACP node's certificates, and therefore it is only necessary to revoke
a compromised ACP registrars sub-CA certificate. Alternatively one can a compromised ACP registrar's sub-CA certificate. Alternatively, one can
let it expire and not renew it, when the certificate of the sub-CA is appropriat let it expire and not renew it when the certificate of the sub-CA is appropriate
ely ly
short-lived.</t> short-lived.</t>
<t>As the ACP domain membership check verifies a <t indent="0" pn="section-9.2.4-2">As the ACP domain membership check verifies a
peer ACP node's ACP certificate trust chain, it will also verify peer ACP node's ACP certificate trust chain, it will also verify
the signing certificate which is the compromised/revoked sub-CA certificate. the signing certificate, which is the compromised and/or revoked sub-CA certific
Therefore, ACP domain membership for an ACP node enrolled from a ate.
Therefore, ACP domain membership for an ACP node enrolled by a
compromised and discovered ACP registrar will fail.</t> compromised and discovered ACP registrar will fail.</t>
<t>ACP nodes enrolled by a compromised ACP registrar <t indent="0" pn="section-9.2.4-3">ACP nodes enrolled by a compromised ACP registrar
would automatically fail to establish ACP channels and ACP domain would automatically fail to establish ACP channels and ACP domain
certificate renewal via EST and therefore revert to their role as certificate renewal via EST and therefore revert to their role as
a candidate ACP members and attempt to get a new ACP certificate candidate ACP members and attempt to get a new ACP certificate
from an ACP registrar - for example, via BRSKI. In result, ACP registrars that h from an ACP registrar, for example, via BRSKI. As a result, ACP registrars that
ave an have an
associated sub-CA makes isolating and resolving issues with associated sub-CA make isolating and resolving issues with
compromised registrars easier.</t> compromised registrars easier.</t>
<t>Note that ACP registrars with sub-CA functionality also can control <t indent="0" pn="section-9.2.4-4">Note that ACP registrars with sub-C
the A functionality also can control the
lifetime of ACP certificates easier and therefore also be used as lifetime of ACP certificates more easily and therefore can be used as
a tool to introduce short lived certificates and not rely on CRL, a tool to introduce short-lived certificates and to no longer rely on CRL,
whereas the certificates for the sub-CAs themselves could be longer whereas the certificates for the sub-CAs themselves could be longer
lived and subject to CRL.</t> lived and subject to CRL.</t>
</section> </section>
<section anchor="pms" numbered="true" toc="default"> <section anchor="pms" numbered="true" toc="include" removeInRFC="false"
<name>Centralized Policy Control</name> pn="section-9.2.5">
<t>When using multiple, uncoordinated ACP registrars, several advanced <name slugifiedName="name-centralized-policy-control">Centralized Poli
cy Control</name>
<t indent="0" pn="section-9.2.5-1">When using multiple, uncoordinated
ACP registrars, several advanced
operations are potentially more complex than with a single, resilient operations are potentially more complex than with a single, resilient
policy control backend, for example including but not limited to: policy control backend, for example, including but not limited to the following :
</t> </t>
<ul spacing="compact"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<li>Which candidate ACP node is permitted or not permitted into an -9.2.5-2">
ACP domain. This may not be a decision to be taken upfront, so that <li pn="section-9.2.5-2.1">Deciding which candidate ACP node is perm
itted or not permitted into an
ACP domain. This may not be a decision to be made upfront, so that
a policy per "serialNumber" attribute in the subject field distinguished na me encoding can be loaded into every ACP registrar. a policy per "serialNumber" attribute in the subject field distinguished na me encoding can be loaded into every ACP registrar.
Instead, it may better be decided in real-time including potentially Instead, it may better be decided in real time, potentially including
a human decision in a NOC.</li> a human decision in a NOC.</li>
<li>Tracking of all enrolled ACP nodes and their certificate informa <li pn="section-9.2.5-2.2">Tracking all enrolled ACP nodes and their
tion. certificate information.
For example, in support of revoking individual ACP nodes certificates.</li> For example, in support of revoking an individual ACP node's certificates.<
<li>More flexible policies what type of address prefix or even what /li>
specific <li pn="section-9.2.5-2.3">Needing more flexible policies as to whic
h type of address prefix or even which specific
address prefix to assign to a candidate ACP node.</li> address prefix to assign to a candidate ACP node.</li>
</ul> </ul>
<t>These and other operations could be introduced more easily by <t indent="0" pn="section-9.2.5-3">These and other operations could be introduced more easily by
introducing a centralized Policy Management System (PMS) and modifying introducing a centralized Policy Management System (PMS) and modifying
ACP registrar behavior so that it queries the PMS for any policy decision ACP registrar behavior so that it queries the PMS for any policy decision
occurring during the candidate ACP node enrollment process and/or the occurring during the candidate ACP node enrollment process and/or the
ACP node certificate renewal process. For example, which ACP address ACP node certificate renewal process, for example, which ACP address
prefix to assign. Likewise the ACP registrar would report any relevant state prefix to assign. Likewise, the ACP registrar would report any relevant state
change information to the PMS as well, for example when a certificate change information to the PMS as well, for example, when a certificate
was successfully enrolled onto a candidate ACP node.</t> was successfully enrolled onto a candidate ACP node.</t>
</section> </section>
</section> </section>
<section anchor="enabling-acp" numbered="true" toc="default"> <section anchor="enabling-acp" numbered="true" toc="include" removeInRFC="
<name>Enabling and disabling ACP/ANI</name> false" pn="section-9.3">
<t> Both ACP and BRSKI require interfaces to be operational enough to su <name slugifiedName="name-enabling-and-disabling-the-">Enabling and Disa
pport sending/receiving their packets. In node types where interfaces are by de bling the ACP and/or the ANI</name>
fault (e.g., without operator configuration) enabled, such as most L2 switches, <t indent="0" pn="section-9.3-1"> Both ACP and BRSKI require interfaces
this would be less of a change in behavior than in most L3 devices (e.g. routers to be operational enough to support the sending and receiving of their packets.
), where interfaces are by default disabled. In almost all network devices it i In node types where interfaces are enabled by default (e.g., without operator c
s common though for configuration to change interfaces to a physically disabled onfiguration), such as most L2 switches, this would be less of a change in behav
state and that would break the ACP.</t> ior than in most L3 devices (e.g., routers), where interfaces are disabled by de
<t>In this section, we discuss a suggested operational model to enable/d fault. In almost all network devices, though, it is common for configuration to
isable interfaces and nodes for ACP/ANI in a way that minimizes the risk of oper change interfaces to a physically disabled state, and this would break the ACP.
ator action to break the ACP in this way, and that also minimizes operator surpr </t>
ise when ACP/ANI becomes supported in node software.</t> <t indent="0" pn="section-9.3-2">In this section, we discuss a suggested
<section anchor="secure-enabling" numbered="true" toc="default"> operational model to enable and disable interfaces and nodes for ACP/ANI in a w
<name>Filtering for non-ACP/ANI packets</name> ay that minimizes the risk of breaking the ACP due to operator action and also m
<t>Whenever this document refers to enabling an interface for ACP (or inimizes operator surprise when the ACP/ANI becomes supported in node software.<
BRSKI), it only requires to permit the interface to send/receive packets necessa /t>
ry to operate ACP (or BRSKI) - but not any other Data-Plane packets. Unless the <section anchor="secure-enabling" numbered="true" toc="include" removeIn
Data-Plane is explicitly configured/enabled, all packets not required for ACP/B RFC="false" pn="section-9.3.1">
RSKI should be filtered on input and output:</t> <name slugifiedName="name-filtering-for-non-acp-ani-p">Filtering for N
<t>Both BRSKI and ACP require link-local only IPv6 operations on inter on-ACP/ANI Packets</name>
faces and DULL GRASP. IPv6 link-local operations means the minimum signaling to <t indent="0" pn="section-9.3.1-1">Whenever this document refers to en
auto-assign an IPv6 link-local address and talk to neighbors via their link-loc abling an interface for ACP (or BRSKI), it only requires permitting the interfac
al address: SLAAC (Stateless Address Auto-Configuration - <xref target="RFC4862" e to send and receive packets necessary to operate ACP (or BRSKI) -- but not any
format="default"/>) and ND (Neighbor Discovery - <xref target="RFC4861" format= other data plane packets. Unless the data plane is explicitly configured and e
"default"/>). When the device is a BRSKI pledge, it may also require TCP/TLS co nabled, all packets that are not required for ACP/BRSKI should be filtered on in
nnections to BRSKI proxies on the interface. When the device has keying materia put and output.</t>
l, and the ACP is running, it requires DULL GRASP packets and packets necessary <t indent="0" pn="section-9.3.1-2">Both BRSKI and ACP require link-loc
for the secure-channel mechanism it supports, e.g., IKEv2 and IPsec ESP packets al-only IPv6 operations on interfaces and DULL GRASP. IPv6 link-local operation
or DTLS packets to the IPv6 link-local address of an ACP neighbor on the interfa s mean the minimum signaling to auto-assign an IPv6 link-local address and talk
ce. It also requires TCP/TLS packets for its BRSKI proxy functionality, if it d to neighbors via their link-local addresses: SLAAC <xref target="RFC4862" format
oes support BRSKI.</t> ="default" sectionFormat="of" derivedContent="RFC4862"/> and ND <xref target="RF
C4861" format="default" sectionFormat="of" derivedContent="RFC4861"/>. When the
device is a BRSKI pledge, it may also require TCP/TLS connections to BRSKI prox
ies on the interface. When the device has keying material, and the ACP is runni
ng, it requires DULL GRASP packets and packets necessary for the secure channel
mechanism it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the
IPv6 link-local address of an ACP neighbor on the interface. It also requires T
CP/TLS packets for its BRSKI proxy functionality if it supports BRSKI.</t>
</section> </section>
<section anchor="admin-down" numbered="true" toc="default"> <section anchor="admin-down" numbered="true" toc="include" removeInRFC="
<name>Admin Down State</name> false" pn="section-9.3.2">
<t>Interfaces on most network equipment have at least two states: "up" <name slugifiedName="name-admin-down-state">"admin down" State</name>
and "down". These may have product specific names. "down" for example could b <t indent="0" pn="section-9.3.2-1">Interfaces on most network equipmen
e called "shutdown" and "up" could be called "no shutdown". The "down" state di t have at least two states: "up" and "down". These may have product-specific na
sables all interface operations down to the physical level. The "up" state enab mes. For example, "down" could be called "shutdown", and "up" could be called "
les the interface enough for all possible L2/L3 services to operate on top of it no shutdown". The "down" state disables all interface operations down to the ph
and it may also auto-enable some subset of them. More commonly, the operations ysical level. The "up" state enables the interface enough for all possible L2/L
of various L2/L3 services is controlled via additional node-wide or interface l 3 services to operate on top of it, and it may also auto-enable some subset of t
evel options, but they all become only active when the interface is not "down". hem. More commonly, the operations of various L2/L3 services are controlled via
Therefore, an easy way to ensure that all L2/L3 operations on an interface are additional node-wide or interface-level options, but they all become active onl
inactive is to put the interface into "down" state. The fact that this also phy y when the interface is not "down". Therefore, an easy way to ensure that all L
sically shuts down the interface is in many cases just a side effect, but it may 2/L3 operations on an interface are inactive is to put the interface into "down"
be important in other cases (see below, <xref target="down-fast-state-propagati state. The fact that this also physically shuts down the interface is just a s
on" format="default"/>).</t> ide effect in many cases, but it may be important in other cases (see <xref targ
<t>One of the common problems of remote management is for the operator et="down-fast-state-propagation" format="default" sectionFormat="of" derivedCont
or SDN controller to cut its own connectivity to the remote node by a configura ent="Section 9.3.2.2"/>).</t>
tion impacting its own management connection into the node. The ACP itself shoul <t indent="0" pn="section-9.3.2-2">A common problem of remote manageme
d have no dedicated configuration other than aforementioned enablement of the AC nt is the operator or SDN controller cutting its own connectivity to the remote
P on brownfield ACP nodes. This leaves configuration that cannot distinguish bet node via configuration, impacting its own management connection to the node. The
ween ACP and Data-Plane as sources of configuration mistakes as these commands w ACP itself should have no dedicated configuration other than the aforementioned
ill impact the ACP even though they should only impact the Data-Plane.</t> enabling of the ACP on brownfield ACP nodes. This leaves configuration that can
<t>The one ubiquitous type of commands that do this on many type of ro not distinguish between the ACP and data plane as sources of configuration mista
uters are interface "down" commands/configurations. When such a command is appli kes as these commands will impact the ACP even though they should only impact th
ed to the interface through which the ACP provides access for remote management e data plane.</t>
it would cut the remote management connection through the ACP because, as outlin <t indent="0" pn="section-9.3.2-3">The one ubiquitous type of command
ed above, the "down" commands typically impact the physical layer too and not on that does this on many types of routers is the interface "down" command/configur
ly the Data-Plane services.</t> ation. When such a command is applied to the interface through which the ACP pro
<t>To provide ACP/ANI resilience against such operator misconfiguratio vides access for remote management, it cuts the remote management connection thr
n, this document ough the ACP because, as outlined above, the "down" command typically impacts th
recommends to separate the "down" state of interfaces into an "admin down" state e physical layer, too, and not only the data plane services.</t>
where the physical layer is kept running and ACP/ANI can use the interface and <t indent="0" pn="section-9.3.2-4">To provide ACP/ANI resilience again
a "physical down" state. Any existing "down" configurations would map to "admin st such operator misconfiguration, this document
down". In "admin down", any existing L2/L3 services of the Data-Plane should s recommends separating the "down" state of interfaces into an "admin down" state,
ee no difference to "physical down" state. To ensure that no Data-Plane packets where the physical layer is kept running and the ACP/ANI can use the interface,
could be sent/received, packet filtering could be established automatically as and a "physical down" state. Any existing "down" configurations would map to "
described above in <xref target="secure-enabling" format="default"/>.</t> admin down". In "admin down", any existing L2/L3 services of the data plane sho
<t>An example of non-ACP but ANI traffic that should be permitted to p uld see no difference to "physical down" state. To ensure that no data plane pa
ass even in "admin-down" state is BRSKI enrollment traffic between BRSKI pledge ckets could be sent or received, packet filtering could be established automatic
and a BRSKI proxy.</t> ally as described in <xref target="secure-enabling" format="default" sectionForm
<t>As necessary (see discussion below) new configuration options could at="of" derivedContent="Section 9.3.1"/>.</t>
be introduced to issue "physical down". The options should be provided with ad <t indent="0" pn="section-9.3.2-5">An example of ANI, but not ACP, tra
ditional checks to minimize the risk of issuing them in a way that breaks the AC ffic that should be permitted to pass even in "admin down" state is BRSKI enroll
P without automatic restoration. For example, they could be denied to be issued ment traffic between a BRSKI pledge and a BRSKI proxy.</t>
from a control connection (NETCONF/SSH) that goes across the interface itself ( <t indent="0" pn="section-9.3.2-6">New configuration options could be
"do not disconnect yourself"). Or they could be performed only temporary and on introduced as necessary (see discussion below) to issue "physical down". The op
ly be made permanent with additional later reconfirmation.</t> tions should be provided with additional checks to minimize the risk of issuing
<t>In the following sub-sections important aspects to the introduction them in a way that breaks the ACP without automatic restoration. Examples of ch
of "admin down" state are discussed.</t> ecks include not allowing the option to be issued from a control connection (NET
<section anchor="down-security" numbered="true" toc="default"> CONF/SSH) that goes across the interface itself ("do not disconnect yourself") o
<name>Security</name> r only applying the option after additional reconfirmation.</t>
<t>Interfaces are physically brought down (or left in default down s <t indent="0" pn="section-9.3.2-7">The following subsections discuss i
tate) as a form of security. mportant aspects of the introduction of "admin down" state.</t>
"Admin down" state as described above provides also a high level of security <section anchor="down-security" numbered="true" toc="include" removeIn
because it only permits ACP/ANI operations which are both well secured. Ultimat RFC="false" pn="section-9.3.2.1">
ely, it is subject to <name slugifiedName="name-security-2">Security</name>
security review for the deployment whether "admin down" is a feasible replacemen <t indent="0" pn="section-9.3.2.1-1">Interfaces are physically broug
t for "physical down".</t> ht down (or left in default "down" state) as a form of security.
<t>The need to trust the security of ACP/ANI operations needs to be The "admin down" state as described above also provides also a high level of sec
weighed against urity
the operational benefits of permitting this: Consider the typical example of a C because it only permits ACP/ANI operations, which are both well secured. Ultima
PE (customer tely, it is subject to
premises equipment) with no on-site network expert. User ports are in physical the deployment's security review whether "admin down" is a feasible replacement
down state unless explicitly configured not to be. In a misconfiguration situat for "physical down".</t>
ion, the uplink <t indent="0" pn="section-9.3.2.1-2">The need to trust the security
connection is incorrectly plugged into such as user port. The device is disconn of ACP/ANI operations needs to be weighed against
ected from the the operational benefits of permitting the following: consider the typical examp
network and therefore no diagnostics from the network side is possible anymore. le of a CPE (customer
Alternatively, all ports default to "admin down". The ACP (but not the Data-Pla premises equipment) with no on-site network expert. User ports are in "physical
ne) would down" state unless explicitly configured not to be. In a misconfiguration situa
still automatically form. Diagnostics from the network side is possible and ope tion, the uplink
rator connection is incorrectly plugged into such a user port. The device is disconne
reaction could include to either make this port the operational uplink port or t cted from the
o instruct network, and therefore diagnostics from the network side are no longer possible.
re-cabling. Security wise, only ACP/ANI could be attacked, all other functions Alternatively, all ports default to "admin down". The ACP (but not the data pla
are filtered ne) would
still automatically form. Diagnostics from the network side are possible, and o
perator
reaction could include either to make this port the operational uplink port or t
o instruct
re-cabling. Security wise, only the ACP/ANI could be attacked, all other functi
ons are filtered
on interfaces in "admin down" state.</t> on interfaces in "admin down" state.</t>
</section> </section>
<section anchor="down-fast-state-propagation" numbered="true" toc="def <section anchor="down-fast-state-propagation" numbered="true" toc="inc
ault"> lude" removeInRFC="false" pn="section-9.3.2.2">
<name>Fast state propagation and Diagnostics</name> <name slugifiedName="name-fast-state-propagation-and-">Fast State Pr
<t>"Physical down" state propagates on many interface types (e.g., E opagation and Diagnostics</name>
thernet) to the other side. <t indent="0" pn="section-9.3.2.2-1">The "physical down" state propa
This can trigger fast L2/L3 protocol reaction on the other side and "admin down" gates on many interface types (e.g., Ethernet) to the other side.
would not This can trigger fast L2/L3 protocol reaction on the other side, and "admin down
" would not
have the same (fast) result.</t> have the same (fast) result.</t>
<t>Bringing interfaces to "physical down" state is to the best of ou <t indent="0" pn="section-9.3.2.2-2">Bringing interfaces to "physica
r knowledge always l down" state is, to the best of our knowledge, always
a result of operator action, but today, never the result of autonomic L2/L3 serv a result of operator action and, today, never the result of autonomic L2/L3 serv
ices ices
running on the nodes. Therefore, one option is to change the operator action to running on the nodes. Therefore, one option is to end the operator's reliance
not on interface state propagation via the subnet link or physical layer. This may
rely on link-state propagation anymore. This may not be possible when both side not be possible when both sides are
s are under the control of different operators, but in that case, it is unlikely that
under different operator control, but in that case it is unlikely that the ACP i the ACP is running
s running across the link, and actually putting the interface into "physical down" state m
across the link and actually putting the interface into "physical down" state ma ay
y
still be a good option.</t> still be a good option.</t>
<t>Ideally, fast physical state propagation is replaced by fast soft <t indent="0" pn="section-9.3.2.2-3">Ideally, fast physical state pr
ware driven state opagation is replaced by fast software-driven state
propagation. For example, a DULL GRASP "admin-state" objective could be used to propagation. For example, a DULL GRASP "admin-state" objective could be used to
auto configure autoconfigure
a Bidirectional Forwarding Protocol (BFD, <xref target="RFC5880" format="default a BFD session ("<xref target="RFC5880" format="title" sectionFormat="of" derived
"/>) session between the two sides of the link that would be used to propagate t Content="Bidirectional Forwarding Detection (BFD)"/>" <xref target="RFC5880" for
he mat="default" sectionFormat="of" derivedContent="RFC5880"/>) between the two sid
"up" vs. admin down state.</t> es of the link that would be used to propagate the
<t>Triggering physical down state may also be used as a mean of diag "up" vs. "admin down" state.</t>
nosing cabling <t indent="0" pn="section-9.3.2.2-4">Triggering "physical down" stat
e may also be used as a means of diagnosing cabling issues
in the absence of easier methods. It is more complex than automated neighbor di agnostics in the absence of easier methods. It is more complex than automated neighbor di agnostics
because it requires coordinated remote access to both (likely) sides of a link t o because it requires coordinated remote access to (likely) both sides of a link t o
determine whether up/down toggling will cause the same reaction on the remote si de.</t> determine whether up/down toggling will cause the same reaction on the remote si de.</t>
<t>See <xref target="diagnostics" format="default"/> for a discussio <t indent="0" pn="section-9.3.2.2-5">See <xref target="diagnostics"
n about how LLDP and/or diagnostics format="default" sectionFormat="of" derivedContent="Section 9.1"/> for a discuss
via GRASP could be used to provide neighbor diagnostics, and therefore hopefully ion about how LLDP and/or diagnostics
eliminating the need for "physical down" for neighbor diagnostics - as long as b via GRASP could be used to provide neighbor diagnostics and therefore hopefully
oth eliminate the need for "physical down" for neighbor diagnostics -- as long as bo
th
neighbors support ACP/ANI.</t> neighbors support ACP/ANI.</t>
</section> </section>
<section anchor="low-level-link" numbered="true" toc="default"> <section anchor="low-level-link" numbered="true" toc="include" removeI
<name>Low Level Link Diagnostics</name> nRFC="false" pn="section-9.3.2.3">
<t>"Physical down" is performed to diagnose low-level interface beha <name slugifiedName="name-low-level-link-diagnostics">Low-Level Link
vior when higher layer services (e.g., IPv6) are not working. Especially Ethern Diagnostics</name>
et links are subject to a wide variety of possible wrong configuration/cablings <t indent="0" pn="section-9.3.2.3-1">The "physical down" state is us
if they do not support automatic selection of variable parameters such as speed ed to diagnose low-level interface behavior when higher-layer services (e.g., IP
(10/100/1000 Mbps), crossover (Auto-MDIX) and connector (fiber, copper - when in v6) are not working. Ethernet links are especially subject to a wide variety of
terfaces have multiple but can only enable one at a time). The need for low lev possible incorrect configurations/cablings if they do not support automatic sel
el link diagnostic can therefore be minimized by using fully auto configuring li ection of variable parameters such as speed (10/100/1000 Mbps), crossover (autom
nks.</t> atic medium-dependent interface crossover (MDI-X)), and connector (fiber, copper
<t>In addition to "Physical down", low level diagnostics of Ethernet -- when interfaces have multiple but can only enable one at a time). The need
or other interfaces also involve the creation of other states on interfaces, su for low-level link diagnostics can therefore be minimized by using fully autocon
ch as physical Loopback (internal and/or external) or bringing down all packet t figuring links.</t>
ransmissions for reflection/cable-length measurements. Any of these options wou <t indent="0" pn="section-9.3.2.3-2">In addition to the "physical do
ld disrupt ACP as well.</t> wn" state, low-level diagnostics of Ethernet or other interfaces also involve th
<t>In cases where such low-level diagnostics of an operational link e creation of other states on interfaces, such as physical loopback (internal an
is desired but where the link could be a single point of failure for the ACP, AS d/or external) or the bringing down of all packet transmissions for reflection a
A on both nodes of the link could perform a negotiated diagnostic that automatic nd/or cable-length measurements. Any of these options would disrupt ACP as well
ally terminates in a predetermined manner without dependence on external input e .</t>
nsuring the link will become operational again.</t> <t indent="0" pn="section-9.3.2.3-3">In cases where such low-level d
iagnostics of an operational link are desired but where the link could be a sing
le point of failure for the ACP, the ASA on both nodes of the link could perform
a negotiated diagnostic that automatically terminates in a predetermined manner
without dependence on external input, ensuring the link will become operational
again.</t>
</section> </section>
<section anchor="power-consumption" numbered="true" toc="default"> <section anchor="power-consumption" numbered="true" toc="include" remo
<name>Power Consumption Issues</name> veInRFC="false" pn="section-9.3.2.4">
<t>Power consumption of "physical down" interfaces, may be significa <name slugifiedName="name-power-consumption-issues">Power Consumptio
ntly lower than those n Issues</name>
in "admin down" state, for example on long-range fiber interfaces. Bringing up <t indent="0" pn="section-9.3.2.4-1">Power consumption of "physical
interfaces, for example to probe reachability, may also consume additional power down" interfaces may be significantly lower than those
. This in "admin down" state, for example, on long-range fiber interfaces. Bringing up
can make these type of interfaces inappropriate to operate purely for the ACP wh interfaces, for example, to probe reachability may also consume additional power
en . This
they are not currently needed for the Data-Plane.</t> can make these types of interfaces inappropriate to operate purely for the ACP w
hen
they are not currently needed for the data plane.</t>
</section> </section>
</section> </section>
<section anchor="if-enable" numbered="true" toc="default"> <section anchor="if-enable" numbered="true" toc="include" removeInRFC="f
<name>Interface level ACP/ANI enable</name> alse" pn="section-9.3.3">
<t>The interface level configuration option "ACP enable" enables ACP <name slugifiedName="name-enabling-interface-level-ac">Enabling Interf
operations on an interface, starting with ACP neighbor discovery via DULL GRAP. ace-Level ACP and ANI</name>
The interface level configuration option "ANI enable" on nodes supporting BRSKI <t indent="0" pn="section-9.3.3-1">The interface-level configuration o
and ACP starts with BRSKI pledge operations when there is no domain certificate ption "ACP enable" enables ACP operations on an interface, starting with ACP ne
on the node. On ACP/BRSKI nodes, "ACP enable" may not need to be supported, bu ighbor discovery via DULL GRASP. The interface-level configuration option "ANI
t only "ANI enable". Unless overridden by global configuration options (see lat enable" on nodes supporting BRSKI and ACP starts with BRSKI pledge operations w
er), "ACP/ANI enable" will result in "down" state on an interface to behave as " hen there is no domain certificate on the node. On ACP/BRSKI nodes, only "ANI e
admin down".</t> nable" may need to be supported and not "ACP enable". Unless overridden by glob
al configuration options (see <xref target="if-enable-auto" format="default" sec
tionFormat="of" derivedContent="Section 9.3.4"/>), either "ACP enable" or "ANI e
nable" (both abbreviated as "ACP/ANI enable") will result in the "down" state o
n an interface behaving as "admin down".</t>
</section> </section>
<section anchor="if-enable-auto" numbered="true" toc="default"> <section anchor="if-enable-auto" numbered="true" toc="include" removeInR
<name>Which interfaces to auto-enable?</name> FC="false" pn="section-9.3.4">
<t>(<xref target="discovery-grasp" format="default"/>) requires that " <name slugifiedName="name-which-interfaces-to-auto-en">Which Interface
ACP enable" is automatically set on native interfaces, but not on non-native int s to Auto-Enable?</name>
erfaces (reminder: a native interface is one that exists without operator config <t indent="0" pn="section-9.3.4-1"><xref target="discovery-grasp" form
uration action such as physical interfaces in physical devices).</t> at="default" sectionFormat="of" derivedContent="Section 6.4"/> requires that "AC
<t>Ideally, ACP enable is set automatically on all interfaces that pro P enable" is automatically set on native interfaces, but not on non-native inter
vide access to additional connectivity that allows to reach more nodes of the AC faces (reminder: a native interface is one that exists without operator configur
P domain. The best set of interfaces necessary to achieve this is not possible ation action, such as physical interfaces in physical devices).</t>
to determine automatically. Native interfaces are the best automatic approximat <t indent="0" pn="section-9.3.4-2">Ideally, "ACP enable" is set automa
ion.</t> tically on all interfaces that provide access to additional connectivity, which
<t>Consider an ACP domain of ACP nodes transitively connected via nati allows more nodes of the ACP domain to be reached. The best set of interfaces n
ve interfaces. A Data-Plane tunnel between two of these nodes that are non-adja ecessary to achieve this is not possible to determine automatically. Native int
cent is created and "ACP enable" is set for that tunnel. ACP RPL sees this tunn erfaces are the best automatic approximation.</t>
el as just as a single hop. Routes in the ACP would use this hop as an attracti <t indent="0" pn="section-9.3.4-3">Consider an ACP domain of ACP nodes
ve path element to connect regions adjacent to the tunnel nodes. In result, the transitively connected via native interfaces. A data plane tunnel between two
actual hop-by-hop paths used by traffic in the ACP can become worse. In additi of these nodes that are nonadjacent is created, and "ACP enable" is set for that
on, correct forwarding in the ACP now depends on correct Data-Plane forwarding c tunnel. ACP RPL sees this tunnel as just as a single hop. Routes in the ACP w
onfig including QoS, filtering and other security on the Data-Plane path across ould use this hop as an attractive path element to connect regions adjacent to t
which this tunnel runs. This is the main issue why "ACP/ANI enable" should not he tunnel nodes. As a result, the actual hop-by-hop paths used by traffic in th
be set automatically on non-native interfaces.</t> e ACP can become worse. In addition, correct forwarding in the ACP now depends
<t>If the tunnel would connect two previously disjoint ACP regions, th on correct data plane forwarding configuration including QoS, filtering, and oth
en it likely would be useful for the ACP. A Data-Plane tunnel could also run ac er security on the data plane path across which this tunnel runs. This is the m
ross nodes without ACP and provide additional connectivity for an already connec ain reason why "ACP/ANI enable" should not be set automatically on non-native in
ted ACP network. The benefit of this additional ACP redundancy has to be weighe terfaces.</t>
d against the problems of relying on the Data-Plane. If a tunnel connects two s <t indent="0" pn="section-9.3.4-4">If the tunnel would connect two pre
eparate ACP regions: how many tunnels should be created to connect these ACP reg viously disjoint ACP regions, then it likely would be useful for the ACP. A dat
ions reliably enough? Between which nodes? These are all standard tunneled netwo a plane tunnel could also run across nodes without ACP and provide additional co
rk design questions not specific to the ACP, and there are no generic fully auto nnectivity for an already connected ACP network. The benefit of this additional
mated answers.</t> ACP redundancy has to be weighed against the problems of relying on the data pl
<t>Instead of automatically setting "ACP enable" on these type of inte ane. If a tunnel connects two separate ACP regions, how many tunnels should be
rfaces, the decision needs to be based on the use purpose of the non-native inte created to connect these ACP regions reliably enough? Between which nodes? These
rface and "ACP enable" needs to be set in conjunction with the mechanism through are all standard tunneled network design questions not specific to the ACP, and
which the non-native interface is created/configured.</t> there are no generic, fully automated answers.</t>
<t>In addition to explicit setting of "ACP/ANI enable", non-native int <t indent="0" pn="section-9.3.4-5">Instead of automatically setting "A
erfaces also need to support configuration of the ACP RPL cost of the link - to CP enable" on these types of interfaces, the decision needs to be based on the u
avoid the problems of attracting too much traffic to the link as described above se purpose of the non-native interface, and "ACP enable" needs to be set in conj
.</t> unction with the mechanism through which the non-native interface is created and
<t>Even native interfaces may not be able to automatically perform BRS /or configured.</t>
KI or ACP because they may require additional operator input to become operation <t indent="0" pn="section-9.3.4-6">In addition to the explicit setting
al. Example include DSL interfaces requiring PPPoE credentials or mobile interf of "ACP/ANI enable", non-native interfaces also need to support configuration o
aces requiring credentials from a SIM card. Whatever mechanism is used to provi f the ACP RPL cost of the link to avoid the problems of attracting too much traf
de the necessary config to the device to enable the interface can also be expand fic to the link as described above.</t>
ed to decide on whether or not to set "ACP/ANI enable".</t> <t indent="0" pn="section-9.3.4-7">Even native interfaces may not be a
<t>The goal of automatically setting "ACP/ANI enable" on interfaces (n ble to automatically perform BRSKI or ACP because they may require additional op
ative or not) is to eliminate unnecessary "touches" to the node to make its oper erator input to become operational. Examples include DSL interfaces requiring P
ation as much as possible "zero-touch" with respect to ACP/ANI. If there are "u oint-to-Point Protocol over Ethernet (PPPoE) credentials or mobile interfaces re
navoidable touches" such a creating/configuring a non-native interface or provis quiring credentials from a SIM card. Whatever mechanism is used to provide the
ioning credentials for a native interface, then "ACP/ANI enable" should be added necessary configuration to the device to enable the interface can also be expand
as an option to that "touch". If a wrong "touch" is easily fixed (not creating ed to decide whether or not to set "ACP/ANI enable".</t>
another high-cost touch), then the default should be not to enable ANI/ACP, and <t indent="0" pn="section-9.3.4-8">The goal of automatically setting "
if it is potentially expensive or slow to fix (e.g., parameters on SIM card shi ACP/ANI enable" on interfaces (native or not) is to eliminate unnecessary "touch
pped to remote location), then the default should be to enable ACP/ANI.</t> es" to the node to make its operation as much as possible "zero-touch" with resp
ect to ACP/ANI. If there are "unavoidable touches" such a creating and/or confi
guring a non-native interface or provisioning credentials for a native interface
, then "ACP/ANI enable" should be added as an option to that "touch". If an err
oneous "touch" is easily fixed (does not create another high-cost touch), then t
he default should be not to enable ANI/ACP, and if it is potentially expensive o
r slow to fix (e.g., parameters on SIM card shipped to remote location), then th
e default should be to enable ACP/ANI.</t>
</section> </section>
<section anchor="node-enable" numbered="true" toc="default"> <section anchor="node-enable" numbered="true" toc="include" removeInRFC=
<name>Node Level ACP/ANI enable</name> "false" pn="section-9.3.5">
<t>A node level command "ACP/ANI enable [up-if-only]" enables ACP or A <name slugifiedName="name-enabling-node-level-acp-and">Enabling Node-L
NI on the node (ANI = ACP + BRSKI). Without this command set, any interface lev evel ACP and ANI</name>
el "ACP/ANI enable" is ignored. Once set, ACP/ANI will operate an interface whe <t indent="0" pn="section-9.3.5-1">A node-level command "ACP/ANI enabl
re "ACP/ANI enable" is set. Setting of interface level "ACP/ANI enable" is eith e [up-if-only]" enables ACP or ANI on the node (ANI = ACP + BRSKI). Without thi
er automatic (default) or explicit through operator action as described in the p s command set, any interface-level "ACP/ANI enable" is ignored. Once set, ACP/A
revious section.</t> NI will operate an interface where "ACP/ANI enable" is set. Setting of interfac
<t>If the option "up-if-only" is selected, the behavior of "down" inte e-level "ACP/ANI enable" is either automatic (default) or explicit through opera
rfaces is unchanged, and ACP/ANI will only operate on interfaces where "ACP/ANI tor action as described in <xref target="if-enable-auto" format="default" sectio
enable" is set and that are "up". When it is not set, then "down" state of inte nFormat="of" derivedContent="Section 9.3.4"/>.</t>
rfaces with "ACP/ANI enable" is modified to behave as "admin down".</t> <t indent="0" pn="section-9.3.5-2">If the option "up-if-only" is selec
<section anchor="brownfield" numbered="true" toc="default"> ted, the behavior of "down" interfaces is unchanged, and ACP/ANI will only opera
<name>Brownfield nodes</name> te on interfaces where "ACP/ANI enable" is set and that are "up". When it is no
<t>A "brownfield" node is one that already has a configured Data-Pla t set, then "down" state of interfaces with "ACP/ANI enable" is modified to beha
ne.</t> ve as "admin down".</t>
<t>Executing global "ACP/ANI enable [up-if-only]" on each node is th <section anchor="brownfield" numbered="true" toc="include" removeInRFC
e only command necessary to create an ACP across a network of brownfield nodes o ="false" pn="section-9.3.5.1">
nce all the nodes have a domain certificate. When BRSKI is used ("ANI enable"), <name slugifiedName="name-brownfield-nodes">Brownfield Nodes</name>
provisioning of the certificates only requires set-up of a single BRSKI registr <t indent="0" pn="section-9.3.5.1-1">A "brownfield" node is one that
ar node which could also implement a CA for the network. This is the simplest w already has a configured data plane.</t>
ay to introduce ACP/ANI into existing (== brownfield) networks.</t> <t indent="0" pn="section-9.3.5.1-2">Executing global "ACP/ANI enabl
<t>The need to explicitly enable ACP/ANI is especially important in e [up-if-only]" on each node is the only command necessary to create an ACP acro
brownfield nodes because otherwise software updates may introduce support for AC ss a network of brownfield nodes once all the nodes have a domain certificate.
P/ANI: Automatic enablement of ACP/ANI in networks where the operator does not o When BRSKI is used ("ANI enable"), provisioning of the certificates only require
nly not want ACP/ANI but where the operator likely never even heard of it could s the setup of a single BRSKI registrar node, which could also implement a CA fo
be quite irritating to the operator. Especially when "down" behavior is changed r the network. This is the simplest way to introduce ACP/ANI into existing (i.e
to "admin down".</t> ., brownfield) networks.</t>
<t>Automatically setting "ANI enable" on brownfield nodes where the <t indent="0" pn="section-9.3.5.1-3">The need to explicitly enable A
operator is unaware of BRSKI and MASA operations CP/ANI is especially important in brownfield nodes because otherwise software up
could also be an unlikely but then critical security issue. If an attacker coul dates may introduce support for ACP/ANI. The automatic enabling of ACP/ANI in ne
d impersonate the operator and register tworks where the operator does not want ACP/ANI or has likely never even heard o
as the operator at the MASA or otherwise get hold of vouchers and can get enough f it could be quite irritating to the operator, especially when "down" behavior
physical access to the network so is changed to "admin down".</t>
<t indent="0" pn="section-9.3.5.1-4">Automatically setting "ANI enab
le" on brownfield nodes where the operator is unaware of BRSKI and MASA operatio
ns
could also be an unlikely, but critical, security issue. If an attacker could i
mpersonate the operator by registering
as the operator at the MASA or otherwise getting hold of vouchers and could get
enough physical access to the network so
pledges would register to an attacking registrar, then the attacker could gain a ccess to the pledges would register to an attacking registrar, then the attacker could gain a ccess to the
ACP, and through the ACP gain access to the Data-Plane.</t> ACP and, through the ACP, gain access to the data plane.</t>
<t indent="0" pn="section-9.3.5.1-5">In networks where the operator
<t>In networks where the operator explicitly wants to enable the ANI explicitly enables the ANI, this could not happen because the operator would cre
this could not happen, because the operator would create a BRSKI registrar that ate a BRSKI registrar that would discover attack attempts, and the operator woul
would discover attack attempts, and the operator would be setting up his regist d set up his registrar with the MASA. Nodes requiring "ownership vouchers" woul
rar with the MASA. Nodes requiring "ownership vouchers" would not be subject to d not be subject to that attack. See <xref target="RFC8995" format="default" se
that attack. See <xref target="I-D.ietf-anima-bootstrapping-keyinfra" format=" ctionFormat="of" derivedContent="RFC8995"/> for more details. Note that a globa
default"/> for more details. Note that a global "ACP enable" alone is not subje l "ACP enable" alone is not subject to these types of attacks because they alway
ct to these type of attacks, because it always depends on some other mechanism f s depend on some other mechanism first to provision domain certificates into the
irst to provision domain certificates into the device.</t> device.</t>
</section> </section>
<section anchor="greenfield" numbered="true" toc="default"> <section anchor="greenfield" numbered="true" toc="include" removeInRFC
<name>Greenfield nodes</name> ="false" pn="section-9.3.5.2">
<name slugifiedName="name-greenfield-nodes">Greenfield Nodes</name>
<t>An ACP "greenfield" node is one that does not have any prior conf <t indent="0" pn="section-9.3.5.2-1">An ACP "greenfield" node is one
iguration and that can be bootstrapped into the ACP across the network. To suppo that does not have any prior configuration and that can be bootstrapped into th
rt greenfield nodes, ACP as described in this document needs to be combined with e ACP across the network. To support greenfield nodes, ACP as described in this
a bootstrap protocol/mechanism that will enroll the node with the ACP keying ma document needs to be combined with a bootstrap protocol and/or mechanism that wi
terial - ACP certificate and TA. For ANI nodes, this protocol/mechanism is BRSKI ll enroll the node with the ACP keying material: the ACP certificate and the TA.
.</t> For ANI nodes, this protocol/mechanism is BRSKI.</t>
<t indent="0" pn="section-9.3.5.2-2">When such a node is powered on
<t>When such a node is powered on and determines it is in greenfield and determines that it is in greenfield condition, it enables the bootstrap prot
condition, it enables the bootstrap protocol(s)/mechanism(s), and once the ACP ocol(s) and/or mechanism(s). Once the ACP keying material is enrolled, the green
keying material is enrolled, greenfield state ends and the ACP is started. When field state ends and the ACP is started. When BRSKI is used, the node's state re
BRSKI is used, the node's state reflects this by setting "ANI enable" upon deter flects this by setting "ANI enable" upon determination of greenfield state when
mination of greenfield state at power on.</t> it is powered on.</t>
<t indent="0" pn="section-9.3.5.2-3">ACP greenfield nodes that, in t
<t>ACP greenfield nodes that in the absence of ACP would have their he absence of ACP, would have their interfaces in "down" state <bcp14>SHOULD</bc
interfaces in "down" state SHOULD set all native interfaces into "admin down" st p14> set all native interfaces into "admin down" state and only permit data plan
ate and only permit Data-Plane traffic required for the bootstrap protocol/mecha e traffic required for the bootstrap protocol and/or mechanisms.</t>
nisms.</t> <t indent="0" pn="section-9.3.5.2-4">The ACP greenfield state ends e
ither through the successful enrollment of ACP keying material (certificate and
<t>ACP greenfield state ends either through successful enrolment of ACP keying m TA) or the detection of a permitted termination of ACP greenfield operations.</t
aterial (certificate, TA) or detection of a permitted termination of ACP greenfi >
eld operations.</t> <t indent="0" pn="section-9.3.5.2-5">ACP nodes supporting greenfield
operations <bcp14>MAY</bcp14> want to provide backward compatibility with other
<t>ACP nodes supporting greenfield operations MAY want to provide ba forms of configuration and/or provisioning, especially when only a subset of no
ckward compatibility with other forms of configuration/provisioning, especially des are expected to be deployed with ACP. Such an ACP node <bcp14>SHOULD</bcp14>
when only a subset of nodes are expected to be deployed with ACP. Such an ACP no observe attempts to provision or configure the node via interfaces and/or metho
de SHOULD observe attempts to provision/configure the node via interfaces/method ds that traditionally indicate physical possession of the node, such as a serial
s that traditionally indicate physical possession of the node, such as a serial or USB console port or a USB memory stick with a bootstrap configuration. When
or USB console port or a USB memory stick with a bootstrap configuration. When s such an operation is observed before enrollment of the ACP keying material has c
uch an operation is observed before enrollment of the ACP keying material has co ompleted, the node <bcp14>SHOULD</bcp14> put itself into the state the node woul
mpleted, the node SHOULD put itself into the state the node would have been in, d have been in if ACP/ANI was disabled at boot. This terminates ACP greenfield o
if ACP/ANI was disabled at boot (terminate ACP greenfield operations).</t> perations.</t>
<t indent="0" pn="section-9.3.5.2-6">When an ACP greenfield node ena
<t>When an ACP greenfield node enables multiple automated ACP or non bles multiple, automated ACP or non-ACP enrollment and/or bootstrap protocols or
-ACP enrollment/bootstrap protocols/mechanisms in parallel, care must be taken n mechanisms in parallel, care must be taken not to terminate any protocol/mechan
ot to terminate any protocol/mechanism before another one has succeeded to enrol ism before the others either have succeeded in enrolling ACP keying material or
l ACP keying material or has progressed to a point where it is permitted to be a have progressed to a point of permitted termination for ACP greenfield operation
termination reason for ACP greenfield operations.</t> s.</t>
<t indent="0" pn="section-9.3.5.2-7">Highly secure ACP greenfield no
<t>Highly secure ACP greenfield nodes may not permit any reason to t des may not permit any reason to terminate ACP greenfield operations, including
erminate ACP greenfield operations, including physical access.</t> physical access.</t>
<t indent="0" pn="section-9.3.5.2-8">Nodes that claim to support ANI
<t>Nodes that claim to support ANI greenfield operations SHOULD NOT greenfield operations <bcp14>SHOULD NOT</bcp14> enable in parallel to BRSKI any
enable in parallel to BRSKI any enrollment/bootstrap protocol/mechanism that all enrollment/bootstrap protocol/mechanism that allows Trust On First Use (TOFU, "
ows Trust On First Use (TOFU, <xref target="RFC7435" format="default"/>) over in <xref target="RFC7435" format="title" sectionFormat="of" derivedContent="Opportu
terfaces other than those traditionally indicating physical possession of the no nistic Security: Some Protection Most of the Time"/>" <xref target="RFC7435" for
de. Protocols/mechanisms with published default username/password authenticatio mat="default" sectionFormat="of" derivedContent="RFC7435"/>) over interfaces oth
n are considered to suffer from TOFU. Securing the bootstrap protocol/mechanism er than those traditionally indicating physical possession of the node. Protoco
by requiring a voucher (<xref target="RFC8366" format="default"/>) can be used t ls/mechanisms with published default username/password authentication are consid
o avoid TOFU.</t> ered to suffer from TOFU. Securing the bootstrap protocol/mechanism by requiring
a voucher <xref target="RFC8366" format="default" sectionFormat="of" derivedCon
<t>In summary, the goal of ACP greenfield support is to allow remote tent="RFC8366"/> can be used to avoid TOFU.</t>
automated enrollment of ACP keying materials, and therefore automated bootstrap <t indent="0" pn="section-9.3.5.2-9">In summary, the goal of ACP gre
into the ACP and to prohibit TOFU during bootstrap with the likely exception (f enfield support is to allow remote, automated enrollment of ACP keying materials
or backward compatibility) of bootstrapping via interfaces traditionally indicat , and therefore automated bootstrap into the ACP and to prohibit TOFU during boo
ing physical possession of the node.</t> tstrap with the likely exception (for backward compatibility) of bootstrapping v
ia interfaces traditionally indicating physical possession of the node.</t>
</section> </section>
</section> </section>
<section anchor="disabling" numbered="true" toc="default"> <section anchor="disabling" numbered="true" toc="include" removeInRFC="f
<name>Undoing ANI/ACP enable</name> alse" pn="section-9.3.6">
<t>Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the rel <name slugifiedName="name-undoing-ani-acp-enable">Undoing "ANI/ACP ena
iable operations of the ACP if it can be executed by mistake or unauthorized. ble"</name>
This behavior could be influenced through some additional (future) property in t <t indent="0" pn="section-9.3.6-1">Disabling ANI/ACP by undoing "ACP/A
he certificate (e.g., in the acp-node-name extension field): In an ANI deploymen NI enable" is a risk for the reliable operations of the ACP if it can be execute
t intended for convenience, disabling it could be allowed without further constr d by mistake or without authorization.
aints. In an ANI deployment considered to be critical more checks would be requ This behavior could be influenced through some additional (future) property in t
ired. he certificate (e.g., in the acp-node-name extension field): in an ANI deploymen
t intended for convenience, disabling it could be allowed without further constr
aints. In an ANI deployment considered to be critical, more checks would be req
uired.
One very controlled option would be to not permit these commands unless the doma in certificate has been revoked or is denied renewal. Configuring this option w ould be a parameter on the BRSKI registrar(s). As long as the node did not rece ive a domain certificate, undoing "ANI/ACP enable" should not have any additiona l constraints.</t> One very controlled option would be to not permit these commands unless the doma in certificate has been revoked or is denied renewal. Configuring this option w ould be a parameter on the BRSKI registrar(s). As long as the node did not rece ive a domain certificate, undoing "ANI/ACP enable" should not have any additiona l constraints.</t>
</section> </section>
<section anchor="enable-summary" numbered="true" toc="default"> <section anchor="enable-summary" numbered="true" toc="include" removeInR
<name>Summary</name> FC="false" pn="section-9.3.7">
<t>Node-wide "ACP/ANI enable [up-if-only]" commands enable the operati <name slugifiedName="name-summary-2">Summary</name>
on of ACP/ANI. This is only auto-enabled on ANI greenfield devices, otherwise i <t indent="0" pn="section-9.3.7-1">Node-wide "ACP/ANI enable [up-if-on
t must be configured explicitly.</t> ly]" commands enable the operation of ACP/ANI. This is only auto-enabled on ANI
<t>If the option "up-if-only" is not selected, interfaces enabled for greenfield devices, otherwise it must be configured explicitly.</t>
ACP/ANI interpret "down" state as "admin down" and not "physical down". In "adm <t indent="0" pn="section-9.3.7-2">If the option "up-if-only" is not s
in-down" all non-ACP/ANI packets are filtered, but the physical layer is kept ru elected, interfaces enabled for ACP/ANI interpret the "down" state as "admin dow
nning to permit ACP/ANI to operate.</t> n" and not "physical down". In the "admin-down" state, all non-ACP/ANI packets
<t>(New) commands that result in physical interruption ("physical down are filtered, but the physical layer is kept running to permit ACP/ANI to operat
", "loopback") of ACP/ANI enabled interfaces should be built to protect continua e.</t>
nce or reestablishment of ACP as much as possible.</t> <t indent="0" pn="section-9.3.7-3">(New) commands that result in physi
<t>Interface level "ACP/ANI enable" control per-interface operations. cal interruption ("physical down", "loopback") of ACP/ANI-enabled interfaces sho
It is enabled by default on native interfaces and has to be configured explicit uld be built to protect continuance or reestablishment of ACP as much as possibl
ly on other interfaces.</t> e.</t>
<t>Disabling "ACP/ANI enable" global and per-interface should have add <t indent="0" pn="section-9.3.7-4">Interface-level "ACP/ANI enable" co
itional checks to minimize undesired breakage of ACP. The degree of control cou mmands control per-interface operations. It is enabled by default on native int
ld be a domain wide parameter in the domain certificates.</t> erfaces and has to be configured explicitly on other interfaces.</t>
<t indent="0" pn="section-9.3.7-5">Disabling "ACP/ANI enable" globally
and per interface should have additional checks to minimize undesired breakage
of ACP. The degree of control could be a domain-wide parameter in the domain ce
rtificates.</t>
</section> </section>
</section> </section>
<section anchor="incremental-adoption" numbered="true" toc="default"> <section anchor="incremental-adoption" numbered="true" toc="include" remov
<name>Partial or Incremental adoption</name> eInRFC="false" pn="section-9.4">
<t>The ACP Zone Addressing Sub-Scheme (see <xref target="zone-scheme" fo <name slugifiedName="name-partial-or-incremental-adop">Partial or Increm
rmat="default"/>) allows incremental ental Adoption</name>
<t indent="0" pn="section-9.4-1">The Zone Addressing Sub-Scheme (see <xr
ef target="zone-scheme" format="default" sectionFormat="of" derivedContent="Sect
ion 6.11.3"/>) allows incremental
adoption of the ACP in a network where ACP can be deployed on edge areas, but no t adoption of the ACP in a network where ACP can be deployed on edge areas, but no t
across the core that is connecting those edges.</t> across the core that is connecting those edges.</t>
<t>In such a setup, each edge network, such as a branch or campus of an <t indent="0" pn="section-9.4-2">In such a setup, each edge network, suc
enterprise network h as a branch or campus of an enterprise network,
has a disjoined ACP to which one or more unique Zone-IDs are assigned: ACP nodes has a disjoint ACP to which one or more unique Zone-IDs are assigned: ACP nodes
registered for registered for
a specific ACP zone have to receive ACP Zone Addressing Sub-scheme addresses, fo a specific ACP zone have to receive Zone Addressing Sub-Scheme addresses, for ex
r example ample,
by virtue of configuring for each such zone one or more ACP Registrars with that by virtue of configuring for each such zone one or more ACP registrars with that
Zone-ID. Zone-ID.
All the Registrars for these ACP Zones need to get ACP certificates from CAs rel All the registrars for these ACP zones need to get ACP certificates from CAs rel
ying on a ying on a
common set of TA and of course the same ACP domain name.</t> common set of TAs and of course the same ACP domain name.</t>
<t>These ACP zones can first be brought up as separate networks without <t indent="0" pn="section-9.4-3">These ACP zones can first be brought up
any connection as separate networks without any connection
between them and/or they can be connected across a non-ACP enabled core network through between them and/or they can be connected across a non-ACP enabled core network through
various non-autonomic operational practices. For example, each separate ACP Zone various non-autonomic operational practices. For example, each separate ACP zone
can have an can have an
edge node that is a layer 3 VPN PE (MPLS or IPv6 layer 3 VPN), where a complete edge node that is a L3 VPN PE (MPLS or IPv6 L3VPN), where a complete
non-autonomic ACP-Core VPN is created by using the ACP VRFs and exchanging the r outes non-autonomic ACP-Core VPN is created by using the ACP VRFs and exchanging the r outes
from those ACP VRFs across the VPNs non-autonomic routing protocol(s).</t> from those ACP VRFs across the VPN's non-autonomic routing protocol(s).</t>
<t>While such a setup is possible with any ACP addressing sub-scheme, th <t indent="0" pn="section-9.4-4">While such a setup is possible with any
e ACP addressing sub-scheme, the
ACP-Zone Addressing sub-scheme makes it easy to configure and scalable for any Zone Addressing Sub-Scheme makes it easy to configure and scalable for any
VPN routing protocols because every ACP zone would only need to indicate one or VPN routing protocols because every ACP zone only needs to indicate one or more
more /64 ACP zone addressing prefix routes into the ACP-Core VPN as opposed to routes
/64 ACP Zone Addressing prefix routes into the ACP-Core VPN as opposed to routes
for every individual ACP node as required in the other ACP addressing schemes.</ t> for every individual ACP node as required in the other ACP addressing schemes.</ t>
<t>Note that the non-autonomous ACP-Core VPN would require additional ex tensions <t indent="0" pn="section-9.4-5">Note that the non-autonomous ACP-Core V PN requires additional extensions
to propagate GRASP messages when GRASP discovery is desired across the zones.</t > to propagate GRASP messages when GRASP discovery is desired across the zones.</t >
<t indent="0" pn="section-9.4-6">For example, one could set up on each z
<t>For example, one could set up on each Zone edge router a remote ACP one edge router a remote ACP
tunnel to a GRASP hub. The GRASP hub could be implemented at the application lev el tunnel to a GRASP hub. The GRASP hub could be implemented at the application lev el
and could run in the NOC of the network. It would serve to propagate and could run in the NOC of the network. It would serve to propagate
GRASP announcements between ACP Zones and/or generate GRASP announcements for NO C GRASP announcements between ACP zones and/or generate GRASP announcements for NO C
services.</t> services.</t>
<t indent="0" pn="section-9.4-7">Such a partial deployment may prove to
<t>Such a partial deployment may prove to be sufficient or could evolve be sufficient or could evolve to become more
to become more autonomous through future standardized or nonstandard enhancements, for example,
autonomous through future standardized or non-standardized enhancements, for exa by allowing GRASP messages to be propagated across the L3VPN, leveraging for
mple example L3VPN multicast support.</t>
by allowing GRASP messages to be propagated across the layer 3 VPN, leveraging f <t indent="0" pn="section-9.4-8">Finally, these partial deployments can
or be merged into a single, contiguous
example L3VPN Multicast support.</t> ACP that is completely autonomous (given appropriate ACP support across the core
<t>Finally, these partial deployments can be merged into a single contig ) without changes
uous complete in the cryptographic material because the node's ACP certificates are from a sin
autonomous ACP (given appropriate ACP support across the core) without changes gle ACP.</t>
in the crypto material, because the node's ACP certificates are from a single AC
P.</t>
</section> </section>
<section anchor="configuration" numbered="true" toc="default"> <section anchor="configuration" numbered="true" toc="include" removeInRFC=
<name>Configuration and the ACP (summary)</name> "false" pn="section-9.5">
<t>There is no desirable configuration for the ACP. Instead, all paramet <name slugifiedName="name-configuration-and-the-acp-s">Configuration and
ers that need to be configured in support of the ACP are limitations of the solu the ACP (Summary)</name>
tion, but they are only needed in cases where not all components are made autono <t indent="0" pn="section-9.5-1">There is no desirable configuration for
mic. Wherever this is necessary, it relies on pre-existing mechanisms for config the ACP. Instead, all parameters that need to be configured in support of the A
uration such as CLI or YANG (<xref target="RFC7950" format="default"/>) data mod CP are limitations of the solution, but they are only needed in cases where not
els.</t> all components are made autonomic. Wherever this is necessary, it relies on pree
<t>The most important examples of such configuration include:</t> xisting mechanisms for configuration such as CLI or YANG data models ("<xref tar
<ul spacing="compact"> get="RFC7950" format="title" sectionFormat="of" derivedContent="The YANG 1.1 Dat
<li>When ACP nodes do not support an autonomic way to receive an ACP c a Modeling Language"/>" <xref target="RFC7950" format="default" sectionFormat="o
ertificate, for example BRSKI, then such certificate needs to be configured via f" derivedContent="RFC7950"/>).</t>
some pre-existing mechanisms outside the scope of this specification. Today, rou <t indent="0" pn="section-9.5-2">The most important examples of such con
ter have typically a variety of mechanisms to do this.</li> figuration include:</t>
<li>Certificate maintenance requires PKI functions. Discovery of these <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9
functions across the ACP is automated (see <xref target="domcert-maint" format= .5-3">
"default"/>), but their configuration is not.</li> <li pn="section-9.5-3.1">When ACP nodes do not support an autonomic wa
<li>When non-ACP capable nodes such as pre-existing NMS need to be phy y to receive an ACP certificate, for example, BRSKI, then such a certificate nee
sically connected to the ACP, the ACP node to which they attach needs to be conf ds to be configured via some preexisting mechanisms outside the scope of this sp
igured with ACP-connect according to <xref target="ACPconnect" format="default"/ ecification. Today, routers typically have a variety of mechanisms to do this.</
>. It is also possible to use that single physical connection to connect both to li>
ACP and the Data-Plane of the network as explained in <xref target="SingleIF" f <li pn="section-9.5-3.2">Certificate maintenance requires PKI function
ormat="default"/>.</li> s. Discovery of these functions across the ACP is automated (see <xref target="d
<li>When devices are not autonomically bootstrapped, explicit configur omcert-maint" format="default" sectionFormat="of" derivedContent="Section 6.2.5"
ation to enable the ACP needs to be applied. See <xref target="enabling-acp" for />), but their configuration is not.</li>
mat="default"/>.</li> <li pn="section-9.5-3.3">When non-ACP-capable nodes such as preexistin
<li>When the ACP needs to be extended across interfaces other than L2, g NMS need to be physically connected to the ACP, the ACP node to which they att
the ACP as defined in this document cannot autodiscover candidate neighbors aut ach needs to be configured with ACP connect according to <xref target="ACPconnec
omatically. Remote neighbors need to be configured, see <xref target="remote-acp t" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. It is als
-neighbors" format="default"/>.</li> o possible to use that single physical connection to connect both to the ACP and
the data plane of the network as explained in <xref target="SingleIF" format="d
efault" sectionFormat="of" derivedContent="Section 8.1.4"/>.</li>
<li pn="section-9.5-3.4">When devices are not autonomically bootstrapp
ed, explicit configuration to enable the ACP needs to be applied. See <xref targ
et="enabling-acp" format="default" sectionFormat="of" derivedContent="Section 9.
3"/>.</li>
<li pn="section-9.5-3.5">When the ACP needs to be extended across inte
rfaces other than L2, the ACP as defined in this document cannot auto-discover c
andidate neighbors automatically. Remote neighbors need to be configured, see <x
ref target="remote-acp-neighbors" format="default" sectionFormat="of" derivedCon
tent="Section 8.2"/>.</li>
</ul> </ul>
<t>Once the ACP is operating, any further configuration for the Data-Pla <t indent="0" pn="section-9.5-4">Once the ACP is operating, any further
ne can be configured more reliably across the ACP itself because the ACP provide configuration for the data plane can be done more reliably across the ACP itself
s addressing and connectivity (routing) independent of the Data-Plane itself. Fo because the ACP provides addressing and connectivity (routing) independent of t
r this, the configuration methods simply need to also allow to operate across th he data plane. For this, the configuration methods simply need to allow operatin
e ACP VRF - NETCONF, SSH or any other method.</t> g across the ACP VRF, for example, with NETCONF, SSH, or any other method.</t>
<t>The ACP also provides additional security through its hop-by-hop encr <t indent="0" pn="section-9.5-5">The ACP also provides additional securi
yption for any such configuration operations: Some legacy configuration methods ty through its hop-by-hop encryption for any such configuration operations. Some
(SNMP, TFTP, HTTP) may not use end-to-end encryption, and most of the end-to-end legacy configuration methods (for example, SNMP, TFTP, or HTTP) may not use end
secured configuration methods still allow for easy passive observation along th -to-end encryption, and most of the end-to-end secured configuration methods sti
e path about configuration taking place (transport flows, port numbers, IP addre ll allow for easy, passive observation along the path of the configuration takin
sses).</t> g place (for example, transport flows, port numbers, and/or IP addresses).</t>
<t>The ACP can and should equally be used as the transport to configure <t indent="0" pn="section-9.5-6">The ACP can and should be used equally
any of the aforementioned non-autonomic components of the ACP, but in that case, as the transport to configure any of the aforementioned non-autonomic components
the same caution needs to be exercised as with Data-Plane configuration without of the ACP, but in that case, the same caution needs to be exercised as with da
ACP: Misconfiguration may cause the configuring entity to be disconnected from ta plane configuration without the ACP. Misconfiguration may cause the configuri
the node it configures - for example when incorrectly unconfiguring a remote ACP ng entity to be disconnected from the node it configures, for example, when inco
neighbor through which the configured ACP node is reached.</t> rrectly unconfiguring a remote ACP neighbor through which the configured ACP nod
e is reached.</t>
</section> </section>
</section> </section>
<section anchor="benefit" numbered="true" toc="default"> <section anchor="benefit" numbered="true" toc="include" removeInRFC="false"
<name>Summary: Benefits (Informative)</name> pn="section-10">
<section anchor="self-healing" numbered="true" toc="default"> <name slugifiedName="name-summary-benefits-informativ">Summary: Benefits (
<name>Self-Healing Properties</name> Informative)</name>
<t>The ACP is self-healing:</t> <section anchor="self-healing" numbered="true" toc="include" removeInRFC="
<ul spacing="compact"> false" pn="section-10.1">
<li>New neighbors will automatically join the ACP after successful val <name slugifiedName="name-self-healing-properties">Self-Healing Properti
idation and will become reachable using their unique ULA address across the ACP. es</name>
</li> <t indent="0" pn="section-10.1-1">The ACP is self-healing:</t>
<li>When any changes happen in the topology, the routing protocol used <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
in the ACP will automatically adapt to the changes and will continue to provide 0.1-2">
reachability to all nodes.</li> <li pn="section-10.1-2.1">New neighbors will automatically join the AC
<li>The ACP tracks the validity of peer certificates and tears down AC P after successful validation and will become reachable using their unique ULA a
P secure channels when a peer certificate has expired. When short-lived certific ddress across the ACP.</li>
ates with lifetimes in the order of OCSP/CRL refresh times are used, then this a <li pn="section-10.1-2.2">When any changes happen in the topology, the
llows for removal of invalid peers (whose certificate was not renewed) at simila routing protocol used in the ACP will automatically adapt to the changes and wi
r speeds as when using OCSP/CRL. The same benefit can be achieved when using CRL ll continue to provide reachability to all nodes.</li>
/OCSP, periodically refreshing the revocation information and also tearing down <li pn="section-10.1-2.3">The ACP tracks the validity of peer certific
ACP secure channels when the peer's (long-lived) certificate is revoked. There ates and tears down ACP secure channels when a peer certificate has expired. Whe
is no requirement against ACP implementations to require this enhancement though n short-lived certificates with lifetimes on the order of OCSP/CRL refresh times
to keep the mandatory implementations simpler.</li> are used, then this allows for removal of invalid peers (whose certificate was
not renewed) at similar speeds as when using OCSP/CRL. The same benefit can be a
chieved when using CRL/OCSP, periodically refreshing the revocation information
and also tearing down ACP secure channels when the peer's (long-lived) certific
ate is revoked. There is no requirement for ACP implementations to require this
enhancement, though, in order to keep the mandatory implementations simpler.</li
>
</ul> </ul>
<t>The ACP can also sustain network partitions and mergers. Practically <t indent="0" pn="section-10.1-3">The ACP can also sustain network parti
all ACP operations are link local, where a network partition has no impact. No tions and mergers. Practically all ACP operations are link local, where a netwo
des authenticate each other using the domain certificates to establish the ACP l rk partition has no impact. Nodes authenticate each other using the domain cert
ocally. Addressing inside the ACP remains unchanged, and the routing protocol i ificates to establish the ACP locally. Addressing inside the ACP remains unchan
nside both parts of the ACP will lead to two working (although partitioned) ACPs ged, and the routing protocol inside both parts of the ACP will lead to two work
.</t> ing (although partitioned) ACPs.</t>
<t>There are few central dependencies: A CRL may not be available during <t indent="0" pn="section-10.1-4">There are a few central dependencies:
a network partition; a suitable policy to not immediately disconnect neighbors a CRL may not be available during a network partition. This can be addressed by
when no CRL is available can address this issue. Also, an ACP Registrar or Cert a suitable policy to not immediately disconnect neighbors when no CRL is availab
ification Authority might not be available during a partition. This may delay r le. Also, an ACP registrar or CA might not be available during a partition. Th
enewal of certificates that are to expire in the future, and it may prevent the is may delay renewal of certificates that are to expire in the future, and it ma
enrollment of new nodes during the partition.</t> y prevent the enrollment of new nodes during the partition.</t>
<t>Highly resilient ACP designs can be built by using ACP Registrars wit <t indent="0" pn="section-10.1-5">Highly resilient ACP designs can be bu
h embedded sub-CA, as outlined in <xref target="sub-ca" format="default"/>. As l ilt by using ACP registrars with embedded sub-CAs, as outlined in <xref target="
ong as a partition is left with one or more of such ACP Registrars, it can conti sub-ca" format="default" sectionFormat="of" derivedContent="Section 9.2.4"/>. As
nue to enroll new candidate ACP nodes as long as the ACP Registrar's sub-CA cert long as a partition is left with one or more of such ACP registrars, it can con
ificate does not expire. Because the ACP addressing relies on unique Registrar-I tinue to enroll new candidate ACP nodes as long as the ACP registrar's sub-CA ce
Ds, a later re-merge of partitions will also not cause problems with ACP address rtificate does not expire. Because the ACP addressing relies on unique Registrar
es assigned during partitioning.</t> -IDs, a later merging of partitions will not cause problems with ACP addresses a
<t>After a network partition, a re-merge will just establish the previou ssigned during partitioning.</t>
s status, certificates can be renewed, the CRL is available, and new nodes can b <t indent="0" pn="section-10.1-6">After a network partition, merging wil
e enrolled everywhere. Since all nodes use the same TA, a re-merge will be smoo l just establish the previous status: certificates can be renewed, the CRL is av
th.</t> ailable, and new nodes can be enrolled everywhere. Since all nodes use the same
<t>Merging two networks with different TA requires the ACP nodes to trus TA, the merging will be smooth.</t>
t the union of TA. As long as the routing-subdomain hashes are different, the a <t indent="0" pn="section-10.1-7">Merging two networks with different TA
ddressing will not overlap. Accidentally, overlaps will only happen in the unlik s requires the ACP nodes to trust the union of TAs. As long as the routing-subd
ely event of a 40-bit hash collision in SHA256 (see <xref target="addressing" fo omain hashes are different, the addressing will not overlap. Overlaps will only
rmat="default"/>). happen accidentally in the unlikely event of a 40-bit hash collision in SHA-256
(see <xref target="addressing" format="default" sectionFormat="of" derivedConten
t="Section 6.11"/>).
Note that the complete mechanisms to merge networks is out of scope of this spec ification.</t> Note that the complete mechanisms to merge networks is out of scope of this spec ification.</t>
<t>It is also highly desirable for implementation of the ACP to be able to run it over interfaces that are administratively down. If this is not feasib le, then it might instead be possible to request explicit operator override upon administrative actions that would administratively bring down an interface acro ss which the ACP is running. Especially if bringing down the ACP is known to di sconnect the operator from the node. For example, any such down administrative action could perform a dependency check to see if the transport connection acros s which this action is performed is affected by the down action (with default RP L routing used, packet forwarding will be symmetric, so this is actually possibl e to check).</t> <t indent="0" pn="section-10.1-8">It is also highly desirable for an imp lementation of the ACP to be able to run it over interfaces that are administrat ively down. If this is not feasible, then it might instead be possible to reque st explicit operator override upon administrative actions that would administrat ively bring down an interface across which the ACP is running, especially if bri nging down the ACP is known to disconnect the operator from the node. For examp le, any such administrative down action could perform a dependency check to see if the transport connection across which this action is performed is affected by the down action (with default RPL routing used, packet forwarding will be symme tric, so this is actually possible to check).</t>
</section> </section>
<!-- self-healing --> <section anchor="self-protecting" numbered="true" toc="include" removeInRF
<section anchor="self-protecting" numbered="true" toc="default"> C="false" pn="section-10.2">
<name>Self-Protection Properties</name> <name slugifiedName="name-self-protection-properties">Self-Protection Pr
<section anchor="self-protecting-outside" numbered="true" toc="default"> operties</name>
<name>From the outside</name> <section anchor="self-protecting-outside" numbered="true" toc="include"
<t>As explained in <xref target="self-creation" format="default"/>, th removeInRFC="false" pn="section-10.2.1">
e ACP is based on secure channels built between nodes that have mutually authent <name slugifiedName="name-from-the-outside">From the Outside</name>
icated each other with their domain certificates. The channels themselves are p <t indent="0" pn="section-10.2.1-1">As explained in <xref target="self
rotected using standard encryption technologies such as DTLS or IPsec which prov -creation" format="default" sectionFormat="of" derivedContent="Section 6"/>, the
ide additional authentication during channel establishment, data integrity and d ACP is based on secure channels built between nodes that have mutually authenti
ata confidentiality protection of data inside the ACP and in addition, provide r cated each other with their domain certificates. The channels themselves are pr
eplay protection.</t> otected using standard encryption technologies such as DTLS or IPsec, which prov
<t>Attacker will not be able to join the ACP unless they have a valid ide additional authentication during channel establishment, data integrity, and
ACP certificate. On-path attackers without a valid ACP certificate cannot inject data confidentiality protection inside the ACP, and also provide replay protecti
packets into the ACP due to ACP secure channels. They can also not decrypt ACP on.</t>
traffic except if they can crack the encryption. They can attempt behavioral tra <t indent="0" pn="section-10.2.1-2">An attacker will not be able to jo
ffic analysis on the encrypted ACP traffic.</t> in the ACP unless it has a valid ACP certificate. An on-path attacker without a
<t>The degree to which compromised ACP nodes can impact the ACP depend valid ACP certificate cannot inject packets into the ACP due to ACP secure chann
s on the implementation of the ACP nodes and their impairment. When an attacker els. An attacker also cannot decrypt ACP traffic unless it can crack the encrypt
has only gained administrative privileges to configure ACP nodes remotely, the a ion. It can attempt behavioral traffic analysis on the encrypted ACP traffic.</t
ttacker can disrupt the ACP only through one of the few configuration options to >
disable it, see <xref target="enabling-acp" format="default"/>, or by configuri <t indent="0" pn="section-10.2.1-3">The degree to which compromised AC
ng of non-autonomic ACP options if those are supported on the impaired ACP nodes P nodes can impact the ACP depends on the implementation of the ACP nodes and th
, see <xref target="workarounds" format="default"/>. Injecting or extracting tra eir impairment. When an attacker has only gained administrative privileges to co
ffic into/from an impaired ACP node is only possible when an impaired ACP node s nfigure ACP nodes remotely, the attacker can disrupt the ACP only through one of
upports ACP connect (see <xref target="ACPconnect" format="default"/>) and the a the few configuration options to disable it (see <xref target="enabling-acp" fo
ttacker can control traffic into/from one of the ACP nodes interfaces, such as b rmat="default" sectionFormat="of" derivedContent="Section 9.3"/>) or by the conf
y having physical access to the ACP node.</t> iguring of non-autonomic ACP options if those are supported on the impaired ACP
<t>The ACP also serves as protection (through authentication and encry nodes (see <xref target="workarounds" format="default" sectionFormat="of" derive
ption) for protocols relevant to OAM that may not have secured protocol stack op dContent="Section 8"/>). Injecting traffic into or extracting traffic from an im
tions or where implementation or deployment of those options fail on some vendor paired ACP node is only possible when an impaired ACP node supports ACP connect
/product/customer limitations. This includes protocols such as SNMP (<xref targ (see <xref target="ACPconnect" format="default" sectionFormat="of" derivedConten
et="RFC3411" format="default"/>), NTP (<xref target="RFC5905" format="default"/> t="Section 8.1"/>), and the attacker can control traffic into/from one of the AC
), PTP (<xref target="IEEE-1588-2008" format="default"/>), DNS (<xref target="RF P node's interfaces, such as by having physical access to the ACP node.</t>
C3596" format="default"/>), DHCPv6 (<xref target="RFC3315" format="default"/>), <t indent="0" pn="section-10.2.1-4">The ACP also serves as protection
syslog (<xref target="RFC3164" format="default"/>), RADIUS (<xref target="RFC286 (through authentication and encryption) for protocols relevant to OAM that may n
5" format="default"/>), Diameter (<xref target="RFC6733" format="default"/>), TA ot have secured protocol stack options or where implementation or deployment of
CACS (<xref target="RFC1492" format="default"/>), IPFIX (<xref target="RFC7011" those options fail due to some vendor, product, or customer limitations. This i
format="default"/>), Netflow (<xref target="RFC3954" format="default"/>) - just ncludes protocols such as SNMP ("<xref target="RFC3411" format="title" sectionFo
to name a few. Not all of these protocol references are necessarily the latest v rmat="of" derivedContent="An Architecture for Describing Simple Network Manageme
ersion of protocols but versions that are still widely deployed.</t> nt Protocol (SNMP) Management Frameworks"/>" <xref target="RFC3411" format="defa
<t>Protection via the ACP secure hop-by-hop channels for these protoco ult" sectionFormat="of" derivedContent="RFC3411"/>), NTP <xref target="RFC5905"
ls is meant to be only a stopgap though: The ultimate goal is for these and othe format="default" sectionFormat="of" derivedContent="RFC5905"/>, PTP (Precision T
r protocols to use end-to-end encryption utilizing the domain certificate and re ime Protocol <xref target="IEEE-1588-2008" format="default" sectionFormat="of" d
ly on the ACP secure channels primarily for zero-touch reliable connectivity, bu erivedContent="IEEE-1588-2008"/>), DNS ("<xref target="RFC3596" format="title" s
t not primarily for security.</t> ectionFormat="of" derivedContent="DNS Extensions to Support IP Version 6"/>" <xr
<t>The remaining attack vector would be to attack the underlying ACP p ef target="RFC3596" format="default" sectionFormat="of" derivedContent="RFC3596"
rotocols themselves, either via directed attacks or by denial-of-service attacks />), DHCPv6 ("<xref target="RFC3315" format="title" sectionFormat="of" derivedCo
. However, as the ACP is built using link-local IPv6 addresses, remote attacks ntent="Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"/>" <xref target="R
from the Data-Plane are impossible as long as the Data-Plane has no facilities t FC3315" format="default" sectionFormat="of" derivedContent="RFC3315"/>), syslog
o remotely send IPv6 link-local packets. The only exceptions are ACP connected ("<xref target="RFC3164" format="title" sectionFormat="of" derivedContent="The B
interfaces which require higher physical protection. The ULA addresses are only SD Syslog Protocol"/>" <xref target="RFC3164" format="default" sectionFormat="of
reachable inside the ACP context, therefore, unreachable from the Data-Plane. " derivedContent="RFC3164"/>), RADIUS ("<xref target="RFC2865" format="title" se
Also, the ACP protocols should be implemented to be attack resistant and not con ctionFormat="of" derivedContent="Remote Authentication Dial In User Service (RAD
sume unnecessary resources even while under attack.</t> IUS)"/>" <xref target="RFC2865" format="default" sectionFormat="of" derivedConte
nt="RFC2865"/>), Diameter ("<xref target="RFC6733" format="title" sectionFormat=
"of" derivedContent="Diameter Base Protocol"/>" <xref target="RFC6733" format="d
efault" sectionFormat="of" derivedContent="RFC6733"/>), TACACS ("<xref target="R
FC1492" format="title" sectionFormat="of" derivedContent="An Access Control Prot
ocol, Sometimes Called TACACS"/>" <xref target="RFC1492" format="default" sectio
nFormat="of" derivedContent="RFC1492"/>), IPFIX ("<xref target="RFC7011" format=
"title" sectionFormat="of" derivedContent="Specification of the IP Flow Informat
ion Export (IPFIX) Protocol for the Exchange of Flow Information"/>" <xref targe
t="RFC7011" format="default" sectionFormat="of" derivedContent="RFC7011"/>), Net
Flow ("<xref target="RFC3954" format="title" sectionFormat="of" derivedContent="
Cisco Systems NetFlow Services Export Version 9"/>" <xref target="RFC3954" forma
t="default" sectionFormat="of" derivedContent="RFC3954"/>) -- just to name a few
. Not all of these protocol references are necessarily the latest version of pro
tocols, but they are versions that are still widely deployed.</t>
<t indent="0" pn="section-10.2.1-5">Protection via the ACP secure hop-
by-hop channels for these protocols is meant to be only a stopgap, though: the u
ltimate goal is for these and other protocols to use end-to-end encryption utili
zing the domain certificate and to rely on the ACP secure channels primarily for
zero-touch reliable connectivity, but not primarily for security.</t>
<t indent="0" pn="section-10.2.1-6">The remaining attack vector would
be to attack the underlying ACP protocols themselves, either via directed attack
s or by denial-of-service attacks. However, as the ACP is built using link-loca
l IPv6 addresses, remote attacks from the data plane are impossible as long as t
he data plane has no facilities to remotely send IPv6 link-local packets. The o
nly exceptions are ACP-connected interfaces, which require greater physical prot
ection. The ULA addresses are only reachable inside the ACP context and therefo
re unreachable from the data plane. Also, the ACP protocols should be implement
ed to be attack resistant and to not consume unnecessary resources even while un
der attack.</t>
</section> </section>
<section anchor="self-protecting-inside" numbered="true" toc="default"> <section anchor="self-protecting-inside" numbered="true" toc="include" r
<name>From the inside</name> emoveInRFC="false" pn="section-10.2.2">
<t>The security model of the ACP is based on trusting all members of t <name slugifiedName="name-from-the-inside">From the Inside</name>
he group of nodes <t indent="0" pn="section-10.2.2-1">The security model of the ACP is b
ased on trusting all members of the group of nodes
that receive an ACP certificate for the same domain. Attacks from the inside b y that receive an ACP certificate for the same domain. Attacks from the inside b y
a compromised group member are therefore the biggest challenge.</t> a compromised group member are therefore the biggest challenge.</t>
<t>Group members must be protected against attackers so that there is no easy way to compromise them, <t indent="0" pn="section-10.2.2-2">Group members must be protected ag ainst attackers so that there is no easy way to compromise them
or use them as a proxy for attacking other devices across the ACP. For example, management plane or use them as a proxy for attacking other devices across the ACP. For example, management plane
functions (transport ports) should only be reachable from the ACP but not the Da functions (transport ports) should be reachable only from the ACP and not from t
ta-Plane. he data plane.
Especially for those management plane functions that have no good protection by This applies especially to those management plane functions that lack
themselves because they secure end-to-end transport and to which the ACP provides both automatic, reliab
do not have secure end-to-end transport and to whom ACP not only provides automa le
tic reliable connectivity and protection against attacks. Protection across all potential
connectivity but also protection against attacks. Protection across all potent attack vectors is typically easier to do in devices whose software is designed f
ial rom the beginning with
attack vectors is typically easier to do in devices whose software is designed f the ACP in mind than in legacy, software-based systems where the ACP is added on
rom the ground up with as another feature.</t>
ACP in mind than with legacy software based systems where the ACP is added on a <t indent="0" pn="section-10.2.2-3">As explained above, traffic across
s another feature.</t> the ACP should still be end-to-end encrypted whenever
<t>As explained above, traffic across the ACP should still be end-to-e possible. This includes traffic such as GRASP, EST, and BRSKI inside the ACP.
nd encrypted whenever This minimizes
possible. This includes traffic such as GRASP, EST and BRSKI inside the ACP. T man-in-the-middle attacks by compromised ACP group members. Such attackers cann
his minimizes ot eavesdrop
man in the middle attacks by compromised ACP group members. Such attackers cann or modify communications, but they can just filter them (which is unavoidable by
ot eavesdrop any means).</t>
or modify communications, they can just filter them (which is unavoidable by any <t indent="0" pn="section-10.2.2-4">See <xref target="compromised" for
means).</t> mat="default" sectionFormat="of" derivedContent="Appendix A.9.8"/> for further c
<t>See <xref target="compromised" format="default"/> for further consi onsiderations on avoiding and dealing with
derations how to avoid and deal with
compromised nodes.</t> compromised nodes.</t>
</section> </section>
</section> </section>
<!-- self-protecting --> <section anchor="admin-view" numbered="true" toc="include" removeInRFC="fa
<section anchor="admin-view" numbered="true" toc="default"> lse" pn="section-10.3">
<name>The Administrator View</name> <name slugifiedName="name-the-administrator-view">The Administrator View
<t>An ACP is self-forming, self-managing and self-protecting, therefore </name>
has minimal dependencies on the administrator of the network. Specifically, sin <t indent="0" pn="section-10.3-1">An ACP is self-forming, self-managing,
ce it is (intended to be) independent of configuration, there is only limited sc and self-protecting; therefore, it has minimal dependencies on the administrato
ope for configuration errors on the ACP itself. The administrator may have the r of the network. Specifically, since it is (intended to be) independent of con
option to enable or disable the entire approach, but detailed configuration is n figuration, there is only limited scope for configuration errors on the ACP itse
ot possible. This means that the ACP must not be reflected in the running confi lf. The administrator may have the option to enable or disable the entire appro
guration of nodes, except a possible on/off switch (and even that is undesirable ach, but detailed configuration is not possible. This means that the ACP must n
).</t> ot be reflected in the running configuration of nodes, except for a possible on/
<t>While configuration (except for <xref target="workarounds" format="de off switch (and even that is undesirable).</t>
fault"/> and <xref target="registrar-considerations" format="default"/>) <t indent="0" pn="section-10.3-2">While configuration (except for <xref
is not possible, an administrator must have full visibility of the ACP and all target="workarounds" format="default" sectionFormat="of" derivedContent="Section
its parameters, to be able to do trouble-shooting. Therefore, an ACP must suppo 8"/> and <xref target="registrar-considerations" format="default" sectionForma
rt all show and debug options, as for any other network function. Specifically, t="of" derivedContent="Section 9.2"/>)
a network management system or controller must be able to discover the ACP, and is not possible, an administrator must have full visibility into the ACP and al
monitor its health. This visibility of ACP operations must clearly be separate l its parameters to be able to troubleshoot. Therefore, an ACP must support all
d from visibility of Data-Plane so automated systems will never have to deal wit show and debug options, as with any other network function. Specifically, an N
h ACP aspects unless they explicitly desire to do so.</t> MS or controller must be able to discover the ACP and monitor its health. This
<t>Since an ACP is self-protecting, a node not supporting the ACP, or wi visibility into ACP operations must clearly be separated from the visibility of
thout a valid domain certificate cannot connect to it. This means that by defau the data plane so automated systems will never have to deal with ACP aspects unl
lt a traditional controller or network management system cannot connect to an AC ess they explicitly desire to do so.</t>
P. See <xref target="NMS" format="default"/> for more details on how to connect <t indent="0" pn="section-10.3-3">Since an ACP is self-protecting, a nod
an NMS host into the ACP.</t> e that does not support the ACP or that does not have a valid domain certificate
cannot connect to it. This means that by default a traditional controller or N
MS cannot connect to an ACP. See <xref target="NMS" format="default" sectionFor
mat="of" derivedContent="Section 8.1.1"/> for details on how to connect an NMS h
ost to the ACP.</t>
</section> </section>
<!-- admin-view -->
</section> </section>
<!-- benefits --> <section anchor="security" numbered="true" toc="include" removeInRFC="false"
<section anchor="security" numbered="true" toc="default"> pn="section-11">
<name>Security Considerations</name> <name slugifiedName="name-security-considerations">Security Considerations
<t>A set of ACP nodes with ACP certificates for the same ACP domain and wi </name>
th ACP functionality enabled is automatically "self-building": The ACP is automa <t indent="0" pn="section-11-1">A set of ACP nodes with ACP certificates f
tically established between neighboring ACP nodes. It is also "self-protecting": or the same ACP domain and with ACP functionality enabled is automatically "self
The ACP secure channels are authenticated and encrypted. No configuration is re -building": the ACP is automatically established between neighboring ACP nodes.
quired for this.</t> It is also self-protecting: the ACP secure channels are authenticated and encryp
<t>The self-protecting property does not include workarounds for non-auton ted. No configuration is required for this.</t>
omic components as explained in <xref target="workarounds" format="default"/>. S <t indent="0" pn="section-11-2">The self-protecting property does not incl
ee <xref target="self-protecting" format="default"/> for details of how the ACP ude workarounds for non-autonomic components as explained in <xref target="worka
protects itself against attacks from the outside and to a more limited degree fr rounds" format="default" sectionFormat="of" derivedContent="Section 8"/>. See <x
om the inside as well.</t> ref target="self-protecting" format="default" sectionFormat="of" derivedContent=
<t>However, the security of the ACP depends on a number of other factors: "Section 10.2"/> for details of how the ACP protects itself against attacks from
</t> the outside and, to a more limited degree, from the inside as well.</t>
<ul spacing="compact"> <t indent="0" pn="section-11-3">However, the security of the ACP depends o
<li>The usage of domain certificates depends on a valid supporting PKI i n a number of other factors:
nfrastructure. If the chain of trust of this PKI infrastructure is compromised, </t>
the security of the ACP is also compromised. This is typically under the contr <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-11-
ol of the network administrator.</li> 4">
<li>ACP nodes receive their certificates from ACP registrars. These ACP <li pn="section-11-4.1">The usage of domain certificates depends on a va
registrars are security critical dependencies of the ACP: Procedures and protoc lid supporting PKI infrastructure. If the chain of trust of this PKI infrastruc
ols for ACP registrars are outside the scope of this specification as explained ture is compromised, the security of the ACP is also compromised. This is typic
in <xref target="registrars-protocols" format="default"/>, only requirements aga ally under the control of the network administrator.</li>
inst the resulting ACP certificates are specified.</li> <li pn="section-11-4.2">ACP nodes receive their certificates from ACP re
gistrars. These ACP registrars are security-critical dependencies of the ACP. P
<li>Every ACP registrar (for enrollment of ACP certificates) and ACP EST rocedures and protocols for ACP registrars are outside the scope of this specifi
server (for renewal of ACP certificates) is a security critical entity and its cation as explained in <xref target="registrars-protocols" format="default" sect
protocols are security critical protocols. Both need to be hardened against atta ionFormat="of" derivedContent="Section 6.11.7.1"/>; only the requirements for th
cks, similar to a CA and its protocols. A malicious registrar can enroll malicio e resulting ACP certificates are specified.</li>
us nodes to an ACP network (if the CA delegates this policy to the registrar) or <li pn="section-11-4.3">Every ACP registrar (for enrollment of ACP certi
break ACP routing for example by assigning duplicate ACP address assignment to ficates) and ACP EST server (for renewal of ACP certificates) is a security-crit
ACP nodes via their ACP certificates.</li> ical entity and its protocols are security-critical protocols. Both need to be h
ardened against attacks, similar to a CA and its protocols. A malicious registra
<li>ACP nodes that are ANI nodes rely on BRSKI as the protocol for ACP r r can enroll malicious nodes to an ACP network (if the CA delegates this policy
egistrars. For ANI type ACP nodes, the security considerations of BRSKI apply. I to the registrar) or break ACP routing, for example, by assigning duplicate ACP
t enables automated, secure enrollment of ACP certificates.</li> addresses to ACP nodes via their ACP certificates.</li>
<li pn="section-11-4.4">ACP nodes that are ANI nodes rely on BRSKI as th
<li>BRSKI and potentially other ACP registrar protocol options require t e protocol for ACP registrars. For ANI-type ACP nodes, the security consideratio
hat nodes have an (X.509v3 based) IDevID. IDevIDs are an option for ACP registra ns of BRSKI apply. It enables automated, secure enrollment of ACP certificates.<
rs to securely identify candidate ACP nodes that should be enrolled into an ACP /li>
domain.</li> <li pn="section-11-4.5">BRSKI and potentially other ACP registrar protoc
ol options require that nodes have an (X.509 v3 based) IDevID. IDevIDs are an op
<li>For IDevIDs to securely identify the node to which it IDevID is assi tion for ACP registrars to securely identify candidate ACP nodes that should be
gned, the node needs to (1) utilize hardware support such as a Trusted Platform enrolled into an ACP domain.</li>
Module (TPM) to protect against extraction/cloning of the private key of the IDe <li pn="section-11-4.6">For IDevIDs to securely identify the node to whi
vID and (2) a hardware/software infrastructure to prohibit execution of non-auth ch its IDevID is assigned, the node needs (1) to utilize hardware support such a
enticated software to protect against malicious use of the IDevID.</li> s a Trusted Platform Module (TPM) to protect against extraction and/or cloning o
f the private key of the IDevID and (2) a hardware/software infrastructure to pr
<li>Like the IDevID, the ACP certificate should equally be protected fro ohibit execution of unauthenticated software to protect against malicious use of
m extraction or other abuse by the same ACP node infrastructure. This infrastruc the IDevID.</li>
ture for IDevID and ACP certificate is beneficial independent of the ACP registr <li pn="section-11-4.7">Like the IDevID, the ACP certificate should equa
ar protocol used (BRSKI or other).</li> lly be protected from extraction or other abuse by the same ACP node infrastruct
ure. This infrastructure for IDevID and ACP certificate is beneficial independen
<li>Renewal of ACP certificates requires support for EST, therefore the t of the ACP registrar protocol used (BRSKI or other).</li>
security considerations of <xref target="RFC7030" format="default"/> related to <li pn="section-11-4.8">Renewal of ACP certificates requires support for
certificate renewal/rekeying and TP renewal apply to the ACP. EST security consi EST; therefore, the security considerations of <xref target="RFC7030" format="d
derations when using other than mutual certificate authentication do not apply n efault" sectionFormat="of" derivedContent="RFC7030"/> related to certificate ren
or do considerations for initial enrollment via EST apply, except for ANI type A ewal and/or rekeying and TP renewal apply to the ACP. EST security consideration
CP nodes because BRSKI leverages EST.</li> s when using other than mutual certificate authentication do not apply, nor do c
onsiderations for initial enrollment via EST apply, except for ANI-type ACP node
<li>A malicious ACP node could declare itself to be an EST server via GR s because BRSKI leverages EST.</li>
ASP across the ACP if malicious software could be executed on it. CA should ther <li pn="section-11-4.9">A malicious ACP node could declare itself to be
efore authenticate only known trustworthy EST servers, such as nodes with hardwa an EST server via GRASP across the ACP if malicious software could be executed o
re protections against malicious software. When Registrars use their ACP certifi n it. The CA should therefore authenticate only known trustworthy EST servers, s
cate to authenticate towards a CA, the id-kp-cmcRA <xref target="RFC6402" format uch as nodes with hardware protections against malicious software. When registra
="default"/> extended key usage attribute allows the CA to determine that the AC rs use their ACP certificate to authenticate towards a CA, the id-kp-cmcRA <xref
P node was permitted during enrollment to act as an ACP registrar. Without the target="RFC6402" format="default" sectionFormat="of" derivedContent="RFC6402"/>
ability to talk to the CA, a malicious EST server can still attract ACP nodes at extended key usage attribute allows the CA to determine that the ACP node was p
tempting to renew their keying material, but they will fail to perform successfu ermitted during enrollment to act as an ACP registrar. Without the ability to t
l renewal of a valid ACP certificate. The ACP node attempting to use the malicio alk to the CA, a malicious EST server can still attract ACP nodes attempting to
us EST server can then continue to use a different EST server, and log a failure renew their keying material, but they will fail to perform successful renewal of
against a malicious EST server.</li> a valid ACP certificate. The ACP node attempting to use the malicious EST serve
r can then continue to use a different EST server and log a failure against a ma
<li>Malicious on-path ACP nodes may filter valid EST server announcement licious EST server.</li>
s across the ACP, but such malicious ACP nodes could equally filter any ACP traf <li pn="section-11-4.10">Malicious on-path ACP nodes may filter valid ES
fic such as the EST traffic itself. Either attack requires the ability to execut T server announcements across the ACP, but such malicious ACP nodes could equall
e malicious software on an impaired ACP node though.</li> y filter any ACP traffic such as the EST traffic itself. Either attack requires
the ability to execute malicious software on an impaired ACP node, though.</li>
<li>In the absence of malicious software injection, an attacker that can <li pn="section-11-4.11">In the absence of malicious software injection,
misconfigure an ACP node which is supporting EST server functionality could att an attacker that can misconfigure an ACP node that supports EST server function
empt to configure a malicious CA. This would not result in the ability to succes ality could attempt to configure a malicious CA. This would not result in the ab
sfully renew ACP certificates, but it could result in DoS attacks by becoming an ility to successfully renew ACP certificates, but it could result in DoS attacks
EST server and making ACP nodes attempting their ACP certificate renewal via th by becoming an EST server and by making ACP nodes attempt their ACP certificate
is impaired ACP node. This problem can be avoided when the EST server implementa renewal via this impaired ACP node. This problem can be avoided when the EST se
tion can verify that the CA configured is indeed providing renewal for certifica rver implementation can verify that the configured CA is indeed providing renewa
tes of the node's ACP. The ability to do so depends on the EST-Server to CA prot l for certificates of the node's ACP. The ability to do so depends on the protoc
ocol, which is outside the scope of this document.</li> ol between the EST server and the CA, which is outside the scope of this documen
t.</li>
</ul> </ul>
<t indent="0" pn="section-11-5">In summary, attacks against the PKI/certif
<t>In summary, attacks against the PKI/certificate dependencies of the ACP can b icate dependencies of the ACP can be minimized by a variety of hardware and/or s
e minimized by a variety of hardware/software components including options such oftware components, including options such as TPM for IDevID and/or ACP certific
as TPM for IDevID/ACP-certificate, prohibitions against execution of non-trusted ate, prohibitions against the execution of untrusted software, and design aspect
software and design aspects of the EST Server functionality for the ACP to elim s of the EST server functionality for the ACP that eliminate configuration-level
inate configuration level impairment.</t> impairment.</t>
<t indent="0" pn="section-11-6">Because ACP peers select one out of potent
<t>Because ACP peers select one out of potentially more than one mutually ially more than one mutually supported ACP secure channel protocols via the appr
supported ACP secure channel protocols via the approach described in <xref targe oach described in <xref target="channel-selection" format="default" sectionForma
t="channel-selection"/>, ACP secure channel setup is subject to downgrade attack t="of" derivedContent="Section 6.6"/>, ACP secure channel setup is subject to do
s by MITM attackers. This can be discovered after such an attack by additional m wngrade attacks by MITM attackers. This can be discovered after such an attack b
echanisms described in <xref target="downgrade"/>. Alternatively, more advanced y additional mechanisms described in <xref target="downgrade" format="default" s
channel selection mechanisms can be devised. [RFC-Editor: Please remove the foll ectionFormat="of" derivedContent="Appendix A.9.9"/>. Alternatively, more advance
owing sentence]. See <xref target="ACPDRAFT"/> Appendix B.1. Both options are ou d channel selection mechanisms can be devised.</t>
t of scope of this document.</t> <t indent="0" pn="section-11-7">The security model of the ACP as defined i
n this document is tailored for use with private PKI. The TA of a private PKI pr
<t>The security model of the ACP as defined in this document is tailored for use ovides the security against maliciously created ACP certificates that give acces
with private PKI. The TA of a private PKI provide the security against maliciou s to an ACP. Such attacks can create fake ACP certificates with correct-looking
sly created ACP certificates to give access to an ACP. Such attacks can create f AcpNodeNames, but those certificates would not pass the certificate path validat
ake ACP certificates with correct looking AcpNodeNames, but those certificates w ion of the ACP domain membership check (see <xref target="certcheck" format="def
ould not pass the certificate path validation of the ACP domain membership check ault" sectionFormat="of" derivedContent="Section 6.2.3"/>, point 2).</t>
(see <xref target="certcheck"/>, point 2).</t> <t indent="0" pn="section-11-8">There is no prevention of source-address s
poofing inside the ACP. This implies that if an attacker gains access to the AC
<t>[RFC-Editor: please remove the following paragraph].</t> P, it can spoof all addresses inside the ACP and fake messages from any other no
<t>Using public CA is out of scope of this document. See <xref target="ACPDRAFT" de. New protocols and/or services running across the ACP should therefore use en
/>, Appendix B.3 for further considerations.</t> d-to-end authentication inside the ACP. This is already done by GRASP as specifi
ed in this document.</t>
<t>There is no prevention of source-address spoofing inside the ACP. This <t indent="0" pn="section-11-9">The ACP is designed to enable automation o
implies that if an attacker gains access to the ACP, it can spoof all addresses f current network management and the management of future autonomic peer-to-peer
inside the ACP and fake messages from any other node. New protocol/services run /distributed networks. Any ACP member can send ACP IPv6 packets to other ACP mem
across the ACP should therefore use end-to-end authentication inside the ACP. T bers and announce via ACP GRASP services to all ACP members without depending on
his is already done by GRASP as specified in this document.</t> centralized components.</t>
<t indent="0" pn="section-11-10">The ACP relies on peer-to-peer authentica
<t>The ACP is designed to enable automation of current network management tion and authorization using ACP certificates. This security model is necessary
and future autonomic peer-to-peer/distributed network automation. Any ACP member to enable the autonomic ad hoc, any-to-any connectivity between ACP nodes. It p
can send ACP IPv6 packet to other ACP members and announce via ACP GRASP servic rovides infrastructure protection through hop-by-hop authentication and encrypti
es to all ACP members without dependency against centralized components.</t> on -- without relying on third parties. For any services where this complete aut
onomic peer-to-peer group security model is appropriate, the ACP certificate can
<t>The ACP relies on peer-to-peer authentication and authorization using A also be used unchanged, for example, for any type of data plane routing protoco
CP certificates. This security model is necessary to enable the autonomic ad-ho l security.</t>
c any-to-any connectivity between ACP nodes. It provides infrastructure protecti <t indent="0" pn="section-11-11">This ACP security model is designed prima
on through hop by hop authentication and encryption - without relying on third p rily to protect against attack from the outside, not against attacks from the in
arties. For any services where this complete autonomic peer-to-peer group securi side. To protect against spoofing attacks from compromised on-path ACP nodes, e
ty model is appropriate, the ACP certificate can also be used unchanged. For exa nd-to-end encryption inside the ACP is used by new ACP signaling: GRASP across t
mple, for any type of Data-Plane routing protocol security.</t> he ACP using TLS. The same is expected from any non-legacy services or protocols
using the ACP. Because no group keys are used, there is no risk of impacted nod
<t>This ACP security model is designed primarily to protect against attack es accessing end-to-end encrypted traffic from other ACP nodes.</t>
from the outside, but not against attacks from the inside. To protect against <t indent="0" pn="section-11-12">Attacks from impacted ACP nodes against t
spoofing attacks from compromised on-path ACP nodes, end-to-end encryption insid he ACP are more difficult than against the data plane because of the autoconfigu
e the ACP is used by new ACP signaling: GRASP across the ACP using TLS. The same ration of the ACP and the absence of configuration options that could be abused
is expected from any non-legacy services/protocols using the ACP. Because no gr to change or break ACP behavior. This is excluding configuration for workaround
oup-keys are used, there is no risk for impacted nodes to access end-to-end encr in support of non-autonomic components.</t>
ypted traffic from other ACP nodes.</t> <t indent="0" pn="section-11-13">Mitigation against compromised ACP member
s is possible through standard automated certificate management mechanisms inclu
<t>Attacks from impacted ACP nodes against the ACP are more difficult than ding revocation and nonrenewal of short-lived certificates. In this specificatio
against the Data-Plane because of the autoconfiguration of the ACP and the abse n, there are no further optimizations of these mechanisms defined for the ACP (b
nce of configuration options that could be abused that allow to change/break ACP ut see <xref target="compromised" format="default" sectionFormat="of" derivedCon
behavior. This is excluding configuration for workaround in support of non-auto tent="Appendix A.9.8"/>).</t>
nomic components.</t> <t indent="0" pn="section-11-14">Higher-layer service built using ACP cert
ificates should not solely rely on undifferentiated group security when another
<t>Mitigation against compromised ACP members is possible through standard model is more appropriate or more secure. For example, central network configura
automated certificate management mechanisms including revocation and non-renewa tion relies on a security model where only a few especially trusted nodes are al
l of short-lived certificates. In this version of the specification, there are n lowed to configure the data plane of network nodes (CLI, NETCONF). This can be d
o further optimization of these mechanisms defined for the ACP (but see <xref ta one through ACP certificates by differentiating them and introducing roles. See
rget="compromised" format="default"/>).</t> <xref target="role-assignments" format="default" sectionFormat="of" derivedConte
nt="Appendix A.9.5"/>.</t>
<t>Higher layer service built using ACP certificates should not solely rel <t indent="0" pn="section-11-15">Operators and developers of provisioning
y on undifferentiated group security when another model is more appropriate/more software need to be aware of how the provisioning and configuration of network d
secure. For example, central network configuration relies on a security model w evices impacts the ability of the operator and/or provisioning software to remot
here only few especially trusted nodes are allowed to configure the Data-Plane o ely access the network nodes. By using the ACP, most of the issues of provisioni
f network nodes (CLI, NETCONF). This can be done through ACP certificates by dif ng/configuration causing connectivity loss of remote provisioning and configurat
ferentiating them and introduce roles. See <xref target="role-assignments" forma ion will be eliminated, see <xref target="self-creation" format="default" sectio
t="default"/>.</t> nFormat="of" derivedContent="Section 6"/>. Only a few exceptions, such as explic
<!-- it physical interface down configuration, will be left. See <xref target="admin-
down" format="default" sectionFormat="of" derivedContent="Section 9.3.2"/>.</t>
<t>Fundamentally, security depends on avoiding operator <t indent="0" pn="section-11-16">Many details of ACP are designed with sec
and network operations automation mistakes, implementation and architecture. Au urity in mind and discussed elsewhere in the document.</t>
tonomic approaches such as the ACP largely eliminate operator mistakes and make <t indent="0" pn="section-11-17">IPv6 addresses used by nodes in the ACP a
it easier to recover from network operations mistakes. Implementation and archit re covered as part of the node's domain certificate as described in <xref target
ectural mistakes are still possible, as in all networking technologies.</t> ="domcert-acpinfo" format="default" sectionFormat="of" derivedContent="Section 6
.2.2"/>. This allows even verification of ownership of a peer's IPv6 address wh
<t>Operators and provisioning software developers need to be aware of how en using a connection authenticated with the domain certificate.</t>
the provisioning/configuration of network devices impacts the ability of the ope <t indent="0" pn="section-11-18">The ACP acts as a security (and transport
rator / provisioning software to remotely access the network nodes. By using the ) substrate for GRASP inside the ACP such that GRASP is not only protected by at
ACP, most of the issues of configuration/provisioning caused loss of connectiv tacks from the outside, but also by attacks from compromised inside attackers --
ity for remote provisioning/configuration will be eliminated, see <xref target=" by relying not only on hop-by-hop security of ACP secure channels, but also by
self-creation" format="default"/>. Only few exceptions such as explicit physical adding end-to-end security for those GRASP messages. See <xref target="GRASP-su
interface down configuration will be left <xref target="admin-down" format="def bstrate" format="default" sectionFormat="of" derivedContent="Section 6.9.2"/>.</
ault"/>.</t> t>
<t indent="0" pn="section-11-19">ACP provides for secure, resilient zero-t
<t>Many details of ACP are designed with security in mind and discussed el ouch discovery of EST servers for certificate renewal. See <xref target="domcer
sewhere in the document:</t> t-maint" format="default" sectionFormat="of" derivedContent="Section 6.2.5"/>.</
<t>IPv6 addresses used by nodes in the ACP are covered as part of the node t>
's domain certificate as described in <xref target="domcert-acpinfo" format="def <t indent="0" pn="section-11-20">ACP provides extensible, autoconfiguring
ault"/>. This allows even verification of ownership of a peer's IPv6 address wh hop-by-hop protection of the ACP infrastructure via the negotiation of hop-by-ho
en using a connection authenticated with the domain certificate.</t> p secure channel protocols. See <xref target="channel-selection" format="defaul
<t>The ACP acts as a security (and transport) substrate for GRASP inside t t" sectionFormat="of" derivedContent="Section 6.6"/>.</t>
he ACP such that GRASP is not only protected by attacks from the outside, but al <t indent="0" pn="section-11-21">The ACP is designed to minimize attacks f
so by attacks from compromised inside attackers - by relying not only on hop-by- rom the outside by minimizing its dependency on any non-ACP (data plane) operati
hop security of ACP secure channels, but adding end-to-end security for those GR ons and/or configuration on a node. See also <xref target="general_addressing"
ASP messages. See <xref target="GRASP-substrate" format="default"/>.</t> format="default" sectionFormat="of" derivedContent="Section 6.13.2"/>.</t>
<t>ACP provides for secure, resilient zero-touch discovery of EST servers <t indent="0" pn="section-11-22">In combination with BRSKI, ACP enables a
for certificate renewal. See <xref target="domcert-maint" format="default"/>.</ resilient, fully zero-touch network solution for short-lived certificates that c
t> an be renewed or reenrolled even after unintentional expiry (e.g., due to interr
<t>ACP provides extensible, auto-configuring hop-by-hop protection of the upted connectivity). See <xref target="bootstrap" format="default" sectionForma
ACP infrastructure via the negotiation of hop-by-hop secure channel protocols. t="of" derivedContent="Appendix A.2"/>.</t>
See <xref target="channel-selection" format="default"/>.</t> <t indent="0" pn="section-11-23">Because ACP secure channels can be long l
ived, but certificates used may be short-lived, secure channels, for example, bu
<t>The ACP is designed to minimize attacks from the outside by minimizing ilt via IPsec, need to be terminated when peer certificates expire. See <xref ta
its dependency against any non-ACP (Data-Plane) operations/configuration on a no rget="Profiles" format="default" sectionFormat="of" derivedContent="Section 6.8.
de. See also <xref target="general_addressing" format="default"/>.</t> 5"/>.</t>
<t indent="0" pn="section-11-24"><xref target="acp-l2-switches-how" format
<t>In combination with BRSKI, ACP enables a resilient, fully zero-touch ne ="default" sectionFormat="of" derivedContent="Section 7.2"/> describes how to im
twork solution for short-lived certificates that can be renewed or re-enrolled e plement a routed
ven after unintentional expiry (e.g., because of interrupted connectivity). See ACP topology operating on what effectively is a large bridge domain when using
<xref target="bootstrap" format="default"/>.</t> L3/L2 routers that operate at L2 in the data plane. In this case, the ACP is
subject to a much higher likelihood of attacks by other nodes "stealing"
<t>Because ACP secure channels can be long lived, but certificates used ma L2 addresses than in the actual routed case, especially when the bridged network
y be short lived, secure channels, for example built via IPsec need to be termin includes untrusted devices such as hosts. This is a generic issue in L2 LANs.
ated when peer certificates expire. See <xref target="Profiles" format="default"
/>.</t>
<t><xref target="acp-l2-switches-how" format="default"/> describes how to
implement a routed
ACP topology operating on what effectively is a large bridge-domain when using
L3/L2 routers that operate at L2 in the Data-Plane. In this case, the ACP is
subject to much higher likelihood of attacks by other nodes "stealing"
L2 addresses than in the actual routed case. Especially when the bridged network
includes non-trusted devices such as hosts. This is a generic issue in L2 LANs.
L2/L3 devices often already have some form of "port security" to prohibit this. They rely on L2/L3 devices often already have some form of "port security" to prohibit this. They rely on
NDP or DHCP learning of which port/MAC-address and IPv6 address belong together and block Neighbor Discovery Protocol (NDP) or DHCP learning which port/MAC-address and IP v6 address belong together and blocking
MAC/IPv6 source addresses from wrong ports. This type of function needs to be MAC/IPv6 source addresses from wrong ports. This type of function needs to be
enabled to prohibit DoS attacks and specifically to protect the ACP. Likewise t he enabled to prohibit DoS attacks and specifically to protect the ACP. Likewise, the
GRASP DULL instance needs to ensure that the IPv6 address in the locator-option matches the source IPv6 address of the DULL GRASP packet.</t> GRASP DULL instance needs to ensure that the IPv6 address in the locator-option matches the source IPv6 address of the DULL GRASP packet.</t>
</section> </section>
<!-- security --> <section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="iana" numbered="true" toc="default"> "section-12">
<name>IANA Considerations</name> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>This document defines the "Autonomic Control Plane".</t> <t indent="0" pn="section-12-1">This document defines the "Autonomic Contr
<t>For the ANIMA-ACP-2020 ASN.1 module, IANA is asked to register ol Plane".</t>
value IANA1 for "id-mod-anima-acpnodename-2020" in the "SMI <t indent="0" pn="section-12-2">For the ANIMA-ACP-2020 ASN.1 module, IANA
has assigned
value 97 for "id-mod-anima-acpnodename-2020" in the "SMI
Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry.</t> Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry.</t>
<t>For the otherName / AcpNodeName, IANA is asked to register a value for IANA2 for <t indent="0" pn="section-12-3">For the otherName / AcpNodeName, IANA has assigned value 10 for
id-on-AcpNodeName in the "SMI Security for PKIX Other Name id-on-AcpNodeName in the "SMI Security for PKIX Other Name
Forms" (1.3.6.1.5.5.7.8) registry.</t> Forms" (1.3.6.1.5.5.7.8) registry.</t>
<t> The IANA is requested to register the value "AN_ACP" (without quotes) <t indent="0" pn="section-12-4">IANA has registered the names in <xref tar
to the GRASP Objectives Names Table in the GRASP Parameter Registry. The get="iana-objnames" format="default" sectionFormat="of" derivedContent="Table 2"
specification for this value is this document, <xref target="discovery-grasp" fo /> in
rmat="default"/>.</t> the "GRASP Objective Names" subregistry of the "GeneRic Autonomic Signaling Prot
<t> The IANA is requested to register the value "SRV.est" (without quotes) ocol (GRASP) Parameters" registry.</t>
to the GRASP Objectives Names Table in the GRASP Parameter Registry. The <table anchor="iana-objnames" align="center" pn="table-2">
specification for this value is this document, <xref target="domcert-maint" form <name slugifiedName="name-grasp-objective-names">GRASP Objective Names</
at="default"/>.</t> name>
<t>Explanation: This document chooses the initially strange looking format <thead>
"SRV.&lt;service-name&gt;" because these objective names would be in line with <tr>
potential future simplification of the GRASP objective registry. Today, every na <th align="left" colspan="1" rowspan="1">Objective Name</th>
me in the GRASP objective registry needs to be explicitly allocated with IANA. I <th align="left" colspan="1" rowspan="1">Reference</th>
n the future, this type of objective names could be considered to be automatical </tr>
ly registered in that registry for the same service for which a &lt;service-name </thead>
h&gt; is registered according to <xref target="RFC6335" format="default"/>. This <tbody>
explanation is solely informational and has no impact on the requested registra <tr>
tion.</t> <td align="left" colspan="1" rowspan="1">AN_ACP</td>
<t> The IANA is requested to create an ACP Parameter Registry with <td align="left" colspan="1" rowspan="1">RFC 8994 (<xref target="dis
currently one registry table - the "ACP Address Type" table.</t> covery-grasp" format="default" sectionFormat="of" derivedContent="Section 6.4"/>
<t>"ACP Address Type" Table. The value in this table are numeric values 0 )</td>
...3 paired with a name (string). Future values MUST be assigned using the Stan </tr>
dards Action policy defined by <xref target="RFC8126" format="default"/>. The f <tr>
ollowing initial values are assigned by this document:</t> <td align="left" colspan="1" rowspan="1">SRV.est</td>
<t> <td align="left" colspan="1" rowspan="1">RFC 8994 (<xref target="dom
0: ACP Zone Addressing Sub-Scheme (ACP RFC <xref target="zone-scheme" format="d cert-maint" format="default" sectionFormat="of" derivedContent="Section 6.2.5"/>
efault"/>) )</td>
</t> </tr>
<t> </tbody>
1: ACP Vlong Addressing Sub-Scheme (ACP RFC <xref target="Vlong" format="default </table>
"/>) / ACP Manual Addressing Sub-Scheme (ACP RFC <xref target="manual-scheme" fo <t indent="0" pn="section-12-6">Explanation: this document chooses the ini
rmat="default"/>) tially strange looking format "SRV.&lt;service-name&gt;" because these objective
</t> names would be in line with potential future simplification of the GRASP object
</section> ive registry. Today, every name in the GRASP objective registry needs to be expl
<!-- iana --> icitly allocated by IANA. In the future, this type of objective names could be c
<section anchor="ack" numbered="true" toc="default"> onsidered to be automatically registered in that registry for the same service f
<name>Acknowledgements</name> or which a &lt;service-name&gt; is registered according to <xref target="RFC6335
<t>This work originated from an Autonomic Networking project at Cisco Syst " format="default" sectionFormat="of" derivedContent="RFC6335"/>. This explanati
ems, which started in early 2010. Many people contributed to this project and t on is solely informational and has no impact on the requested registration.</t>
he idea of the Autonomic Control Plane, amongst which (in alphabetical order): I <t indent="0" pn="section-12-7">IANA has created an "Autonomic Control Pla
gnas Bagdonas, Parag Bhide, Balaji BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, ne (ACP)" registry with
Max Pritikin, Michael Richardson, Ravi Kumar Vadapalli.</t> the subregistry, "ACP Address Type" (<xref target="iana-acpaddresstype" format="
<t>Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and Sheng default" sectionFormat="of" derivedContent="Table 3"/>).</t>
Jiang for their thorough reviews.</t> <table anchor="iana-acpaddresstype" align="center" pn="table-3">
<t>Many thanks Ben Kaduk, Roman Danyliv and Eric Rescorla for their thorou <name slugifiedName="name-initial-values-in-the-acp-a">Initial Values in
gh SEC AD reviews, Russ Housley and Erik Kline for their reviews and to Valery S the "ACP Address Type" Subregistry</name>
myslov, Tero Kivinen, Paul Wouters and Yoav Nir for review of IPsec and IKEv2 pa <thead>
rameters and helping to understand those and other security protocol details bet <tr>
ter. Thanks for Carsten Borman for CBOR/CDDL help.</t> <th align="left" colspan="1" rowspan="1">Value</th>
<t>Further input, review or suggestions were received from: Rene Struik, B <th align="left" colspan="1" rowspan="1">Description</th>
enoit Claise, William Atwood and Yongkang Zhang.</t> <th align="left" colspan="1" rowspan="1">Reference</th>
</section> </tr>
<!-- ack --> </thead>
<tbody>
<section anchor="contributors" numbered="true" toc="default"> <tr>
<name>Contributors</name> <td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">ACP Zone Addressing Sub-Sch
<t>For all things GRASP including validation code, ongoing document text eme/ACP Manual Addressing Sub-Scheme</td>
support and technical input.</t> <td align="left" colspan="1" rowspan="1">RFC 8994 (<xref target="zon
e-scheme" format="default" sectionFormat="of" derivedContent="Section 6.11.3"/>,
<contact fullname="Brian Carpenter" initials="B. E." surname="Carpenter" <xref target="manual-scheme" format="default" sectionFormat="of" derivedContent
> ="Section 6.11.4"/>)</td>
<organization abbrev="Univ. of Auckland"/> </tr>
<address> <tr>
<postal> <td align="left" colspan="1" rowspan="1">1</td>
<street>School of Computer Science</street> <td align="left" colspan="1" rowspan="1">ACP Vlong Addressing Sub-Sc
<street>University of Auckland</street> heme</td>
<street>PB 92019</street> <td align="left" colspan="1" rowspan="1">RFC 8994 (<xref target="Vlo
<city>Auckland</city> ng" format="default" sectionFormat="of" derivedContent="Section 6.11.5"/>)</td>
<region/> </tr>
<code>1142</code> <tr>
<country>New Zealand</country> <td align="left" colspan="1" rowspan="1">2-3</td>
</postal> <td align="left" colspan="1" rowspan="1">Unassigned</td>
<email>brian.e.carpenter@gmail.com</email> <td align="left" colspan="1" rowspan="1"/>
</address> </tr>
</contact> </tbody>
</table>
<t>For RPL contributions and all things BRSKI/bootstrap including valida <t indent="0" pn="section-12-9">The values in the "ACP Address Type" subre
tion code, ongoing document text support and technical input.</t> gistry are numeric values 0..3 paired with a name (string). Future values <bcp1
4>MUST</bcp14> be assigned using the Standards Action policy defined by "<xref t
<contact fullname="Michael C. Richardson" initials="M." surname="Richardson" arget="RFC8126" format="title" sectionFormat="of" derivedContent="Guidelines for
> Writing an IANA Considerations Section in RFCs"/>" <xref target="RFC8126" forma
<organization abbrev="Sandelman">Sandelman Software Works</organization> t="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
<address>
<email>mcr+ietf@sandelman.ca</email>
<uri>http://www.sandelman.ca/mcr/</uri>
</address>
</contact>
<t>For the RPL technology choices and text.</t>
<contact initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization abbrev="Cisco Systems">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>
</contact>
</section>
<!-- contributors -->
<section anchor="changes" numbered="true" toc="default">
<name>Change log [RFC-Editor: Please remove]</name>
<t>This document was developed on <eref target="https://github.com/anima-w
g/autonomic-control-plane/tree/master/draft-ietf-anima-autonomic-control-plane"/
>. That github repository also contains the document review/reply emails.</t>
<section numbered="true" toc="default">
<name>Summary of changes since entering IESG review</name>
<t>This text replaces the prior changelog with a summary to provide guid
ance for further IESG review.</t>
<t>Please see revision -21 for the individual changelogs of prior versio
ns .</t>
<section numbered="true" toc="default">
<name>Reviews (while in IESG review status) / status</name>
<t>This document entered IESG review with version -13. It has since se
en the following reviews:</t>
<t/>
<t>IESG: Original owner/Yes: Terry Manderson (INT).</t>
<t>IESG: No Objection: Deborah Brungard (RTG), Alissa Cooper (GEN), Wa
rren Kumari (OPS), Mirja Kuehlewind (TSV), Alexey Melnikov (ART), Adam Roach (AR
T).</t>
<t>IESG: No Objection, not counted anymore as they have left IESG: Ben
Campbell (ART), Spencer Dawkins (TSV).</t>
<t>IESG: Open DISCUSS hopefully resolved by this version: Eric Rescorl
a (SEC, left IESG), Benjamin Kaduk (SEC).</t>
<t>Other: Michael Richardson (WG), Brian Carpenter (WG), Pascal Thuber
t (WG), Frank Xialiang (WG), Elwyn Davies (GEN), Joel Halpern (RTGdir), Yongkang
Zhang (WG), William Atwood (WG).</t>
</section>
<section numbered="true" toc="default">
<name>BRSKI / ACP registrar related enhancements</name>
<t>Only after ACP entered IESG review did it become clear that the in-
progress BRSKI document would not provide all the explanations needed for ACP re
gistrars as expected earlier by ACP authors. Instead, BRSKI will only specify a
subset of required ACP behavior related to certificate handling and registrar. T
here, it became clear that the ACP draft should specify generic ACP registrar be
havior independent of BRSKI so ACP could be implemented with or without BRSKI an
d any manual/proprietary or future standardized BRSKI alternatives (for example
via NETCONF) would understand the requirements for ACP registrars and its certif
icate handling.</t>
<t>This lead to additional text about ACP registrars in the ACP docume
nt:</t>
<t>1. Defined relationship ACP / ANI (ANI = ACP + BRSKI).</t>
<t>6.1.4 (new) Overview of TA required for ACP.</t>
<t>6.1.5.5 Added explanations/requirements for Re-enrollment.</t>
<t>6.10.7 Normative requirements for ACP registrars (BRSKI or not).</t
>
<t>10.2 Operational expectations against ACP registrars (BRSKI or not)
.</t>
</section>
<section numbered="true" toc="default">
<name>Normative enhancements since start of IESG review</name>
<t>In addition to above ACP registrar / BRSKI related enhancements the
re is a range of minor normative (also explanatory) enhancements since the start
of IESG review:</t>
<t>6.1.1 Hex digits in ACP domain information field now upper-case (no
specific reason except that both options are equally good, but capitalized ones
are used in rfc5234).</t>
<t>6.1.5.3 Added explanations about CRLs.</t>
<t>6.1.5.6 Added explanations of behavior under failing certificates.<
/t>
<t>6.1.2 Allow ACP address '0' in ACP domain information field: presen
ce of address indicates permission to build ACP secure channel to node, 0 indica
tes that the address of the node is assigned by (future) other means than certif
icate. Non-autonomic nodes have no address at all (that was in -13), and can on
ly connect via ACP connect interfaces to ACP.</t>
<t>6.1.3 Distinction of real ACP nodes (with address) and those with d
omain certificate without address added as a new rule to ACP domain membership c
heck.</t>
<t>6.6 Added throttling of secure-channel setup attempts.</t>
<t>6.11.1.14 Removed requirement to handle unknown destination ACP tra
ffic in low-end nodes that would never be RPL roots.</t>
<t>6.12.5 Added recommendation to use IPv6 DAD.</t>
<t>6.1.1, 6.7.1.1, 6.7.2, 6.7.3, 6.8.2 Various refined additional cert
ificate, secure channel protocol (IPsec/IKEv2 and DTLS) and ACP GRASP TLS protoc
ol parameter requirements to ensure interoperating implementations (from SEC-AD
review).</t>
</section>
<section numbered="true" toc="default">
<name>Explanatory enhancements since start of IESG review</name>
<t>Beyond the functional enhancements from the previous two sections,
the mayority of changes since -13 are additional explanations from review feedba
ck, textual nits and restructuring - with no functional requirement additions/ch
anges.</t>
<t>1.1 Added "applicability and scope" section with summarized explana
tions.</t>
<t>2.Added in-band vs. out-of-band management definitions.</t>
<t>6.1.2 (was 6.1.1) expanded explanations of reasoning for elements o
f the ACP domain information field.</t>
<t>6.1.3 refined explanations of ACP domain membership check and justi
fications for it.</t>
<t>6.5 Elaborated step-by-step secure channel setup.</t>
<t>6.10 Additional explanations for addressing modes, additional tabl
e of addressing formats (thanks MichaelR).</t>
<t>6.10.5 introduced 'F' bit position as a better visual representatio
n in the Vlong address space.</t>
<t>6.11.1.1 extensive overhaul to improve readability of use of RPL (f
rom IESG feedback of non-routing/RPL experts).</t>
<t>6.12.2 Added caution about unconfiguring Data-Plane IPv6 addresses
and impact to ACP (limitation of current ACP design, and pointint to more detail
s in 10.2).</t>
<t>10.4 New explanations / summary of configurations for ACP (aka: all
config is undesirable and only required for integrating with non-autonomic comp
onents, primarily ACP-connect and Registrars).</t>
<t>11. Textually enhanced / better structured security considerations
section after IESG security review.</t>
<t>A. (new) Moved all explanations and discussions about futures from
section 10 into this new appendix. This text should not be removed because it ca
ptures a lot of repeated asked questions in WG and during reviews and from users
, and also captures ideas for some likely important followup work. But none of t
his is relevant to implementing (section 6) and operating (section 10) the ACP.<
/t>
</section>
</section>
<section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-30</name>
<t>-29 did pass all IESG DISCUSS. This version cleans up reamining comme
nts.</t>
<t>Planned to be removed section Appendix A.6 was moved into new Appendi
x B.1 to be amended by further A.2, A.3 containing text felt to be unfit for pub
lication in RFC (see below). Added reference to this last draft, and referencing
those sections ([ACPDRAFT]).</t>
<t>Final discussion with responsible AD (Eric Vyncke): marked all refere
nces to [ACPDRAFT] as to be removed from RFC,
as this would be too unconventional. Likewise also [ACPDRAFT] reference itself.
Added explanation to appendix B.</t>
<t>Comments from Erik Kline:</t>
<t>2. Fine tuned ULA definition.</t>
<t>Comments Michael Richardson / Eric Vyncke.</t>
<t>6.2.4. / 11. Removed text arguing ability how to use public CA (or no
t). Replaced with reference to new [ACPDRAFT] section B.3 (not in RFC) that expl
ains current state of understanding (unfinished).</t>
<t>B.3 New text detailling authors understanding of use of public CA (wi
ll not be in RFC).</t>
<t>Comments/proposals from Ben Kaduk:</t>
<t>Various: Replaced RFC4492 with RFC8422 which is superceeding it.</t>
<t>6.1 Text fix for hash strength 384 bits (from SHA384); Text fix for e
c_point_format extension.</t>
<t>6.2.1 Text fixup. Removed requirements for ECDH support in certificat
e, instead merely explaining the dependencies required IF this is desired (educa
tional).</t>
<t>6.2.5.4. Fine tuning 2 sentences.</t>
<t>6.3.2. (ACP domain memebership check) Add reference to ACPDRAFT B.2 e
xplaining why ACP domain membership does not validate ACP address of the connect
ion.</t>
<t>6.4. Downgraded SHOULD to MAY in new -29 suggestion how to deal with
DoS attacks with many GRASP announcements. Will also separately ask TSV ADs.</t>
<t>6.4. Fixed extension points in CDDL objective-value definitions (with
help from Carsten/Brian).</t>
<t>9.3.5.2. Added explanation when ACP greenfield state ends, and refine
d text explaining how to deal with this.</t>
<t>11. removed duplicate paragraph (first, kept paragraph was the fixed
up, improved correct version).</t>
<t>11. Added references to ACPDRAFT B.1, B.2 as possible future solution
s for downgrade attacks.</t>
<t>12. Fixed up text for IANA code point allocation request.</t>
<t>A.6 - removed.</t>
<t>A.9.9 - added one explanatory intro paragraph to makes it easier to d
istinguish this option from the B.1 considerations.</t>
<t>B.1 - new text suggested from Ben, replacing A.6 (will not be in RFC)
.</t>
<t>B.2 - new text discussing why there is no network layer address verif
ication in ACP domain membership check (will not be in RFC).</t>
<t>B.4 - Text discussing DULL GRASP attacks via port sweeps and what do
do against it.</t>
<t>Other.</t>
<t>1. Added sentence about FCC outage report from June as example for in
-band management.</t>
<t>15. added reference to github where document was developed (removed i
n RFC, part of changelog).</t>
</section>
<section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-29</name>
<t>Comments from Robert Wilton:</t>
<t>Improved several textual nits.</t>
<t>Discuss/Comments from Erik Kline:</t>
<t>Editorial suggestions and nits. Thanks!.</t>
<t>6.1.3 Added text about how/why rsub is irrelevant for domain membersh
ip check.</t>
<t>6.3 Added extension points to AN_ACP DULL GRASP objective because for
example ACP domain certificate could be a nice optional additional parameter an
d prior syntax would have forced us to encode into separate objective unnecessar
ily.</t>
<t>6.7 Using RFC8415 terminology for exponential backoff parameters.</t>
<t>6.11.2 Amended ACP Sub-Addressing table with future code points, expl
anations and prefix announced into RPL.</t>
<t>6.12.1.11. Reworked text to better explain how black hole route works
and added expanation for prefix for manual address scheme.</t>
<t>8.1.3. Reworked explanation of RIOs for ACP connect interfaces for Ty
pe C vs. Type A/B hosts.</t>
<t>8.1.4. Added explanation how this "VRF select" option is required for
auto-attachment of Type A/B hosts to ACP and other networks.</t>
<t></t>
<t>Discuss/Comments from Barry Leiba:</t>
<t>Various editorial nits - thanks.</t>
<t>6.1 New section pulling in TLS requirements, no need anymore to dupli
cat for ACP GRASP, EST, BRSKI (ACP/ANI nodes) and (if desired) OCSP/CRLDP. Added
rule to start use secure channel only after negotiation has finished. Added rul
es not to optimize negotiation across multiple L2 interfaces to the same peer.</
t>
<t>6.6 Changed role names in secure channel negotiation process: Alice/B
ob -> Decider/Follower. Explanation enhancements. Added definition for ACP nodes
with "0" address.</t>
<t>6.8.3 Improved explanation how IKEv2 forces preference of IPsec over
GRE due to ACP IPsec profiles being Tunneled vs. Transport.</t>
<t>6.8.4 Limited mentioning of DTLS version requirements to this section
.</t>
<t>6.9.2 Removed TLS requirements, they are now in 6.1.</t>
<t>6.10.6 Removed explanation of IANA allocation requirement. Redundant
- already in IANA section, and was seen as confusing.</t>
<t>8.1.1 Clarified that there can be security impacts when weakening dir
ectly connected address RPF filtering for ACP connect interfaces.</t>
<t></t>
<t>Discuss/Comments from Ben Kaduk:</t>
<t>Many good editorial improvements - thanks!.</t>
<t>5. added explanation of what to do upon failed secure channel establi
shment.</t>
<t>6.1.1. refined/extended cert public cey crypto algo and better distin
guished algo for the keys of the cert and the key of the signer.</t>
<t>6.1.1. and following: explicitly defining "serialNumber" to be the X.
520 subject name serialNumber, not the certificate serial Number.</t>
<t> 6.1.1. emhasize additional authorization step for EST servers (id-kp
-cmcRA).</t>
<t>6.1.2 changed AcpNodeName ABNF to again use 32HEXDIG instead of self-
defined variation, because authors overlooked that ABNF is case agnostic (which
is fine). Added recommendation to encode as lower case. Added full ABNF encoding
for extensions (any characters as in "atoms" except the new "+" separator).</t>
<t>6.1.5.3. New text to explain reason for use of HTTPS (instead of HTTP
) for CRLDP and when and how to use HTTPS then.</t>
<t>6.1.5.5. added text explaning why/how and when to maintain TA data up
on failing cert renewal (one version with BRSKI, one version with other, ess sec
ure bootstrap protocols).</t>
<t>6.3. new text and requirement about the signaling of transport ports
in DULL GRASP - benefits (no well-known ports required), and problems (additiona
l DoS attack vector, albeit not worse than pre-existing ones, depending on setup
of L2 subnets.).</t>
<t>6.7.3.1.1. Specified AUTH_HMAC_SHA2_256_128 (as the ESP authenticatio
n algorithm).</t>
<t>6.8.2. Added recommendations for TLS_AES_256_GCM_SHA384, TLS_CHACHA20
_POLY1305_SHA256 when supporting TLS 1.3.</t>
<t>8.2.2. Added explanation about downgrade attack across configured ACP
tunnels and what to do against it.</t>
<t>9.3.5.2. Rewrote most of section as it originally was too centric on
BRSKI. Should now well describe expectations against automated bootstrap. Introd
uces new requirement not to call node as in support of ANI if is ALSO has TOFU b
ootstrap.</t>
<t>11. Expanded text about malicious EST servers. Added paragraph about
ACP secure channel downgrade attacks. Added paragraphs about private PKI as a co
re to allow security against fake certificates, added paragraph about considerat
ionsproblems when using public PI.</t>
<t>A.10.9 New appendix suggesting how to discover ACP secure channel neg
otiation downgrade attacks.</t>
<t></t>
<t>Discuss from Roman Danyliw:</t>
<t>6.1.5.1 - Added requirement to only announce SRV.est when a working C
A connection.</t>
<t>15 - Amended security considerations with text about registrar depend
encies, security of IDevID/ACP-certificate, EST-Server and GRASP for EST server
discovery.</t>
<t>Other:</t>
<t>Conversion to XML v3. Solved empty () taxonomy xref problems. Various
formatting fixes for v3.</t>
<t>Added contributors section.</t>
</section>
<section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-28</name>
<t>IESG review Roman Danyliw:</t>
<t>6. Requested additional text elaborating misconfiguration plus attack
vectors.</t>
<t>6.1.3.1 Added paragraph about unsecured NTP as basis for time in the
absence of other options.</t>
<t>6.7.2 reworded text about additional secure channel protocol reqiurem
ents.</t>
<t> 6.7.3.1.2. Added requirement for ACP nodes supporting IKEv2 to suppo
rt RFC8247 (not sure how that got dropped from prior versions.</t>
<t>Replaced minimum crypto requirements definition via specific AES opti
ons with more generic "symmetric key/hash strength" requirements.</t>
<t>6.10.7.3. Added example how to derive addressing scheme from IDevID (
PID). Added explanation how to deal with non-persistant registrar address databa
se (hint: it sucks or is wasteful, what did you expect).</t>
<t>8.1.1. Added explanation for 'Physical controlled/secured'.</t>
<t>8.1.5. Removed 'Physical controlled/secured' text, refer back to 8.1.
1.</t>
<t>8.2.1. Fixed ABNF 'or' syntax line.</t>
<t>9.3.2. Added explanation of remote management problem with interface
"down" type commands.</t>
<t>10.2.1. Added explanations for attacks from impaired ACP nodes.</t>
<t>11. Rewrote intro paragraph. Removed text referring to enrollment/reg
istrars as they are out of scope of ACP (dependencies only).</t>
<t>11. Added note about need for new protocols inside ACP to use end-to-
end authentication.</t>
<t>11. Rewrote paragraph about operator mistakes so as to be actionably.
Operators must not make mistakes - but ACP minimizes the mistakes they can make
.</t>
<t>ACP domain certificate -&gt; ACP certificate.</t>
<t>Various other cosmetic edits (thanks!) and typo fixes (sorry for not
running full spell check for every version. Will definitely do before RFC editor
).</t>
<t>Other:</t>
<t>6.12.5.2.1./6.12.5.2.2. Added text explaining link breakage wrt. RTL
(came about re-analyzing behavior after question about hop count).</t>
<t>Removed now unnecessary references for earlier rrc822Name otherName c
hoice.</t>
</section>
<section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-27</name>
<t>Too many revisions with too many fixes. Lets do a one-word change rev
ision for a change now if it helps to accelerate the review process.</t>
<t>Added "subjectAltName /" to make it unambiguous that AcpNodeName is i
ndeed a SAN (from Russ).</t>
</section>
<section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-26</name>
<t>Russ Housley review of -25.</t>
<t>1.1 Explicit reference for TLS 1.2 RFC.</t>
<t>2. Changed term of "ACP Domain Information" to AcpNodeName (ASN.1) /
acp-node-name (ABNF), also through rest of document.</t>
<t>2. Improved CA behavior definition. changed IDevID/LDevID to IDevID/
LDevID certificate to be more unambiguous.</t>
<t>2. Changed definition of root CA to just refer to how its used in RF
C7030 CA root key update, because thats the only thing relevant to ACP.</t>
<t>6.1.1 Moved ECDH requirement to end of text as it was not related to
the subject of the initial paragraps. Likewise reference to CABFORUM.</t>
<t>6.1.1 Reduced cert key requirements to only be MUST for certs with 20
48 RSA public key and P-256 curves. Reduced longer keys to SHOULD.</t>
<t>6.1.2 Changed text for conversion from rfc822Name to otherName / AcpN
ode, removed all the explanations of benefits coming with rfc822Name *sob* *sob*
*sob*.</t>
<t>6.1.2.1 New ASN.1 definition for otherName / AcpNodeName.</t>
<t>6.1.3 Fixed up text. re the handling of missing connectivity for CRLD
P / OCSP.</t>
<t>6.1.4 Fixed up text re. inability to use public CA to situation with
otherName / AcpNodeName (no more ACME rfc822Name validation for us *sob* *sob* *
sob*).</t>
<t>12. Added ASN.1 registration requests to IANA section.</t>
<t>Appenices. Minor changes for rfc822Name to otherName change.</t>
<t>Various minor verbal fixes/enhancements.</t>
</section>
<section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-25</name>
<t>Crypto parameter discuss from Valery Smyslov and Paul Wouters and res
ulting changes.</t>
<t>6.7.2 Moved Michael Richardson suggested diagnostic of signaling TA f
rom IPsec section to this general requirements section and added explanation how
this may be inappropriate if TA payload is considered secret by TA owner.</t>
<t>6.7.3.1 Added traffic selectors for native IPsec. Improved text expla
nation.</t>
<t>6.7.3.1.2 removed misleading text about signaling TA when using inter
mediate certs.</t>
<t>6.7.3.1.2 Removed requirement for 'PKCS #7 wrapped X.509 certificate'
requirement on request of Valery Smyslov as it is not defined in RFC7296 and th
ere are enough options mandated in RFC7296. Replaced with just informative text
to educate readers who are not IPsec experts what the mandatory option in RFC729
6 is that allows to signal certificates.</t>
<t>6.7.3.1.2 Added SHOULD requirement how to deal with CERTREQ so that 6
.7.2 requirement for TA diagnostics will work in IKEv2 (ignoring CERTREQ is perm
itted by IKEv2). Added explanation how this will result in TA cert diagnostics.<
/t>
<t>6.7.3.1.2 Added requirement for IKEv2 to operate on link-local addres
ses for ACP so at to assume ACT cert as the only possible authenticator - to avo
id potentialy failing section from multiple available certs on a router.</t>
<t>6.7.3.1.2 fixed PKIX- style OID to ASN.1 object AlgorithmIdentifier (
Paul).</t>
<t>6.7.3.2 Added IPsec traffic selectors for IPsec with GRE.</t>
<t>6.7.5 Added notion that IPsec/GRE MAY be preferred over IPsec/native.
Luckily IPsec/native uses tunneling, whereas IPsec/GRE uses transport mode, and
there is a long discuss whether it is permitted to even build IPsec connectings
that only support transports instead of always being able to fall back to tunne
l mode. Added explanatory paragraph why ACP nodes may prefer GRE over native (wo
nder how that was missing..).</t>
<t>9.1.1 Added section to explain need for secure channel peer diagnosti
cs via signaling of TA. Four examples given.</t>
<t>Paul Wouters mentioned that ipkcs7 had to be used in some interop cas
es with windows CA, but that is an issue of ACP Registrar having to convert into
PKCS#7 to talk to a windows CA, and this spec is not concerned with that, excep
t to know that it is feasible, so not mentioned in text anywhere, just tracking
discussion here in changelog.</t>
<t/>
<t>Michael Richardson:</t>
<t>3.1.3 Added point in support of rfc822address that CA may not support
to sign certificates with new attributes (such as new otherName).</t>
<t/>
<t>Michael Richardson/Brian Carpenter fix:</t>
<t>6.1.5.1/6.3 Fixed GRASP examples.</t>
<t/>
<t>Joe Halpern review:</t>
<t>1. Enhanded introduction text for in-band and of out-of-band, explain
ing how ACP is an in-band network aiming to achieve all possible benefits of an
out-of-band network.</t>
<t>1. Comprehensive explanation for term Data-Plane as it is only logica
lly following pre-established terminology on a fully autonomic node, when used f
or existing nodes augmented with ACP, Data-Plane has more functionality than usu
ally associated with the term.</t>
<t>2. Removed explanatory text for Data-Plane, referring to section 1.</
t>
<t>2. Reduced explanation in definition of in-band (management/signaling
), out-of-band-signaling, now pointing to section 1.</t>
<t>5. Rewrote a lot of the steps (overview) as this text was not reviewe
d for long time. Added references to normative section for each step to hopefull
y avoid feedback of not explaining terms used (really not possible to give good
summary without using forward references).</t>
<t>2. Separate out-of-band-management definition from virtual out-of-ban
d-management definition (later one for ACP).</t>
<t>2. Added definitions for RPI and RPL.</t>
<t>6.1.1. added note about end-to-end authentication to distinguish chan
nel security from overall ACP security model.</t>
<t>6.5 Fixed bugs in channel selection signaling step description (Alice
vs. Bob).</t>
<t>6.7.1 Removed redundant channel selection explanation.</t>
<t>6.10.3 remove locator/identifier terminology from zone addressing sch
eme description (unnecessary), removed explanations (now in 9.4), simplified tex
t, clarified requirement for Node-ID to be unique, recommend to use primarily zo
ne 0.</t>
<t>6.10.3.1 Removed. Included a lot of insufficient suggestions for futu
re stanards extensions, most of it was wrong or would need to be revisited by WG
anyhow. Idea now (just here for comment): Announce via GRASP Zone-ID (e.g. from
per-zone edge-node/registrar) into a zone of the ACP so all nodes supporting th
e scheme can automatically self-allocate the Zone-ID.</t>
<t>6.11.1.1 (RPL overview), eliminated redundant text.</t>
<t>6.11.1.1.1 New subsection to better structure overview.</t>
<t>6.11.1.1.2 New subsection to better group overview, replaced TTL expl
anation (just the symptom) with hopefully better reconvergence text (intent of t
he profile) for the ACP RPL profile.</t>
<t>6.11.1.1.6 Added text to explain simple choice for rank_factor.</t>
<t>6.11.1.13 moved explanation for RPI up into 6.11.1.1.</t>
<t>6.12.5.1 rewrote section for ACP Loopback Interface.</t>
<t>9.4 New informative/informational section for partial or incremental
adoption of ACP to help understand why there is the Zone interface sub-scheme, a
nd how to use it.</t>
<t/>
<t>Unrelated fixes:</t>
<t>Ask to RFC editor to add most important abbreviations to RFC editor a
bbreviation list.</t>
<t>6.10.2 changed names in ACP addressing scheme table to be less sugges
tive of use.</t>
<t>Russ Hously review:</t>
<t>2. Fixed definition of "Enrollment", "Trust Anchor", "CA", and "root
CA". Changed "Certificate Authority" to "Certification Authority" throughout the
document (correct term according to X.509).</t>
<t>6.1 Fixed explanation of mutual ACP trust.</t>
<t>6.1.1 s/X509/X509v3/.</t>
<t>6.1.2 created bulleted lists for explanations and justifications for
choices of ACP certificate encoding. No semantic changes, just to make it easier
to refer to the points in discussions (rfcdiff seems to have a bug showing text
differences due to formatting changes).</t>
<t>6.1.3 Moved content of rule #1 into previous rule #2 because certific
ation chain validation does imply validation of lifetime. numbers of all rules r
educed by 1, changed hopefully all references to the rule numbers in the documen
t.</t>
<t> Rule #3, Hopefully fixed linguistic problem self-contradiction
of MUST by lower casing MUST in the explanation part and rewriting the condition
when this is not applicable.</t>
<t>6.1.4 Replaced redundant term "Trust Point" (TP) with Trust Anchor (T
A"). Replaced throughout document Trust Anchor with abbreviation TA.</t>
<t> Enhanced several sentences/rewrote paragraphs to make explanati
ons clearer.</t>
<t>6.6 Added explanation how ACP nodes must throttle their attempts for
connection making purely on the result of their own connection attempts, not bas
ed on those connections where they are responder.</t>
<t/>
</section>
<section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-24</name>
<t>Leftover from -23 review by Eric Vyncke:</t>
<t>Swapping sections 9 and 10, section 9 was meant to be at end of docum
ent and summarize. Its not meant to be misinterpreted as introducing any new inf
ormation. This did happen because section 10 was added after section 9.</t>
</section>
<section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-23</name>
<t>Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal.</
t>
<t>Review of IPsec security with Mcr and ipsec mailing list.</t>
<t>6.7.1 - new section: Moved general considerations for secure channel
protocols here, refined them.</t>
<t>6.7.2 - new section: Moved common requirements for secure channel pro
tocols here, refined them.</t>
<t>6.7.3.1.1. - improved requirements text related to RFC8221, better ex
plamations re. HW acceleration issues.</t>
<t>6.7.3.1.2. - improved requirements text related to RFC8247, (some req
uirements still discussed to be redundant, will be finalized in next weeks.</t>
<t/>
<t>Eric Vyncke review of -21:</t>
<t> Only noting most important changes, long list of smaller text/readab
ility enhancements.</t>
<t>2. - New explanation of "normative", "informational" section title ta
gs. alphabetic reordering of terms, refined definitions for CA, CRL. root CA.</t
>
<t>6.1.1. - explanation when IDevID parameters may be copied into LDevID
.</t>
<t>6.1.2. - Fixed hex digits in ACP domain information to lower case.</t
>
<t>6.1.3.1. - New section on Realtime clock and Time Validation.</t>
<t>6.3 - Added explanation that DTLS means &gt;= version 1.2 (not only 1
.2).</t>
<t>6.7 - New text in this main section explaing relationship of ACP secu
re channels and ACP virtual interfaces - with forward references to virtual inte
rface section.</t>
<t>6.8.2 - reordered text and picture, no text change.</t>
<t>6.10.7.2 - describe first how Registrar-ID can be allocted for all ty
pe of registrars, then refined text for how to potentially use MAC addresses on
physical registrars.</t>
<t>6.11.1.1 - Added text how this profile does not use Data-Plane artefa
cts (RPI) because hadware forwarding. This was previously hidden only later in t
he text.</t>
<t>6.11.1.13. - Rewrote RPL Data-Plane artefact text. Provide decoder ri
ng for abbreviations and all relevant RFCs.</t>
<t>6.12.5.2. - Added more explicit text that secure channels are mapped
into virtual interfaces, moved different type of interfaces used by ACP into sep
arate subsections to be able to refer to them.</t>
<t>7.2 - Rewrote/refined text for ACP on L2, prior text was confusing an
d did not well explain why ACP for L2/L3 switches can be implemented without any
L2 (HW) changes. Also missing explanation of only running GRASP untagged when V
LANs are used.</t>
<t>8.1.1 - Added requirement for ACP Edge nodes to allow configurable fi
ltering of IPv6 RPI headers.</t>
<t>11. - (security section). Moved explanation of address stealing from
7.2 to here.</t>
</section>
<section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-22</name>
<t>Ben Kaduk review of -21:</t>
<t>RFC822 encoding of ACP domain information:</t>
<t>6.1.2 rewrote text for explaining / justifying use of rfc822name as i
dentifier for node CP in certificate (was discussed in thread, but badly written
in prior versions).</t>
<t>6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is th
e known primary name to extensions separator in many email systems ("." was wron
g in prior versions).</t>
<t>6.1.2 Rewrote/improved explanations for use of rfc822name field to ex
plain better why it is PKIX compliant and the right thing to do.</t>
<t>Crypto parameters for IPsec:</t>
<t>6.1 - Added explanation of why manual keying for ACP is not feasible
for ACP. Surprisingly, that text did not exist. Referred to by IPsec text (6.7.1
), but here is the right place to describe the reasoning.</t>
<t>6.1.2 - Small textual refinement referring to requirements to authent
icate peers (for the special cases of empty or '0' ACP address in ACP domain inf
ormation field.</t>
<t>6.3 - To better justify Bens proposed change of secure channel protoc
ol being IPsec vs. GRASP objective being IKEv2, better explained how protocol in
dicated in GRASP objective-value is name of protocol used to negotiate secure ch
annel, use example of IKEv2 to negotiate IPsec.</t>
<t>6.7.1 - refinemenet similar to 6.3.</t>
<t> - moved new paragraph from Bens pull request up from 6.7.1.1 to 6.7.
1 as it equally applies to GRE encapped IPsec (looks nicer one level up).</t>
<t>- created subsections 6.7.1.1 (IPsec/ESP) / 6.7.1.2 (IKEv2) to cleare
r distinguish between these two requirements blocks.</t>
<t>- Refined the text in these two sections to hopefully be a good answe
r to Valery's concern of not randomnly mocking with existing requirements docs (
rfc8247 / rfc8221).</t>
<t>6.7.1.1.1 - IPsec/ESP requirements section:</t>
<t>- MUST support rfc8221 mandatory EXCEPT for the superceeding requirem
ents in this section. Previously, this was not quite clear from the text.</t>
<t>- Hopefully persuasive explanations about the requirements levels for
ENCR_AES_GCM_16, ENCR_AES_CBC, ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY1305: Restr
uctured text for why not ENCR_AES_CBC (was in prior version, just not well struc
tured), added new expanations for ENCR_AES_CCM_8 and ENCR_CHACHA20_POLY130.</t>
<t>- In simple terms, requirements for ENCR_AES_CBC, ENCR_AES_CCM_8, ENC
R_CHACHACHA are SHOULD when they are implementable with rqual or faster performa
ncce than ENCR_AES_GCM_16.</t>
<t>- Removed text about "additional rfc8221" reqiurements MAY be used. N
ow the logic is that all other requirements apply. Hopefully we have written eno
ugh so that we prohibited downgrades.</t>
<t>6.7.1.1.2 - RFC8247 requirements:</t>
<t>- Added mandate to support rfc8247, added explanation that there is n
o "stripping down" requirement, just additional stronger requirements to mandate
correct use of ACP certificartes during authentication.</t>
<t>- refined text on identifying ACP by IPv6 address to be clearer: Iden
tifying in the context of IKEv2 and cases for '0' in ACP domain information.</t>
<t>- removed last two paragraphs about relationship to rfc8247, as his i
s now written in first paragraph of the section.</t>
<t>End of Ben Kaduk review related fixes.</t>
<t> Other:</t>
<t>Forgot to update example of ACP domain information to use capitalized
hex-digits as required by HEXDIG used.</t>
<t>Added reference to RFC8316 (AN use-cases) to beginning of section 3 (
ACP use cases).</t>
<t>Small Enhanced IPsec parameters description / requirements fixes (fro
m Michael Richardson).</t>
</section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <displayreference target="I-D.ietf-tls-dtls13" to="TLS-DTLS13"/>
<name>Normative References</name> <displayreference target="I-D.eckert-anima-noc-autoconfig" to="NOC-AUTOCONFI
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc103 G"/>
4"> <displayreference target="I-D.ietf-roll-applicability-template" to="ROLL-APP
<front> LICABILITY"/>
<title>Domain names - concepts and facilities</title> <references pn="section-13">
<seriesInfo name="DOI" value="10.17487/RFC1034"/> <name slugifiedName="name-references">References</name>
<seriesInfo name="RFC" value="1034"/> <references pn="section-13.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="IKEV2IANA" target="https://www.iana.org/assignments/i
kev2-parameters" quoteTitle="true" derivedAnchor="IKEV2IANA">
<front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<author fullname="IANA">
<organization showOnFrontPage="true"/>
</author>
<date/>
</front>
</reference>
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
034" quoteTitle="true" derivedAnchor="RFC1034">
<front>
<title>Domain names - concepts and facilities</title>
<author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
tris">
<organization showOnFrontPage="true"/>
</author>
<date year="1987" month="November"/>
<abstract>
<t indent="0">This RFC is the revised basic definition of The Doma
in Name System. It obsoletes RFC-882. This memo describes the domain style nam
es and their used for host address look up and electronic mail forwarding. It d
iscusses the clients and servers in the domain name system and the protocol used
between them.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/> <seriesInfo name="STD" value="13"/>
<author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetr <seriesInfo name="RFC" value="1034"/>
is"> <seriesInfo name="DOI" value="10.17487/RFC1034"/>
<organization/> </reference>
</author> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<date year="1987" month="November"/> 119" quoteTitle="true" derivedAnchor="RFC2119">
<abstract> <front>
<t>This RFC is the revised basic definition of The Domain Name Syste <title>Key words for use in RFCs to Indicate Requirement Levels</tit
m. It obsoletes RFC-882. This memo describes the domain style names and their le>
used for host address look up and electronic mail forwarding. It discusses the <author initials="S." surname="Bradner" fullname="S. Bradner">
clients and servers in the domain name system and the protocol used between them <organization showOnFrontPage="true"/>
.</t> </author>
</abstract> <date year="1997" month="March"/>
</front> <abstract>
</reference> <t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc211 pitalized. This document defines these words as they should be interpreted in IE
9"> TF documents. This document specifies an Internet Best Current Practices for th
<front> e Internet Community, and requests discussion and suggestions for improvements.<
<title>Key words for use in RFCs to Indicate Requirement Levels</title /t>
> </abstract>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> </front>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<author initials="S." surname="Bradner" fullname="S. Bradner"> <seriesInfo name="RFC" value="2119"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</author> </reference>
<date year="1997" month="March"/> <reference anchor="RFC3810" target="https://www.rfc-editor.org/info/rfc3
<abstract> 810" quoteTitle="true" derivedAnchor="RFC3810">
<t>In many standards track documents several words are used to signi <front>
fy the requirements in the specification. These words are often capitalized. Th <title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</titl
is document defines these words as they should be interpreted in IETF documents. e>
This document specifies an Internet Best Current Practices for the Internet Co <author initials="R." surname="Vida" fullname="R. Vida" role="editor
mmunity, and requests discussion and suggestions for improvements.</t> ">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <author initials="L." surname="Costa" fullname="L. Costa" role="edit
or">
<reference anchor="RFC3810" target="https://www.rfc-editor.org/info/rfc381 <organization showOnFrontPage="true"/>
0"> </author>
<front> <date year="2004" month="June"/>
<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title> <abstract>
<seriesInfo name="DOI" value="10.17487/RFC3810"/> <t indent="0">This document updates RFC 2710, and it specifies Ver
sion 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an I
Pv6 router to discover the presence of multicast listeners on directly attached
links, and to discover which multicast addresses are of interest to those neighb
oring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the
ability for a node to report interest in listening to packets with a particular
multicast address only from specific source addresses or from all sources except
for specific source addresses. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3810"/> <seriesInfo name="RFC" value="3810"/>
<author initials="R." surname="Vida" fullname="R. Vida" role="editor"> <seriesInfo name="DOI" value="10.17487/RFC3810"/>
<organization/> </reference>
</author> <reference anchor="RFC4191" target="https://www.rfc-editor.org/info/rfc4
<author initials="L." surname="Costa" fullname="L. Costa" role="editor 191" quoteTitle="true" derivedAnchor="RFC4191">
"> <front>
<organization/> <title>Default Router Preferences and More-Specific Routes</title>
</author> <author initials="R." surname="Draves" fullname="R. Draves">
<date year="2004" month="June"/> <organization showOnFrontPage="true"/>
<abstract> </author>
<t>This document updates RFC 2710, and it specifies Version 2 of the <author initials="D." surname="Thaler" fullname="D. Thaler">
ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to <organization showOnFrontPage="true"/>
discover the presence of multicast listeners on directly attached links, and to </author>
discover which multicast addresses are of interest to those neighboring nodes. <date year="2005" month="November"/>
MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a <abstract>
node to report interest in listening to packets with a particular multicast add <t indent="0">This document describes an optional extension to Rou
ress only from specific source addresses or from all sources except for specific ter Advertisement messages for communicating default router preferences and more
source addresses. [STANDARDS-TRACK]</t> -specific routes from routers to hosts. This improves the ability of hosts to p
</abstract> ick an appropriate router, especially when the host is multi-homed and the route
</front> rs are on different links. The preference values and specific routes advertised
</reference> to hosts require administrative configuration; they are not automatically deriv
<reference anchor="RFC4191" target="https://www.rfc-editor.org/info/rfc419 ed from routing tables. [STANDARDS-TRACK]</t>
1"> </abstract>
<front> </front>
<title>Default Router Preferences and More-Specific Routes</title>
<seriesInfo name="DOI" value="10.17487/RFC4191"/>
<seriesInfo name="RFC" value="4191"/> <seriesInfo name="RFC" value="4191"/>
<author initials="R." surname="Draves" fullname="R. Draves"> <seriesInfo name="DOI" value="10.17487/RFC4191"/>
<organization/> </reference>
</author> <reference anchor="RFC4193" target="https://www.rfc-editor.org/info/rfc4
<author initials="D." surname="Thaler" fullname="D. Thaler"> 193" quoteTitle="true" derivedAnchor="RFC4193">
<organization/> <front>
</author> <title>Unique Local IPv6 Unicast Addresses</title>
<date year="2005" month="November"/> <author initials="R." surname="Hinden" fullname="R. Hinden">
<abstract> <organization showOnFrontPage="true"/>
<t>This document describes an optional extension to Router Advertise </author>
ment messages for communicating default router preferences and more-specific rou <author initials="B." surname="Haberman" fullname="B. Haberman">
tes from routers to hosts. This improves the ability of hosts to pick an approp <organization showOnFrontPage="true"/>
riate router, especially when the host is multi-homed and the routers are on dif </author>
ferent links. The preference values and specific routes advertised to hosts req <date year="2005" month="October"/>
uire administrative configuration; they are not automatically derived from routi <abstract>
ng tables. [STANDARDS-TRACK]</t> <t indent="0">This document defines an IPv6 unicast address format
</abstract> that is globally unique and is intended for local communications, usually insid
</front> e of a site. These addresses are not expected to be routable on the global Inter
</reference> net. [STANDARDS-TRACK]</t>
<reference anchor="RFC4193" target="https://www.rfc-editor.org/info/rfc419 </abstract>
3"> </front>
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<seriesInfo name="DOI" value="10.17487/RFC4193"/>
<seriesInfo name="RFC" value="4193"/> <seriesInfo name="RFC" value="4193"/>
<author initials="R." surname="Hinden" fullname="R. Hinden"> <seriesInfo name="DOI" value="10.17487/RFC4193"/>
<organization/> </reference>
</author> <reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4
<author initials="B." surname="Haberman" fullname="B. Haberman"> 291" quoteTitle="true" derivedAnchor="RFC4291">
<organization/> <front>
</author> <title>IP Version 6 Addressing Architecture</title>
<date year="2005" month="October"/> <author initials="R." surname="Hinden" fullname="R. Hinden">
<abstract> <organization showOnFrontPage="true"/>
<t>This document defines an IPv6 unicast address format that is glob </author>
ally unique and is intended for local communications, usually inside of a site. <author initials="S." surname="Deering" fullname="S. Deering">
These addresses are not expected to be routable on the global Internet. [STANDA <organization showOnFrontPage="true"/>
RDS-TRACK]</t> </author>
</abstract> <date year="2006" month="February"/>
</front> <abstract>
</reference> <t indent="0">This specification defines the addressing architectu
<reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc429 re of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressi
1"> ng model, text representations of IPv6 addresses, definition of IPv6 unicast add
<front> resses, anycast addresses, and multicast addresses, and an IPv6 node's required
<title>IP Version 6 Addressing Architecture</title> addresses.</t>
<seriesInfo name="DOI" value="10.17487/RFC4291"/> <t indent="0">This document obsoletes RFC 3513, "IP Version 6 Addr
essing Architecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/> <seriesInfo name="RFC" value="4291"/>
<author initials="R." surname="Hinden" fullname="R. Hinden"> <seriesInfo name="DOI" value="10.17487/RFC4291"/>
<organization/> </reference>
</author> <reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4
<author initials="S." surname="Deering" fullname="S. Deering"> 301" quoteTitle="true" derivedAnchor="RFC4301">
<organization/> <front>
</author> <title>Security Architecture for the Internet Protocol</title>
<date year="2006" month="February"/> <author initials="S." surname="Kent" fullname="S. Kent">
<abstract> <organization showOnFrontPage="true"/>
<t>This specification defines the addressing architecture of the IP </author>
Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, tex <author initials="K." surname="Seo" fullname="K. Seo">
t representations of IPv6 addresses, definition of IPv6 unicast addresses, anyca <organization showOnFrontPage="true"/>
st addresses, and multicast addresses, and an IPv6 node's required addresses.</t </author>
> <date year="2005" month="December"/>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing Archit <abstract>
ecture". [STANDARDS-TRACK]</t> <t indent="0">This document describes an updated version of the "S
</abstract> ecurity Architecture for IP", which is designed to provide security services for
</front> traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [S
</reference> TANDARDS-TRACK]</t>
<reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc430 </abstract>
1"> </front>
<front>
<title>Security Architecture for the Internet Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
<seriesInfo name="RFC" value="4301"/> <seriesInfo name="RFC" value="4301"/>
<author initials="S." surname="Kent" fullname="S. Kent"> <seriesInfo name="DOI" value="10.17487/RFC4301"/>
<organization/> </reference>
</author> <reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4
<author initials="K." surname="Seo" fullname="K. Seo"> 861" quoteTitle="true" derivedAnchor="RFC4861">
<organization/> <front>
</author> <title>Neighbor Discovery for IP version 6 (IPv6)</title>
<date year="2005" month="December"/> <author initials="T." surname="Narten" fullname="T. Narten">
<abstract> <organization showOnFrontPage="true"/>
<t>This document describes an updated version of the "Security Archi </author>
tecture for IP", which is designed to provide security services for traffic at t <author initials="E." surname="Nordmark" fullname="E. Nordmark">
he IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRAC <organization showOnFrontPage="true"/>
K]</t> </author>
</abstract> <author initials="W." surname="Simpson" fullname="W. Simpson">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="H." surname="Soliman" fullname="H. Soliman">
<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc486 <organization showOnFrontPage="true"/>
1"> </author>
<front> <date year="2007" month="September"/>
<title>Neighbor Discovery for IP version 6 (IPv6)</title> <abstract>
<seriesInfo name="DOI" value="10.17487/RFC4861"/> <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="RFC" value="4861"/>
<author initials="T." surname="Narten" fullname="T. Narten"> <seriesInfo name="DOI" value="10.17487/RFC4861"/>
<organization/> </reference>
</author> <reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4
<author initials="E." surname="Nordmark" fullname="E. Nordmark"> 862" quoteTitle="true" derivedAnchor="RFC4862">
<organization/> <front>
</author> <title>IPv6 Stateless Address Autoconfiguration</title>
<author initials="W." surname="Simpson" fullname="W. Simpson"> <author initials="S." surname="Thomson" fullname="S. Thomson">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="H." surname="Soliman" fullname="H. Soliman"> <author initials="T." surname="Narten" fullname="T. Narten">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2007" month="September"/> <author initials="T." surname="Jinmei" fullname="T. Jinmei">
<abstract> <organization showOnFrontPage="true"/>
<t>This document specifies the Neighbor Discovery protocol for IP Ve </author>
rsion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each ot <date year="2007" month="September"/>
her's presence, to determine each other's link-layer addresses, to find routers, <abstract>
and to maintain reachability information about the paths to active neighbors. <t indent="0">This document specifies the steps a host takes in de
[STANDARDS-TRACK]</t> ciding how to autoconfigure its interfaces in IP version 6. The autoconfigurati
</abstract> on process includes generating a link-local address, generating global addresses
</front> via stateless address autoconfiguration, and the Duplicate Address Detection pr
</reference> ocedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]<
<reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc486 /t>
2"> </abstract>
<front> </front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
<seriesInfo name="RFC" value="4862"/> <seriesInfo name="RFC" value="4862"/>
<author initials="S." surname="Thomson" fullname="S. Thomson"> <seriesInfo name="DOI" value="10.17487/RFC4862"/>
<organization/> </reference>
</author> <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
<author initials="T." surname="Narten" fullname="T. Narten"> 234" quoteTitle="true" derivedAnchor="RFC5234">
<organization/> <front>
</author> <title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="T." surname="Jinmei" fullname="T. Jinmei"> <author initials="D." surname="Crocker" fullname="D. Crocker" role="
<organization/> editor">
</author> <organization showOnFrontPage="true"/>
<date year="2007" month="September"/> </author>
<abstract> <author initials="P." surname="Overell" fullname="P. Overell">
<t>This document specifies the steps a host takes in deciding how to <organization showOnFrontPage="true"/>
autoconfigure its interfaces in IP version 6. The autoconfiguration process in </author>
cludes generating a link-local address, generating global addresses via stateles <date year="2008" month="January"/>
s address autoconfiguration, and the Duplicate Address Detection procedure to ve <abstract>
rify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t> <t indent="0">Internet technical specifications often need to defi
</abstract> ne a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF
</front> ), called Augmented BNF (ABNF), has been popular among many Internet specificati
</reference> ons. The current specification documents ABNF. It balances compactness and simp
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc523 licity with reasonable representational power. The differences between standard
4"> BNF and ABNF involve naming rules, repetition, alternatives, order-independence
<front> , and value ranges. This specification also supplies additional rule definition
<title>Augmented BNF for Syntax Specifications: ABNF</title> s and encoding for a core lexical analyzer of the type common to several Interne
<seriesInfo name="DOI" value="10.17487/RFC5234"/> t specifications. [STANDARDS-TRACK]</t>
<seriesInfo name="RFC" value="5234"/> </abstract>
</front>
<seriesInfo name="STD" value="68"/> <seriesInfo name="STD" value="68"/>
<author initials="D." surname="Crocker" fullname="D. Crocker" role="ed <seriesInfo name="RFC" value="5234"/>
itor"> <seriesInfo name="DOI" value="10.17487/RFC5234"/>
<organization/> </reference>
</author> <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5
<author initials="P." surname="Overell" fullname="P. Overell"> 246" quoteTitle="true" derivedAnchor="RFC5246">
<organization/> <front>
</author> <title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
<date year="2008" month="January"/> e>
<abstract> <author initials="T." surname="Dierks" fullname="T. Dierks">
<t>Internet technical specifications often need to define a formal s <organization showOnFrontPage="true"/>
yntax. Over the years, a modified version of Backus-Naur Form (BNF), called Aug </author>
mented BNF (ABNF), has been popular among many Internet specifications. The cur <author initials="E." surname="Rescorla" fullname="E. Rescorla">
rent specification documents ABNF. It balances compactness and simplicity with r <organization showOnFrontPage="true"/>
easonable representational power. The differences between standard BNF and ABNF </author>
involve naming rules, repetition, alternatives, order-independence, and value r <date year="2008" month="August"/>
anges. This specification also supplies additional rule definitions and encodin <abstract>
g for a core lexical analyzer of the type common to several Internet specificati <t indent="0">This document specifies Version 1.2 of the Transport
ons. [STANDARDS-TRACK]</t> Layer Security (TLS) protocol. The TLS protocol provides communications securi
</abstract> ty over the Internet. The protocol allows client/server applications to communi
</front> cate in a way that is designed to prevent eavesdropping, tampering, or message f
</reference> orgery. [STANDARDS-TRACK]</t>
<reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc524 </abstract>
6"> </front>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
<seriesInfo name="RFC" value="5246"/> <seriesInfo name="RFC" value="5246"/>
<author initials="T." surname="Dierks" fullname="T. Dierks"> <seriesInfo name="DOI" value="10.17487/RFC5246"/>
<organization/> </reference>
</author> <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5
<author initials="E." surname="Rescorla" fullname="E. Rescorla"> 280" quoteTitle="true" derivedAnchor="RFC5280">
<organization/> <front>
</author> <title>Internet X.509 Public Key Infrastructure Certificate and Cert
<date year="2008" month="August"/> ificate Revocation List (CRL) Profile</title>
<abstract> <author initials="D." surname="Cooper" fullname="D. Cooper">
<t>This document specifies Version 1.2 of the Transport Layer Securi <organization showOnFrontPage="true"/>
ty (TLS) protocol. The TLS protocol provides communications security over the I </author>
nternet. The protocol allows client/server applications to communicate in a way <author initials="S." surname="Santesson" fullname="S. Santesson">
that is designed to prevent eavesdropping, tampering, or message forgery. [STA <organization showOnFrontPage="true"/>
NDARDS-TRACK]</t> </author>
</abstract> <author initials="S." surname="Farrell" fullname="S. Farrell">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc528 <author initials="S." surname="Boeyen" fullname="S. Boeyen">
0"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Internet X.509 Public Key Infrastructure Certificate and Certif <author initials="R." surname="Housley" fullname="R. Housley">
icate Revocation List (CRL) Profile</title> <organization showOnFrontPage="true"/>
<seriesInfo name="DOI" value="10.17487/RFC5280"/> </author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="May"/>
<abstract>
<t indent="0">This memo profiles the X.509 v3 certificate and X.50
9 v2 certificate revocation list (CRL) for use in the Internet. An overview of
this approach and model is provided as an introduction. The X.509 v3 certificat
e format is described in detail, with additional information regarding the forma
t and semantics of Internet name forms. Standard certificate extensions are des
cribed and two Internet-specific extensions are defined. A set of required cert
ificate extensions is specified. The X.509 v2 CRL format is described in detail
along with standard and Internet-specific extensions. An algorithm for X.509 c
ertification path validation is described. An ASN.1 module and examples are pro
vided in the appendices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/> <seriesInfo name="RFC" value="5280"/>
<author initials="D." surname="Cooper" fullname="D. Cooper"> <seriesInfo name="DOI" value="10.17487/RFC5280"/>
<organization/> </reference>
</author> <reference anchor="RFC5954" target="https://www.rfc-editor.org/info/rfc5
<author initials="S." surname="Santesson" fullname="S. Santesson"> 954" quoteTitle="true" derivedAnchor="RFC5954">
<organization/> <front>
</author> <title>Essential Correction for IPv6 ABNF and URI Comparison in RFC
<author initials="S." surname="Farrell" fullname="S. Farrell"> 3261</title>
<organization/> <author initials="V." surname="Gurbani" fullname="V. Gurbani" role="
</author> editor">
<author initials="S." surname="Boeyen" fullname="S. Boeyen"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <author initials="B." surname="Carpenter" fullname="B. Carpenter" ro
<author initials="R." surname="Housley" fullname="R. Housley"> le="editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="W." surname="Polk" fullname="W. Polk"> <author initials="B." surname="Tate" fullname="B. Tate" role="editor
<organization/> ">
</author> <organization showOnFrontPage="true"/>
<date year="2008" month="May"/> </author>
<abstract> <date year="2010" month="August"/>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certific <abstract>
ate revocation list (CRL) for use in the Internet. An overview of this approach <t indent="0">This document corrects the Augmented Backus-Naur For
and model is provided as an introduction. The X.509 v3 certificate format is d m (ABNF) production rule associated with generating IPv6 literals in RFC 3261. I
escribed in detail, with additional information regarding the format and semanti t also clarifies the rule for Uniform Resource Identifier (URI) comparison when
cs of Internet name forms. Standard certificate extensions are described and tw the URIs contain textual representation of IP addresses. [STANDARDS-TRACK]</t>
o Internet-specific extensions are defined. A set of required certificate exten </abstract>
sions is specified. The X.509 v2 CRL format is described in detail along with s </front>
tandard and Internet-specific extensions. An algorithm for X.509 certification <seriesInfo name="RFC" value="5954"/>
path validation is described. An ASN.1 module and examples are provided in the <seriesInfo name="DOI" value="10.17487/RFC5954"/>
appendices. [STANDARDS-TRACK]</t> </reference>
</abstract> <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
</front> 347" quoteTitle="true" derivedAnchor="RFC6347">
</reference> <front>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc634 <title>Datagram Transport Layer Security Version 1.2</title>
7"> <author initials="E." surname="Rescorla" fullname="E. Rescorla">
<front> <organization showOnFrontPage="true"/>
<title>Datagram Transport Layer Security Version 1.2</title> </author>
<seriesInfo name="DOI" value="10.17487/RFC6347"/> <author initials="N." surname="Modadugu" fullname="N. Modadugu">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="January"/>
<abstract>
<t indent="0">This document specifies version 1.2 of the Datagram
Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
ions privacy for datagram protocols. The protocol allows client/server applicat
ions to communicate in a way that is designed to prevent eavesdropping, tamperin
g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
cs of the underlying transport are preserved by the DTLS protocol. This documen
t updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/> <seriesInfo name="RFC" value="6347"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla"> <seriesInfo name="DOI" value="10.17487/RFC6347"/>
<organization/> </reference>
</author> <reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6
<author initials="N." surname="Modadugu" fullname="N. Modadugu"> 550" quoteTitle="true" derivedAnchor="RFC6550">
<organization/> <front>
</author> <title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</
<date year="2012" month="January"/> title>
<abstract> <author initials="T." surname="Winter" fullname="T. Winter" role="ed
<t>This document specifies version 1.2 of the Datagram Transport Lay itor">
er Security (DTLS) protocol. The DTLS protocol provides communications privacy <organization showOnFrontPage="true"/>
for datagram protocols. The protocol allows client/server applications to commu </author>
nicate in a way that is designed to prevent eavesdropping, tampering, or message <author initials="P." surname="Thubert" fullname="P. Thubert" role="
forgery. The DTLS protocol is based on the Transport Layer Security (TLS) prot editor">
ocol and provides equivalent security guarantees. Datagram semantics of the und <organization showOnFrontPage="true"/>
erlying transport are preserved by the DTLS protocol. This document updates DTL </author>
S 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t> <author initials="A." surname="Brandt" fullname="A. Brandt">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <author initials="J." surname="Hui" fullname="J. Hui">
<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc655 <organization showOnFrontPage="true"/>
0"> </author>
<front> <author initials="R." surname="Kelsey" fullname="R. Kelsey">
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</ti <organization showOnFrontPage="true"/>
tle> </author>
<seriesInfo name="DOI" value="10.17487/RFC6550"/> <author initials="P." surname="Levis" fullname="P. Levis">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Struik" fullname="R. Struik">
<organization showOnFrontPage="true"/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Alexander" fullname="R. Alexander">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">Low-Power and Lossy Networks (LLNs) are a class of n
etwork in which both the routers and their interconnect are constrained. LLN ro
uters typically operate with constraints on processing power, memory, and energy
(battery power). Their interconnects are characterized by high loss rates, low
data rates, and instability. LLNs are comprised of anything from a few dozen t
o thousands of routers. Supported traffic flows include point-to-point (between
devices inside the LLN), point-to-multipoint (from a central control point to a
subset of devices inside the LLN), and multipoint-to-point (from devices inside
the LLN towards a central control point). This document specifies the IPv6 Rou
ting Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism
whereby multipoint-to-point traffic from devices inside the LLN towards a centr
al control point as well as point-to-multipoint traffic from the central control
point to the devices inside the LLN are supported. Support for point-to-point
traffic is also available. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6550"/> <seriesInfo name="RFC" value="6550"/>
<author initials="T." surname="Winter" fullname="T. Winter" role="edit <seriesInfo name="DOI" value="10.17487/RFC6550"/>
or"> </reference>
<organization/> <reference anchor="RFC6551" target="https://www.rfc-editor.org/info/rfc6
</author> 551" quoteTitle="true" derivedAnchor="RFC6551">
<author initials="P." surname="Thubert" fullname="P. Thubert" role="ed <front>
itor"> <title>Routing Metrics Used for Path Calculation in Low-Power and Lo
<organization/> ssy Networks</title>
</author> <author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role
<author initials="A." surname="Brandt" fullname="A. Brandt"> ="editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="J." surname="Hui" fullname="J. Hui"> <author initials="M." surname="Kim" fullname="M. Kim" role="editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="R." surname="Kelsey" fullname="R. Kelsey"> <author initials="K." surname="Pister" fullname="K. Pister">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="P." surname="Levis" fullname="P. Levis"> <author initials="N." surname="Dejean" fullname="N. Dejean">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="K." surname="Pister" fullname="K. Pister"> <author initials="D." surname="Barthel" fullname="D. Barthel">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="R." surname="Struik" fullname="R. Struik"> <date year="2012" month="March"/>
<organization/> <abstract>
</author> <t indent="0">Low-Power and Lossy Networks (LLNs) have unique char
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur"> acteristics compared with traditional wired and ad hoc networks that require the
<organization/> specification of new routing metrics and constraints. By contrast, with typica
</author> l Interior Gateway Protocol (IGP) routing metrics using hop counts or link metri
<author initials="R." surname="Alexander" fullname="R. Alexander"> cs, this document specifies a set of link and node routing metrics and constrain
<organization/> ts suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy N
</author> etworks (RPL). [STANDARDS-TRACK]</t>
<date year="2012" month="March"/> </abstract>
<abstract> </front>
<t>Low-Power and Lossy Networks (LLNs) are a class of network in whi
ch both the routers and their interconnect are constrained. LLN routers typical
ly operate with constraints on processing power, memory, and energy (battery pow
er). Their interconnects are characterized by high loss rates, low data rates,
and instability. LLNs are comprised of anything from a few dozen to thousands o
f routers. Supported traffic flows include point-to-point (between devices insi
de the LLN), point-to-multipoint (from a central control point to a subset of de
vices inside the LLN), and multipoint-to-point (from devices inside the LLN towa
rds a central control point). This document specifies the IPv6 Routing Protocol
for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby mult
ipoint-to-point traffic from devices inside the LLN towards a central control po
int as well as point-to-multipoint traffic from the central control point to the
devices inside the LLN are supported. Support for point-to-point traffic is al
so available. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6551" target="https://www.rfc-editor.org/info/rfc655
1">
<front>
<title>Routing Metrics Used for Path Calculation in Low-Power and Loss
y Networks</title>
<seriesInfo name="DOI" value="10.17487/RFC6551"/>
<seriesInfo name="RFC" value="6551"/> <seriesInfo name="RFC" value="6551"/>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role=" <seriesInfo name="DOI" value="10.17487/RFC6551"/>
editor"> </reference>
<organization/> <reference anchor="RFC6552" target="https://www.rfc-editor.org/info/rfc6
</author> 552" quoteTitle="true" derivedAnchor="RFC6552">
<author initials="M." surname="Kim" fullname="M. Kim" role="editor"> <front>
<organization/> <title>Objective Function Zero for the Routing Protocol for Low-Powe
</author> r and Lossy Networks (RPL)</title>
<author initials="K." surname="Pister" fullname="K. Pister"> <author initials="P." surname="Thubert" fullname="P. Thubert" role="
<organization/> editor">
</author> <organization showOnFrontPage="true"/>
<author initials="N." surname="Dejean" fullname="N. Dejean"> </author>
<organization/> <date year="2012" month="March"/>
</author> <abstract>
<author initials="D." surname="Barthel" fullname="D. Barthel"> <t indent="0">The Routing Protocol for Low-Power and Lossy Network
<organization/> s (RPL) specification defines a generic Distance Vector protocol that is adapted
</author> to a variety of network types by the application of specific Objective Function
<date year="2012" month="March"/> s (OFs). An OF states the outcome of the process used by a RPL node to select a
<abstract> nd optimize routes within a RPL Instance based on the Information Objects availa
<t>Low-Power and Lossy Networks (LLNs) have unique characteristics c ble; an OF is not an algorithm.</t>
ompared with traditional wired and ad hoc networks that require the specificatio <t indent="0">This document specifies a basic Objective Function t
n of new routing metrics and constraints. By contrast, with typical Interior Ga hat relies only on the objects that are defined in the RPL and does not use any
teway Protocol (IGP) routing metrics using hop counts or link metrics, this docu protocol extensions. [STANDARDS-TRACK]</t>
ment specifies a set of link and node routing metrics and constraints suitable t </abstract>
o LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL) </front>
. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6552" target="https://www.rfc-editor.org/info/rfc655
2">
<front>
<title>Objective Function Zero for the Routing Protocol for Low-Power
and Lossy Networks (RPL)</title>
<seriesInfo name="DOI" value="10.17487/RFC6552"/>
<seriesInfo name="RFC" value="6552"/> <seriesInfo name="RFC" value="6552"/>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="ed <seriesInfo name="DOI" value="10.17487/RFC6552"/>
itor"> </reference>
<organization/> <reference anchor="RFC6553" target="https://www.rfc-editor.org/info/rfc6
</author> 553" quoteTitle="true" derivedAnchor="RFC6553">
<date year="2012" month="March"/> <front>
<abstract> <title>The Routing Protocol for Low-Power and Lossy Networks (RPL) O
<t>The Routing Protocol for Low-Power and Lossy Networks (RPL) speci ption for Carrying RPL Information in Data-Plane Datagrams</title>
fication defines a generic Distance Vector protocol that is adapted to a variety <author initials="J." surname="Hui" fullname="J. Hui">
of network types by the application of specific Objective Functions (OFs). An <organization showOnFrontPage="true"/>
OF states the outcome of the process used by a RPL node to select and optimize r </author>
outes within a RPL Instance based on the Information Objects available; an OF is <author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
not an algorithm.</t> <organization showOnFrontPage="true"/>
<t>This document specifies a basic Objective Function that relies on </author>
ly on the objects that are defined in the RPL and does not use any protocol exte <date year="2012" month="March"/>
nsions. [STANDARDS-TRACK]</t> <abstract>
</abstract> <t indent="0">The Routing Protocol for Low-Power and Lossy Network
</front> s (RPL) includes routing information in data-plane datagrams to quickly identify
</reference> inconsistencies in the routing topology. This document describes the RPL Optio
<reference anchor="RFC6553" target="https://www.rfc-editor.org/info/rfc655 n for use among RPL routers to include such routing information. [STANDARDS-TRA
3"> CK]</t>
<front> </abstract>
<title>The Routing Protocol for Low-Power and Lossy Networks (RPL) Opt </front>
ion for Carrying RPL Information in Data-Plane Datagrams</title>
<seriesInfo name="DOI" value="10.17487/RFC6553"/>
<seriesInfo name="RFC" value="6553"/> <seriesInfo name="RFC" value="6553"/>
<author initials="J." surname="Hui" fullname="J. Hui"> <seriesInfo name="DOI" value="10.17487/RFC6553"/>
<organization/> </reference>
</author> <reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur"> 030" quoteTitle="true" derivedAnchor="RFC7030">
<organization/> <front>
</author> <title>Enrollment over Secure Transport</title>
<date year="2012" month="March"/> <author initials="M." surname="Pritikin" fullname="M. Pritikin" role
<abstract> ="editor">
<t>The Routing Protocol for Low-Power and Lossy Networks (RPL) inclu <organization showOnFrontPage="true"/>
des routing information in data-plane datagrams to quickly identify inconsistenc </author>
ies in the routing topology. This document describes the RPL Option for use amo <author initials="P." surname="Yee" fullname="P. Yee" role="editor">
ng RPL routers to include such routing information. [STANDARDS-TRACK]</t> <organization showOnFrontPage="true"/>
</abstract> </author>
</front> <author initials="D." surname="Harkins" fullname="D. Harkins" role="
</reference> editor">
<reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc703 <organization showOnFrontPage="true"/>
0"> </author>
<front> <date year="2013" month="October"/>
<title>Enrollment over Secure Transport</title> <abstract>
<seriesInfo name="DOI" value="10.17487/RFC7030"/> <t indent="0">This document profiles certificate enrollment for cl
ients using Certificate Management over CMS (CMC) messages over a secure transpo
rt. This profile, called Enrollment over Secure Transport (EST), describes a si
mple, yet functional, certificate management protocol targeting Public Key Infra
structure (PKI) clients that need to acquire client certificates and associated
Certification Authority (CA) certificates. It also supports client-generated pu
blic/private key pairs as well as key pairs generated by the CA.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7030"/> <seriesInfo name="RFC" value="7030"/>
<author initials="M." surname="Pritikin" fullname="M. Pritikin" role=" <seriesInfo name="DOI" value="10.17487/RFC7030"/>
editor"> </reference>
<organization/> <reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7
</author> 296" quoteTitle="true" derivedAnchor="RFC7296">
<author initials="P." surname="Yee" fullname="P. Yee" role="editor"> <front>
<organization/> <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
</author> <author initials="C." surname="Kaufman" fullname="C. Kaufman">
<author initials="D." surname="Harkins" fullname="D. Harkins" role="ed <organization showOnFrontPage="true"/>
itor"> </author>
<organization/> <author initials="P." surname="Hoffman" fullname="P. Hoffman">
</author> <organization showOnFrontPage="true"/>
<date year="2013" month="October"/> </author>
<abstract> <author initials="Y." surname="Nir" fullname="Y. Nir">
<t>This document profiles certificate enrollment for clients using C <organization showOnFrontPage="true"/>
ertificate Management over CMS (CMC) messages over a secure transport. This pro </author>
file, called Enrollment over Secure Transport (EST), describes a simple, yet fun <author initials="P." surname="Eronen" fullname="P. Eronen">
ctional, certificate management protocol targeting Public Key Infrastructure (PK <organization showOnFrontPage="true"/>
I) clients that need to acquire client certificates and associated Certification </author>
Authority (CA) certificates. It also supports client-generated public/private <author initials="T." surname="Kivinen" fullname="T. Kivinen">
key pairs as well as key pairs generated by the CA.</t> <organization showOnFrontPage="true"/>
</abstract> </author>
</front> <date year="2014" month="October"/>
</reference> <abstract>
<reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc729 <t indent="0">This document describes version 2 of the Internet Ke
6"> y Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutu
<front> al authentication and establishing and maintaining Security Associations (SAs).
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title> This document obsoletes RFC 5996, and includes all of the errata for it. It ad
<seriesInfo name="DOI" value="10.17487/RFC7296"/> vances IKEv2 to be an Internet Standard.</t>
<seriesInfo name="RFC" value="7296"/> </abstract>
</front>
<seriesInfo name="STD" value="79"/> <seriesInfo name="STD" value="79"/>
<author initials="C." surname="Kaufman" fullname="C. Kaufman"> <seriesInfo name="RFC" value="7296"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC7296"/>
</author> </reference>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"> <reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7
<organization/> 525" quoteTitle="true" derivedAnchor="RFC7525">
</author> <front>
<author initials="Y." surname="Nir" fullname="Y. Nir"> <title>Recommendations for Secure Use of Transport Layer Security (T
<organization/> LS) and Datagram Transport Layer Security (DTLS)</title>
</author> <author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
<author initials="P." surname="Eronen" fullname="P. Eronen"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <author initials="R." surname="Holz" fullname="R. Holz">
<author initials="T." surname="Kivinen" fullname="T. Kivinen"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
<date year="2014" month="October"/> ">
<abstract> <organization showOnFrontPage="true"/>
<t>This document describes version 2 of the Internet Key Exchange (I </author>
KE) protocol. IKE is a component of IPsec used for performing mutual authentica <date year="2015" month="May"/>
tion and establishing and maintaining Security Associations (SAs). This documen <abstract>
t obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 <t indent="0">Transport Layer Security (TLS) and Datagram Transpor
to be an Internet Standard.</t> t Layer Security (DTLS) are widely used to protect data exchanged over applicati
</abstract> on protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few ye
</front> ars, several serious attacks on TLS have emerged, including attacks on its most
</reference> commonly used cipher suites and their modes of operation. This document provide
<reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc752 s recommendations for improving the security of deployed services that use TLS a
5"> nd DTLS. The recommendations are applicable to the majority of use cases.</t>
<front> </abstract>
<title>Recommendations for Secure Use of Transport Layer Security (TLS </front>
) and Datagram Transport Layer Security (DTLS)</title>
<seriesInfo name="DOI" value="10.17487/RFC7525"/>
<seriesInfo name="RFC" value="7525"/>
<seriesInfo name="BCP" value="195"/> <seriesInfo name="BCP" value="195"/>
<author initials="Y." surname="Sheffer" fullname="Y. Sheffer"> <seriesInfo name="RFC" value="7525"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC7525"/>
</author> </reference>
<author initials="R." surname="Holz" fullname="R. Holz"> <reference anchor="RFC7676" target="https://www.rfc-editor.org/info/rfc7
<organization/> 676" quoteTitle="true" derivedAnchor="RFC7676">
</author> <front>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre"> <title>IPv6 Support for Generic Routing Encapsulation (GRE)</title>
<organization/> <author initials="C." surname="Pignataro" fullname="C. Pignataro">
</author> <organization showOnFrontPage="true"/>
<date year="2015" month="May"/> </author>
<abstract> <author initials="R." surname="Bonica" fullname="R. Bonica">
<t>Transport Layer Security (TLS) and Datagram Transport Layer Secur <organization showOnFrontPage="true"/>
ity (DTLS) are widely used to protect data exchanged over application protocols </author>
such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several <author initials="S." surname="Krishnan" fullname="S. Krishnan">
serious attacks on TLS have emerged, including attacks on its most commonly used <organization showOnFrontPage="true"/>
cipher suites and their modes of operation. This document provides recommendat </author>
ions for improving the security of deployed services that use TLS and DTLS. The <date year="2015" month="October"/>
recommendations are applicable to the majority of use cases.</t> <abstract>
</abstract> <t indent="0">Generic Routing Encapsulation (GRE) can be used to c
</front> arry any network- layer payload protocol over any network-layer delivery protoco
</reference> l. Currently, GRE procedures are specified for IPv4, used as either the payload
<reference anchor="RFC7676" target="https://www.rfc-editor.org/info/rfc767 or delivery protocol. However, GRE procedures are not specified for IPv6.</t>
6"> <t indent="0">This document specifies GRE procedures for IPv6, use
<front> d as either the payload or delivery protocol.</t>
<title>IPv6 Support for Generic Routing Encapsulation (GRE)</title> </abstract>
<seriesInfo name="DOI" value="10.17487/RFC7676"/> </front>
<seriesInfo name="RFC" value="7676"/> <seriesInfo name="RFC" value="7676"/>
<author initials="C." surname="Pignataro" fullname="C. Pignataro"> <seriesInfo name="DOI" value="10.17487/RFC7676"/>
<organization/> </reference>
</author> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
<author initials="R." surname="Bonica" fullname="R. Bonica"> 174" quoteTitle="true" derivedAnchor="RFC8174">
<organization/> <front>
</author> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
<author initials="S." surname="Krishnan" fullname="S. Krishnan"> tle>
<organization/> <author initials="B." surname="Leiba" fullname="B. Leiba">
</author> <organization showOnFrontPage="true"/>
<date year="2015" month="October"/> </author>
<abstract> <date year="2017" month="May"/>
<t>Generic Routing Encapsulation (GRE) can be used to carry any netw <abstract>
ork- layer payload protocol over any network-layer delivery protocol. Currently, <t indent="0">RFC 2119 specifies common key words that may be used
GRE procedures are specified for IPv4, used as either the payload or delivery p in protocol specifications. This document aims to reduce the ambiguity by cla
rotocol. However, GRE procedures are not specified for IPv6.</t> rifying that only UPPERCASE usage of the key words have the defined special mea
<t>This document specifies GRE procedures for IPv6, used as either t nings.</t>
he payload or delivery protocol.</t> </abstract>
</abstract> </front>
</front>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc817
4">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</titl
e>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="BCP" value="14"/>
<author initials="B." surname="Leiba" fullname="B. Leiba"> <seriesInfo name="RFC" value="8174"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</author> </reference>
<date year="2017" month="May"/> <reference anchor="RFC8221" target="https://www.rfc-editor.org/info/rfc8
<abstract> 221" quoteTitle="true" derivedAnchor="RFC8221">
<t>RFC 2119 specifies common key words that may be used in protocol <front>
specifications. This document aims to reduce the ambiguity by clarifying that <title>Cryptographic Algorithm Implementation Requirements and Usage
only UPPERCASE usage of the key words have the defined special meanings.</t> Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH
</abstract> )</title>
</front> <author initials="P." surname="Wouters" fullname="P. Wouters">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC8221" target="https://www.rfc-editor.org/info/rfc822 <author initials="D." surname="Migault" fullname="D. Migault">
1"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Cryptographic Algorithm Implementation Requirements and Usage G <author initials="J." surname="Mattsson" fullname="J. Mattsson">
uidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)< <organization showOnFrontPage="true"/>
/title> </author>
<seriesInfo name="DOI" value="10.17487/RFC8221"/> <author initials="Y." surname="Nir" fullname="Y. Nir">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Kivinen" fullname="T. Kivinen">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="October"/>
<abstract>
<t indent="0">This document replaces RFC 7321, "Cryptographic Algo
rithm Implementation Requirements and Usage Guidance for Encapsulating S
ecurity Payload (ESP) and Authentication Header (AH)". The goal o
f this document is to enable ESP and AH to benefit from cryptography that is up
to date while making IPsec interoperable.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8221"/> <seriesInfo name="RFC" value="8221"/>
<author initials="P." surname="Wouters" fullname="P. Wouters"> <seriesInfo name="DOI" value="10.17487/RFC8221"/>
<organization/> </reference>
</author> <reference anchor="RFC8247" target="https://www.rfc-editor.org/info/rfc8
<author initials="D." surname="Migault" fullname="D. Migault"> 247" quoteTitle="true" derivedAnchor="RFC8247">
<organization/> <front>
</author> <title>Algorithm Implementation Requirements and Usage Guidance for
<author initials="J." surname="Mattsson" fullname="J. Mattsson"> the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<organization/> <author initials="Y." surname="Nir" fullname="Y. Nir">
</author> <organization showOnFrontPage="true"/>
<author initials="Y." surname="Nir" fullname="Y. Nir"> </author>
<organization/> <author initials="T." surname="Kivinen" fullname="T. Kivinen">
</author> <organization showOnFrontPage="true"/>
<author initials="T." surname="Kivinen" fullname="T. Kivinen"> </author>
<organization/> <author initials="P." surname="Wouters" fullname="P. Wouters">
</author> <organization showOnFrontPage="true"/>
<date year="2017" month="October"/> </author>
<abstract> <author initials="D." surname="Migault" fullname="D. Migault">
<t>This document replaces RFC 7321, "Cryptographic Algorithm Impleme <organization showOnFrontPage="true"/>
ntation Requirements and Usage Guidance for Encapsulating Security Paylo </author>
ad (ESP) and Authentication Header (AH)". The goal of this docume <date year="2017" month="September"/>
nt is to enable ESP and AH to benefit from cryptography that is up to date while <abstract>
making IPsec interoperable.</t> <t indent="0">The IPsec series of protocols makes use of various c
</abstract> ryptographic algorithms in order to provide security services. The Internet Key
</front> Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IP
</reference> sec SA) parameters, such as which algorithms should be used. To ensure interope
<reference anchor="RFC8247" target="https://www.rfc-editor.org/info/rfc824 rability between different implementations, it is necessary to specify a set of
7"> algorithm implementation requirements and usage guidance to ensure that there is
<front> at least one algorithm that all implementations support. This document updates
<title>Algorithm Implementation Requirements and Usage Guidance for th RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementatio
e Internet Key Exchange Protocol Version 2 (IKEv2)</title> n requirements and usage guidance for IKEv2, and does minor cleaning up of the I
<seriesInfo name="DOI" value="10.17487/RFC8247"/> KEv2 IANA registry. This document does not update the algorithms used for packe
t encryption using IPsec Encapsulating Security Payload (ESP).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8247"/> <seriesInfo name="RFC" value="8247"/>
<author initials="Y." surname="Nir" fullname="Y. Nir"> <seriesInfo name="DOI" value="10.17487/RFC8247"/>
<organization/> </reference>
</author> <reference anchor="RFC8422" target="https://www.rfc-editor.org/info/rfc8
<author initials="T." surname="Kivinen" fullname="T. Kivinen"> 422" quoteTitle="true" derivedAnchor="RFC8422">
<organization/> <front>
</author> <title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
<author initials="P." surname="Wouters" fullname="P. Wouters"> Layer Security (TLS) Versions 1.2 and Earlier</title>
<organization/> <author initials="Y." surname="Nir" fullname="Y. Nir">
</author> <organization showOnFrontPage="true"/>
<author initials="D." surname="Migault" fullname="D. Migault"> </author>
<organization/> <author initials="S." surname="Josefsson" fullname="S. Josefsson">
</author> <organization showOnFrontPage="true"/>
<date year="2017" month="September"/> </author>
<abstract> <author initials="M." surname="Pegourie-Gonnard" fullname="M. Pegour
<t>The IPsec series of protocols makes use of various cryptographic ie-Gonnard">
algorithms in order to provide security services. The Internet Key Exchange (IK <organization showOnFrontPage="true"/>
E) protocol is used to negotiate the IPsec Security Association (IPsec SA) param </author>
eters, such as which algorithms should be used. To ensure interoperability betw <date year="2018" month="August"/>
een different implementations, it is necessary to specify a set of algorithm imp <abstract>
lementation requirements and usage guidance to ensure that there is at least one <t indent="0">This document describes key exchange algorithms base
algorithm that all implementations support. This document updates RFC 7296 and d on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) pr
obsoletes RFC 4307 in defining the current algorithm implementation requirement otocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-
s and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA reg Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Cur
istry. This document does not update the algorithms used for packet encryption ve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algor
using IPsec Encapsulating Security Payload (ESP).</t> ithm (EdDSA) as authentication mechanisms.</t>
</abstract> <t indent="0">This document obsoletes RFC 4492.</t>
</front> </abstract>
</reference> </front>
<seriesInfo name="RFC" value="8422"/>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc <seriesInfo name="DOI" value="10.17487/RFC8422"/>
e.RFC.8422.xml"/> </reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc844 446" quoteTitle="true" derivedAnchor="RFC8446">
6"> <front>
<front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title> e>
<seriesInfo name="DOI" value="10.17487/RFC8446"/> <author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport
Layer Security (TLS) protocol. TLS allows client/server applications to commun
icate over the Internet in a way that is designed to prevent eavesdropping, tamp
ering, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
r TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/> <seriesInfo name="RFC" value="8446"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla"> <seriesInfo name="DOI" value="10.17487/RFC8446"/>
<organization/> </reference>
</author> <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
<date year="2018" month="August"/> 610" quoteTitle="true" derivedAnchor="RFC8610">
<abstract> <front>
<t>This document specifies version 1.3 of the Transport Layer Securi <title>Concise Data Definition Language (CDDL): A Notational Convent
ty (TLS) protocol. TLS allows client/server applications to communicate over th ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
e Internet in a way that is designed to prevent eavesdropping, tampering, and me res</title>
ssage forgery.</t> <author initials="H." surname="Birkholz" fullname="H. Birkholz">
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077 <organization showOnFrontPage="true"/>
, 5246, and 6961. This document also specifies new requirements for TLS 1.2 imp </author>
lementations.</t> <author initials="C." surname="Vigano" fullname="C. Vigano">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <author initials="C." surname="Bormann" fullname="C. Bormann">
<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc861 <organization showOnFrontPage="true"/>
0"> </author>
<front> <date year="2019" month="June"/>
<title>Concise Data Definition Language (CDDL): A Notational Conventio <abstract>
n to Express Concise Binary Object Representation (CBOR) and JSON Data Structure <t indent="0">This document proposes a notational convention to ex
s</title> press Concise Binary Object Representation (CBOR) data structures (RFC 7049). I
<seriesInfo name="DOI" value="10.17487/RFC8610"/> ts main goal is to provide an easy and unambiguous way to express structures for
protocol messages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8610"/> <seriesInfo name="RFC" value="8610"/>
<author initials="H." surname="Birkholz" fullname="H. Birkholz"> <seriesInfo name="DOI" value="10.17487/RFC8610"/>
<organization/> </reference>
</author> <reference anchor="RFC8990" target="https://www.rfc-editor.org/info/rfc8
<author initials="C." surname="Vigano" fullname="C. Vigano"> 990" quoteTitle="true" derivedAnchor="RFC8990">
<organization/> <front>
</author> <title>GeneRic Autonomic Signaling Protocol (GRASP)</title>
<author initials="C." surname="Bormann" fullname="C. Bormann"> <author initials="C" surname="Bormann" fullname="Carsten Bormann">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2019" month="June"/> <author initials="B" surname="Carpenter" fullname="Brian Carpenter"
<abstract> role="editor">
<t>This document proposes a notational convention to express Concise <organization showOnFrontPage="true"/>
Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal </author>
is to provide an easy and unambiguous way to express structures for protocol mes <author initials="B" surname="Liu" fullname="Bing Liu" role="editor"
sages and data formats that use CBOR or JSON.</t> >
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <date month="May" year="2021"/>
<reference anchor="I-D.ietf-anima-bootstrapping-keyinfra" target="http://w </front>
ww.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-43.txt"> <seriesInfo name="RFC" value="8990"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC8990"/>
<title>Bootstrapping Remote Secure Key Infrastructures (BRSKI)</title> </reference>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-bootstrappin <reference anchor="RFC8995" target="https://www.rfc-editor.org/info/rfc8
g-keyinfra-43"/> 995" quoteTitle="true" derivedAnchor="RFC8995">
<author initials="M" surname="Pritikin" fullname="Max Pritikin"> <front>
<organization/> <title>Bootstrapping Remote Secure Key Infrastructure (BRSKI)</title
</author> >
<author initials="M" surname="Richardson" fullname="Michael Richardson <author initials="M" surname="Pritikin" fullname="Max Pritikin">
"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <author initials="M" surname="Richardson" fullname="Michael C. Richa
<author initials="T" surname="Eckert" fullname="Toerless Eckert"> rdson">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M" surname="Behringer" fullname="Michael Behringer"> <author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="K" surname="Watsen" fullname="Kent Watsen"> <author initials="M" surname="Behringer" fullname="Michael H. Behrin
<organization/> ger">
</author> <organization showOnFrontPage="true"/>
<date month="August" day="7" year="2020"/> </author>
<abstract> <author initials="K" surname="Watsen" fullname="Kent Watsen">
<t>This document specifies automated bootstrapping of an Autonomic C <organization showOnFrontPage="true"/>
ontrol Plane. To do this a Secure Key Infrastructure is bootstrapped. This is </author>
done using manufacturer-installed X.509 certificates, in combination with a manu <date month="May" year="2021"/>
facturer's authorizing service, both online and offline. We call this process t </front>
he Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrappin <seriesInfo name="RFC" value="8995"/>
g a new device can occur using a routable address and a cloud service, or using <seriesInfo name="DOI" value="10.17487/RFC8995"/>
only link-local connectivity, or on limited/ disconnected networks. Support for </reference>
deployment models with less stringent security requirements is included. Boots </references>
trapping is complete when the cryptographic identity of the new key infrastructu <references pn="section-13.2">
re is successfully deployed to the device. The established secure connection ca <name slugifiedName="name-informative-references">Informative References
n be used to deploy a locally issued certificate to the device as well.</t> </name>
</abstract> <reference anchor="AR8021" target="https://1.ieee802.org/security/802-1a
</front> r" quoteTitle="true" derivedAnchor="AR8021">
</reference> <front>
<reference anchor="I-D.ietf-anima-grasp" target="http://www.ietf.org/inter <title>IEEE Standard for Local and metropolitan area networks - Secu
net-drafts/draft-ietf-anima-grasp-15.txt"> re Device Identity</title>
<front> <author>
<title>A Generic Autonomic Signaling Protocol (GRASP)</title> <organization showOnFrontPage="true">IEEE</organization>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-grasp-15"/> </author>
<author initials="C" surname="Bormann" fullname="Carsten Bormann"> </front>
<organization/> <seriesInfo name="IEEE" value="802.1AR"/>
</author> </reference>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter"> <reference anchor="CABFORUM" target="https://cabforum.org/baseline-requi
<organization/> rements-certificate-contents/" quoteTitle="true" derivedAnchor="CABFORUM">
</author> <front>
<author initials="B" surname="Liu" fullname="Bing Liu"> <title>Certificate Contents for Baseline SSL</title>
<organization/> <author>
</author> <organization showOnFrontPage="true">CA/Browser Forum</organizatio
<date month="July" day="13" year="2017"/> n>
<abstract> </author>
<t>This document specifies the GeneRic Autonomic Signaling Protocol <date month="Nov" year="2019"/>
(GRASP), which enables autonomic nodes and autonomic service agents to dynamical </front>
ly discover peers, to synchronize state with each other, and to negotiate parame </reference>
ter settings with each other. GRASP depends on an external security environment <reference anchor="FCC" target="https://docs.fcc.gov/public/attachments/
that is described elsewhere. The technical objectives and parameters for speci DOC-367699A1.docx" quoteTitle="true" derivedAnchor="FCC">
fic application scenarios are to be described in separate documents. Appendices <front>
briefly discuss requirements for the protocol and existing protocols with compa <title>June 15, 2020 T-Mobile Network Outage Report</title>
rable features.</t> <author>
</abstract> <organization showOnFrontPage="true">FCC</organization>
</front> </author>
</reference> <date year="2020" month="October"/>
<reference anchor="IKEV2IANA" target="https://www.iana.org/assignments/ike </front>
v2-parameters/ikev2-parameters.xhtml"> <seriesInfo name="PS Docket No." value="20-183"/>
<front> <refcontent>A Report of the Public Safety and Homeland Security Bureau
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title> Federal Communications Commission</refcontent>
<author fullname="IANA"> </reference>
<organization/> <reference anchor="IEEE-1588-2008" target="https://standards.ieee.org/st
</author> andard/1588-2008.html" quoteTitle="true" derivedAnchor="IEEE-1588-2008">
<date/> <front>
</front> <title>IEEE Standard for a Precision Clock Synchronization Protocol
</reference> for Networked Measurement and Control Systems</title>
</references> <author>
<references> <organization showOnFrontPage="true">IEEE</organization>
<name>Informative References</name> </author>
<!-- references whose text got removed over the versions of the doc: <date month="July" year="2008"/>
<?rfc include='reference.RFC.4122'?> - No idea </front>
<?rfc include='reference.RFC.5082'?> - GTSM was consider <seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/>
ed for GRASP, text removed <seriesInfo name="IEEE" value="1588-2008"/>
<?rfc include="reference.I-D.carpenter-anima-ani-objecti </reference>
ves"?> <reference anchor="IEEE-802.1X" target="https://standards.ieee.org/stand
<?rfc include="reference.I-D.richardson-anima-6join-disc ard/802_1X-2010.html" quoteTitle="true" derivedAnchor="IEEE-802.1X">
overy.xml"?> <front>
--> <title>IEEE Standard for Local and metropolitan area networks--Port-
<reference anchor="I-D.ietf-anima-prefix-management" target="http://www.ie Based Network Access Control</title>
tf.org/internet-drafts/draft-ietf-anima-prefix-management-07.txt"> <author>
<front> <organization showOnFrontPage="true">IEEE</organization>
<title>Autonomic IPv6 Edge Prefix Management in Large-scale Networks</ </author>
title> <date month="February" year="2010"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-prefix-manag </front>
ement-07"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5409813"/>
<author initials="S" surname="Jiang" fullname="Sheng Jiang"> <seriesInfo name="IEEE" value="802.1X-2010"/>
<organization/> </reference>
</author> <reference anchor="LLDP" target="https://standards.ieee.org/standard/802
<author initials="Z" surname="Du" fullname="Zongpeng Du"> _1AB-2016.html" quoteTitle="true" derivedAnchor="LLDP">
<organization/> <front>
</author> <title>IEEE Standard for Local and metropolitan area networks: Stati
<author initials="B" surname="Carpenter" fullname="Brian Carpenter"> on and Media Access Control Connectivity Discovery</title>
<organization/> <author>
</author> <organization showOnFrontPage="true">IEEE</organization>
<author initials="Q" surname="Sun" fullname="Qiong Sun"> </author>
<organization/> <date month="March" year="2016"/>
</author> </front>
<date month="December" day="18" year="2017"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7433915"/>
<abstract> <seriesInfo name="IEEE" value="802.1AB-2016"/>
<t>This document defines two autonomic technical objectives for IPv6 </reference>
prefix management at the edge of large-scale ISP networks, with an extension to <reference anchor="MACSEC" target="https://standards.ieee.org/standard/8
support IPv4 prefixes. An important purpose of the document is to use it for v 02_1AE-2006.html" quoteTitle="true" derivedAnchor="MACSEC">
alidation of the design of various components of the autonomic networking infras <front>
tructure.</t> <title>IEEE Standard for Local and Metropolitan Area Networks: Media
</abstract> Access Control (MAC) Security</title>
</front> <author>
</reference> <organization showOnFrontPage="true">IEEE</organization>
<reference anchor="I-D.ietf-acme-star" target="http://www.ietf.org/interne </author>
t-drafts/draft-ietf-acme-star-11.txt"> <date month="August" year="2006"/>
<front> </front>
<title>Support for Short-Term, Automatically-Renewed (STAR) Certificat <seriesInfo name="DOI" value="10.1109/IEEESTD.2006.245590"/>
es in Automated Certificate Management Environment (ACME)</title> <seriesInfo name="IEEE" value="802.1AE-2006"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-acme-star-11"/> </reference>
<author initials="Y" surname="Sheffer" fullname="Yaron Sheffer"> <reference anchor="I-D.eckert-anima-noc-autoconfig" quoteTitle="true" ta
<organization/> rget="https://tools.ietf.org/html/draft-eckert-anima-noc-autoconfig-00" derivedA
</author> nchor="NOC-AUTOCONFIG">
<author initials="D" surname="Lopez" fullname="Diego Lopez"> <front>
<organization/> <title>Autoconfiguration of NOC services in ACP networks via GRASP</
</author> title>
<author initials="O" surname="Dios" fullname="Oscar de Dios"> <author fullname="Toerless Eckert" role="editor">
<organization/> <organization showOnFrontPage="true">Futurewei Technologies Inc.</
</author> organization>
<author initials="A" surname="Pastor" fullname="Antonio Pastor"> </author>
<organization/> <date month="July" day="2" year="2018"/>
</author> </front>
<author initials="T" surname="Fossati" fullname="Thomas Fossati"> <seriesInfo name="Internet-Draft" value="draft-eckert-anima-noc-autoco
<organization/> nfig-00"/>
</author> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ecker
<date month="October" day="24" year="2019"/> t-anima-noc-autoconfig-00.txt"/>
<abstract> <refcontent>Work in Progress</refcontent>
<t>Public-key certificates need to be revoked when they are compromi </reference>
sed, that is, when the associated private key is exposed to an unauthorized enti <reference anchor="OP-TECH" target="https://en.wikipedia.org/w/index.php
ty. However the revocation process is often unreliable. An alternative to revo ?title=Operational_technology&amp;oldid=986363045" quoteTitle="true" derivedAnch
cation is issuing a sequence of certificates, each with a short validity period, or="OP-TECH">
and terminating this sequence upon compromise. This memo proposes an ACME exte <front>
nsion to enable the issuance of short-term and automatically renewed (STAR) X.50 <title>Operational technology</title>
9 certificates. [RFC-Editor: please remove before publication] While the draft <author>
is being developed, the editor's version can be found at https://github.com/yar <organization showOnFrontPage="true">Wikipedia</organization>
onf/I-D/tree/master/STAR.</t> </author>
</abstract> <date month="October" year="2020"/>
</front> </front>
</reference> </reference>
<reference anchor="I-D.ietf-tls-dtls13" target="http://www.ietf.org/intern <reference anchor="RFC1112" target="https://www.rfc-editor.org/info/rfc1
et-drafts/draft-ietf-tls-dtls13-38.txt"> 112" quoteTitle="true" derivedAnchor="RFC1112">
<front> <front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1 <title>Host extensions for IP multicasting</title>
.3</title> <author initials="S.E." surname="Deering" fullname="S.E. Deering">
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-38"/> <organization showOnFrontPage="true"/>
<author initials="E" surname="Rescorla" fullname="Eric Rescorla"> </author>
<organization/> <date year="1989" month="August"/>
</author> <abstract>
<author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig" <t indent="0">This memo specifies the extensions required of a hos
> t implementation of the Internet Protocol (IP) to support multicasting. Recomme
<organization/> nded procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998
</author> and 1054. [STANDARDS-TRACK]</t>
<author initials="N" surname="Modadugu" fullname="Nagendra Modadugu"> </abstract>
<organization/> </front>
</author>
<date month="May" day="29" year="2020"/>
<abstract>
<t>This document specifies Version 1.3 of the Datagram Transport Lay
er Security (DTLS) protocol. DTLS 1.3 allows client/server applications to comm
unicate over the Internet in a way that is designed to prevent eavesdropping, ta
mpering, and message forgery. The DTLS 1.3 protocol is intentionally based on t
he Transport Layer Security (TLS) 1.3 protocol and provides equivalent security
guarantees with the exception of order protection/non-replayability. Datagram se
mantics of the underlying transport are preserved by the DTLS protocol.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1112" target="https://www.rfc-editor.org/info/rfc111
2">
<front>
<title>Host extensions for IP multicasting</title>
<seriesInfo name="DOI" value="10.17487/RFC1112"/>
<seriesInfo name="RFC" value="1112"/>
<seriesInfo name="STD" value="5"/> <seriesInfo name="STD" value="5"/>
<author initials="S.E." surname="Deering" fullname="S.E. Deering"> <seriesInfo name="RFC" value="1112"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC1112"/>
</author> </reference>
<date year="1989" month="August"/> <reference anchor="RFC1492" target="https://www.rfc-editor.org/info/rfc1
<abstract> 492" quoteTitle="true" derivedAnchor="RFC1492">
<t>This memo specifies the extensions required of a host implementat <front>
ion of the Internet Protocol (IP) to support multicasting. Recommended procedur <title>An Access Control Protocol, Sometimes Called TACACS</title>
e for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [ <author initials="C." surname="Finseth" fullname="C. Finseth">
STANDARDS-TRACK]</t> <organization showOnFrontPage="true"/>
</abstract> </author>
</front> <date year="1993" month="July"/>
</reference> <abstract>
<reference anchor="RFC1492" target="https://www.rfc-editor.org/info/rfc149 <t indent="0">This RFC documents the extended TACACS protocol use
2"> by the Cisco Systems terminal servers. This same protocol is used by the Univer
<front> sity of Minnesota's distributed authentication system. This memo provides infor
<title>An Access Control Protocol, Sometimes Called TACACS</title> mation for the Internet community. It does not specify an Internet standard.</t
<seriesInfo name="DOI" value="10.17487/RFC1492"/> >
</abstract>
</front>
<seriesInfo name="RFC" value="1492"/> <seriesInfo name="RFC" value="1492"/>
<author initials="C." surname="Finseth" fullname="C. Finseth"> <seriesInfo name="DOI" value="10.17487/RFC1492"/>
<organization/> </reference>
</author> <reference anchor="RFC1654" target="https://www.rfc-editor.org/info/rfc1
<date year="1993" month="July"/> 654" quoteTitle="true" derivedAnchor="RFC1654">
<abstract> <front>
<t>This RFC documents the extended TACACS protocol use by the Cisco <title>A Border Gateway Protocol 4 (BGP-4)</title>
Systems terminal servers. This same protocol is used by the University of Minne <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="
sota's distributed authentication system. This memo provides information for th editor">
e Internet community. It does not specify an Internet standard.</t> <organization showOnFrontPage="true"/>
</abstract> </author>
</front> <author initials="T." surname="Li" fullname="T. Li" role="editor">
</reference> <organization showOnFrontPage="true"/>
<reference anchor="RFC1654" target="https://www.rfc-editor.org/info/rfc165 </author>
4"> <date year="1994" month="July"/>
<front> <abstract>
<title>A Border Gateway Protocol 4 (BGP-4)</title> <t indent="0">This document defines an inter-autonomous system rou
<seriesInfo name="DOI" value="10.17487/RFC1654"/> ting protocol for the Internet. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1654"/> <seriesInfo name="RFC" value="1654"/>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="ed <seriesInfo name="DOI" value="10.17487/RFC1654"/>
itor"> </reference>
<organization/> <reference anchor="RFC1918" target="https://www.rfc-editor.org/info/rfc1
</author> 918" quoteTitle="true" derivedAnchor="RFC1918">
<author initials="T." surname="Li" fullname="T. Li" role="editor"> <front>
<organization/> <title>Address Allocation for Private Internets</title>
</author> <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<date year="1994" month="July"/> <organization showOnFrontPage="true"/>
<abstract> </author>
<t>This document defines an inter-autonomous system routing protocol <author initials="B." surname="Moskowitz" fullname="B. Moskowitz">
for the Internet. [STANDARDS-TRACK]</t> <organization showOnFrontPage="true"/>
</abstract> </author>
</front> <author initials="D." surname="Karrenberg" fullname="D. Karrenberg">
</reference> <organization showOnFrontPage="true"/>
<reference anchor="RFC1918" target="https://www.rfc-editor.org/info/rfc191 </author>
8"> <author initials="G. J." surname="de Groot" fullname="G. J. de Groot
<front> ">
<title>Address Allocation for Private Internets</title> <organization showOnFrontPage="true"/>
<seriesInfo name="DOI" value="10.17487/RFC1918"/> </author>
<seriesInfo name="RFC" value="1918"/> <author initials="E." surname="Lear" fullname="E. Lear">
<organization showOnFrontPage="true"/>
</author>
<date year="1996" month="February"/>
<abstract>
<t indent="0">This document describes address allocation for priva
te internets. This document specifies an Internet Best Current Practices for th
e Internet Community, and requests discussion and suggestions for improvements.<
/t>
</abstract>
</front>
<seriesInfo name="BCP" value="5"/> <seriesInfo name="BCP" value="5"/>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter"> <seriesInfo name="RFC" value="1918"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC1918"/>
</author> </reference>
<author initials="B." surname="Moskowitz" fullname="B. Moskowitz"> <reference anchor="RFC2315" target="https://www.rfc-editor.org/info/rfc2
<organization/> 315" quoteTitle="true" derivedAnchor="RFC2315">
</author> <front>
<author initials="D." surname="Karrenberg" fullname="D. Karrenberg"> <title>PKCS #7: Cryptographic Message Syntax Version 1.5</title>
<organization/> <author initials="B." surname="Kaliski" fullname="B. Kaliski">
</author> <organization showOnFrontPage="true"/>
<author initials="G. J." surname="de Groot" fullname="G. J. de Groot"> </author>
<organization/> <date year="1998" month="March"/>
</author> <abstract>
<author initials="E." surname="Lear" fullname="E. Lear"> <t indent="0">This document describes a general syntax for data th
<organization/> at may have cryptography applied to it, such as digital signatures and digital e
</author> nvelopes. This memo provides information for the Internet community. It does no
<date year="1996" month="February"/> t specify an Internet standard of any kind.</t>
<abstract> </abstract>
<t>This document describes address allocation for private internets. </front>
This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2315" target="https://www.rfc-editor.org/info/rfc231
5">
<front>
<title>PKCS #7: Cryptographic Message Syntax Version 1.5</title>
<seriesInfo name="DOI" value="10.17487/RFC2315"/>
<seriesInfo name="RFC" value="2315"/> <seriesInfo name="RFC" value="2315"/>
<author initials="B." surname="Kaliski" fullname="B. Kaliski"> <seriesInfo name="DOI" value="10.17487/RFC2315"/>
<organization/> </reference>
</author> <reference anchor="RFC2409" target="https://www.rfc-editor.org/info/rfc2
<date year="1998" month="March"/> 409" quoteTitle="true" derivedAnchor="RFC2409">
<abstract> <front>
<t>This document describes a general syntax for data that may have c <title>The Internet Key Exchange (IKE)</title>
ryptography applied to it, such as digital signatures and digital envelopes. Th <author initials="D." surname="Harkins" fullname="D. Harkins">
is memo provides information for the Internet community. It does not specify an <organization showOnFrontPage="true"/>
Internet standard of any kind.</t> </author>
</abstract> <author initials="D." surname="Carrel" fullname="D. Carrel">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
<reference anchor="RFC2409" target="https://www.rfc-editor.org/info/rfc240 <date year="1998" month="November"/>
9"> <abstract>
<front> <t indent="0">This memo describes a hybrid protocol. The purpose i
<title>The Internet Key Exchange (IKE)</title> s to negotiate, and provide authenticated keying material for, security associat
<seriesInfo name="DOI" value="10.17487/RFC2409"/> ions in a protected manner. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2409"/> <seriesInfo name="RFC" value="2409"/>
<author initials="D." surname="Harkins" fullname="D. Harkins"> <seriesInfo name="DOI" value="10.17487/RFC2409"/>
<organization/> </reference>
</author> <reference anchor="RFC2865" target="https://www.rfc-editor.org/info/rfc2
<author initials="D." surname="Carrel" fullname="D. Carrel"> 865" quoteTitle="true" derivedAnchor="RFC2865">
<organization/> <front>
</author> <title>Remote Authentication Dial In User Service (RADIUS)</title>
<date year="1998" month="November"/> <author initials="C." surname="Rigney" fullname="C. Rigney">
<abstract> <organization showOnFrontPage="true"/>
<t>This memo describes a hybrid protocol. The purpose is to negotiat </author>
e, and provide authenticated keying material for, security associations in a pro <author initials="S." surname="Willens" fullname="S. Willens">
tected manner. [STANDARDS-TRACK]</t> <organization showOnFrontPage="true"/>
</abstract> </author>
</front> <author initials="A." surname="Rubens" fullname="A. Rubens">
</reference> <organization showOnFrontPage="true"/>
<reference anchor="RFC2865" target="https://www.rfc-editor.org/info/rfc286 </author>
5"> <author initials="W." surname="Simpson" fullname="W. Simpson">
<front> <organization showOnFrontPage="true"/>
<title>Remote Authentication Dial In User Service (RADIUS)</title> </author>
<seriesInfo name="DOI" value="10.17487/RFC2865"/> <date year="2000" month="June"/>
<abstract>
<t indent="0">This document describes a protocol for carrying auth
entication, authorization, and configuration information between a Network Acces
s Server which desires to authenticate its links and a shared Authentication Ser
ver. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2865"/> <seriesInfo name="RFC" value="2865"/>
<author initials="C." surname="Rigney" fullname="C. Rigney"> <seriesInfo name="DOI" value="10.17487/RFC2865"/>
<organization/> </reference>
</author> <reference anchor="RFC3164" target="https://www.rfc-editor.org/info/rfc3
<author initials="S." surname="Willens" fullname="S. Willens"> 164" quoteTitle="true" derivedAnchor="RFC3164">
<organization/> <front>
</author> <title>The BSD Syslog Protocol</title>
<author initials="A." surname="Rubens" fullname="A. Rubens"> <author initials="C." surname="Lonvick" fullname="C. Lonvick">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="W." surname="Simpson" fullname="W. Simpson"> <date year="2001" month="August"/>
<organization/> <abstract>
</author> <t indent="0">This document describes the observed behavior of the
<date year="2000" month="June"/> syslog protocol. This memo provides information for the Internet community.</t>
<abstract> </abstract>
<t>This document describes a protocol for carrying authentication, a </front>
uthorization, and configuration information between a Network Access Server whic
h desires to authenticate its links and a shared Authentication Server. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3164" target="https://www.rfc-editor.org/info/rfc316
4">
<front>
<title>The BSD Syslog Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC3164"/>
<seriesInfo name="RFC" value="3164"/> <seriesInfo name="RFC" value="3164"/>
<author initials="C." surname="Lonvick" fullname="C. Lonvick"> <seriesInfo name="DOI" value="10.17487/RFC3164"/>
<organization/> </reference>
</author> <reference anchor="RFC3315" target="https://www.rfc-editor.org/info/rfc3
<date year="2001" month="August"/> 315" quoteTitle="true" derivedAnchor="RFC3315">
<abstract> <front>
<t>This document describes the observed behavior of the syslog proto <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
col. This memo provides information for the Internet community.</t> <author initials="R." surname="Droms" fullname="R. Droms" role="edit
</abstract> or">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
<reference anchor="RFC3315" target="https://www.rfc-editor.org/info/rfc331 <author initials="J." surname="Bound" fullname="J. Bound">
5"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title> <author initials="B." surname="Volz" fullname="B. Volz">
<seriesInfo name="DOI" value="10.17487/RFC3315"/> <organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Lemon" fullname="T. Lemon">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Carney" fullname="M. Carney">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="July"/>
</front>
<seriesInfo name="RFC" value="3315"/> <seriesInfo name="RFC" value="3315"/>
<author initials="R." surname="Droms" fullname="R. Droms" role="editor <seriesInfo name="DOI" value="10.17487/RFC3315"/>
"> </reference>
<organization/> <reference anchor="RFC3411" target="https://www.rfc-editor.org/info/rfc3
</author> 411" quoteTitle="true" derivedAnchor="RFC3411">
<author initials="J." surname="Bound" fullname="J. Bound"> <front>
<organization/> <title>An Architecture for Describing Simple Network Management Prot
</author> ocol (SNMP) Management Frameworks</title>
<author initials="B." surname="Volz" fullname="B. Volz"> <author initials="D." surname="Harrington" fullname="D. Harrington">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="T." surname="Lemon" fullname="T. Lemon"> <author initials="R." surname="Presuhn" fullname="R. Presuhn">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="C." surname="Perkins" fullname="C. Perkins"> <author initials="B." surname="Wijnen" fullname="B. Wijnen">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Carney" fullname="M. Carney"> <date year="2002" month="December"/>
<organization/> <abstract>
</author> <t indent="0">This document describes an architecture for describi
<date year="2003" month="July"/> ng Simple Network Management Protocol (SNMP) Management Frameworks. The archite
</front> cture is designed to be modular to allow the evolution of the SNMP protocol stan
</reference> dards over time. The major portions of the architecture are an SNMP engine cont
<reference anchor="RFC3411" target="https://www.rfc-editor.org/info/rfc341 aining a Message Processing Subsystem, a Security Subsystem and an Access Contro
1"> l Subsystem, and possibly multiple SNMP applications which provide specific func
<front> tional processing of management data. This document obsoletes RFC 2571. [STAND
<title>An Architecture for Describing Simple Network Management Protoc ARDS-TRACK]</t>
ol (SNMP) Management Frameworks</title> </abstract>
<seriesInfo name="DOI" value="10.17487/RFC3411"/> </front>
<seriesInfo name="RFC" value="3411"/>
<seriesInfo name="STD" value="62"/> <seriesInfo name="STD" value="62"/>
<author initials="D." surname="Harrington" fullname="D. Harrington"> <seriesInfo name="RFC" value="3411"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC3411"/>
</author> </reference>
<author initials="R." surname="Presuhn" fullname="R. Presuhn"> <reference anchor="RFC3596" target="https://www.rfc-editor.org/info/rfc3
<organization/> 596" quoteTitle="true" derivedAnchor="RFC3596">
</author> <front>
<author initials="B." surname="Wijnen" fullname="B. Wijnen"> <title>DNS Extensions to Support IP Version 6</title>
<organization/> <author initials="S." surname="Thomson" fullname="S. Thomson">
</author> <organization showOnFrontPage="true"/>
<date year="2002" month="December"/> </author>
<abstract> <author initials="C." surname="Huitema" fullname="C. Huitema">
<t>This document describes an architecture for describing Simple Net <organization showOnFrontPage="true"/>
work Management Protocol (SNMP) Management Frameworks. The architecture is desi </author>
gned to be modular to allow the evolution of the SNMP protocol standards over ti <author initials="V." surname="Ksinant" fullname="V. Ksinant">
me. The major portions of the architecture are an SNMP engine containing a Mess <organization showOnFrontPage="true"/>
age Processing Subsystem, a Security Subsystem and an Access Control Subsystem, </author>
and possibly multiple SNMP applications which provide specific functional proces <author initials="M." surname="Souissi" fullname="M. Souissi">
sing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]</ <organization showOnFrontPage="true"/>
t> </author>
</abstract> <date year="2003" month="October"/>
</front> <abstract>
</reference> <t indent="0">This document defines the changes that need to be ma
<reference anchor="RFC3596" target="https://www.rfc-editor.org/info/rfc359 de to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6).
6"> The changes include a resource record type to store an IPv6 address, a domain
<front> to support lookups based on an IPv6 address, and updated definitions of existing
<title>DNS Extensions to Support IP Version 6</title> query types that return Internet addresses as part of additional section proces
<seriesInfo name="DOI" value="10.17487/RFC3596"/> sing. The extensions are designed to be compatible with existing applications a
<seriesInfo name="RFC" value="3596"/> nd, in particular, DNS implementations themselves. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="88"/> <seriesInfo name="STD" value="88"/>
<author initials="S." surname="Thomson" fullname="S. Thomson"> <seriesInfo name="RFC" value="3596"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC3596"/>
</author> </reference>
<author initials="C." surname="Huitema" fullname="C. Huitema"> <reference anchor="RFC3954" target="https://www.rfc-editor.org/info/rfc3
<organization/> 954" quoteTitle="true" derivedAnchor="RFC3954">
</author> <front>
<author initials="V." surname="Ksinant" fullname="V. Ksinant"> <title>Cisco Systems NetFlow Services Export Version 9</title>
<organization/> <author initials="B." surname="Claise" fullname="B. Claise" role="ed
</author> itor">
<author initials="M." surname="Souissi" fullname="M. Souissi"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <date year="2004" month="October"/>
<date year="2003" month="October"/> <abstract>
<abstract> <t indent="0">This document specifies the data export format for v
<t>This document defines the changes that need to be made to the Dom ersion 9 of Cisco Systems' NetFlow services, for use by implementations on the n
ain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes etwork elements and/or matching collector programs. The version 9 export format
include a resource record type to store an IPv6 address, a domain to support lo uses templates to provide access to observations of IP packet flows in a flexib
okups based on an IPv6 address, and updated definitions of existing query types le and extensible manner. A template defines a collection of fields, with corre
that return Internet addresses as part of additional section processing. The ex sponding descriptions of structure and semantics. This memo provides informatio
tensions are designed to be compatible with existing applications and, in partic n for the Internet community.</t>
ular, DNS implementations themselves. [STANDARDS-TRACK]</t> </abstract>
</abstract> </front>
</front>
</reference>
<reference anchor="RFC3920" target="https://www.rfc-editor.org/info/rfc392
0">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<seriesInfo name="DOI" value="10.17487/RFC3920"/>
<seriesInfo name="RFC" value="3920"/>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre"
role="editor">
<organization/>
</author>
<date year="2004" month="October"/>
<abstract>
<t>This memo defines the core features of the Extensible Messaging a
nd Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language
(XML) elements in order to exchange structured information in close to real tim
e between any two network endpoints. While XMPP provides a generalized, extensi
ble framework for exchanging XML data, it is used mainly for the purpose of buil
ding instant messaging and presence applications that meet the requirements of R
FC 2779. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3954" target="https://www.rfc-editor.org/info/rfc395
4">
<front>
<title>Cisco Systems NetFlow Services Export Version 9</title>
<seriesInfo name="DOI" value="10.17487/RFC3954"/>
<seriesInfo name="RFC" value="3954"/> <seriesInfo name="RFC" value="3954"/>
<author initials="B." surname="Claise" fullname="B. Claise" role="edit <seriesInfo name="DOI" value="10.17487/RFC3954"/>
or"> </reference>
<organization/> <reference anchor="RFC4007" target="https://www.rfc-editor.org/info/rfc4
</author> 007" quoteTitle="true" derivedAnchor="RFC4007">
<date year="2004" month="October"/> <front>
<abstract> <title>IPv6 Scoped Address Architecture</title>
<t>This document specifies the data export format for version 9 of C <author initials="S." surname="Deering" fullname="S. Deering">
isco Systems' NetFlow services, for use by implementations on the network elemen <organization showOnFrontPage="true"/>
ts and/or matching collector programs. The version 9 export format uses templat </author>
es to provide access to observations of IP packet flows in a flexible and extens <author initials="B." surname="Haberman" fullname="B. Haberman">
ible manner. A template defines a collection of fields, with corresponding desc <organization showOnFrontPage="true"/>
riptions of structure and semantics. This memo provides information for the Int </author>
ernet community.</t> <author initials="T." surname="Jinmei" fullname="T. Jinmei">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <author initials="E." surname="Nordmark" fullname="E. Nordmark">
<reference anchor="RFC4007" target="https://www.rfc-editor.org/info/rfc400 <organization showOnFrontPage="true"/>
7"> </author>
<front> <author initials="B." surname="Zill" fullname="B. Zill">
<title>IPv6 Scoped Address Architecture</title> <organization showOnFrontPage="true"/>
<seriesInfo name="DOI" value="10.17487/RFC4007"/> </author>
<date year="2005" month="March"/>
<abstract>
<t indent="0">This document specifies the architectural characteri
stics, expected behavior, textual representation, and usage of IPv6 addresses of
different scopes. According to a decision in the IPv6 working group, this docu
ment intentionally avoids the syntax and usage of unicast site-local addresses.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4007"/> <seriesInfo name="RFC" value="4007"/>
<author initials="S." surname="Deering" fullname="S. Deering"> <seriesInfo name="DOI" value="10.17487/RFC4007"/>
<organization/> </reference>
</author> <reference anchor="RFC4210" target="https://www.rfc-editor.org/info/rfc4
<author initials="B." surname="Haberman" fullname="B. Haberman"> 210" quoteTitle="true" derivedAnchor="RFC4210">
<organization/> <front>
</author> <title>Internet X.509 Public Key Infrastructure Certificate Manageme
<author initials="T." surname="Jinmei" fullname="T. Jinmei"> nt Protocol (CMP)</title>
<organization/> <author initials="C." surname="Adams" fullname="C. Adams">
</author> <organization showOnFrontPage="true"/>
<author initials="E." surname="Nordmark" fullname="E. Nordmark"> </author>
<organization/> <author initials="S." surname="Farrell" fullname="S. Farrell">
</author> <organization showOnFrontPage="true"/>
<author initials="B." surname="Zill" fullname="B. Zill"> </author>
<organization/> <author initials="T." surname="Kause" fullname="T. Kause">
</author> <organization showOnFrontPage="true"/>
<date year="2005" month="March"/> </author>
<abstract> <author initials="T." surname="Mononen" fullname="T. Mononen">
<t>This document specifies the architectural characteristics, expect <organization showOnFrontPage="true"/>
ed behavior, textual representation, and usage of IPv6 addresses of different sc </author>
opes. According to a decision in the IPv6 working group, this document intentio <date year="2005" month="September"/>
nally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-T <abstract>
RACK]</t> <t indent="0">This document describes the Internet X.509 Public Ke
</abstract> y Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages
</front> are defined for X.509v3 certificate creation and management. CMP provides on-l
</reference> ine interactions between PKI components, including an exchange between a Certifi
<reference anchor="RFC4210" target="https://www.rfc-editor.org/info/rfc421 cation Authority (CA) and a client system. [STANDARDS-TRACK]</t>
0"> </abstract>
<front> </front>
<title>Internet X.509 Public Key Infrastructure Certificate Management
Protocol (CMP)</title>
<seriesInfo name="DOI" value="10.17487/RFC4210"/>
<seriesInfo name="RFC" value="4210"/> <seriesInfo name="RFC" value="4210"/>
<author initials="C." surname="Adams" fullname="C. Adams"> <seriesInfo name="DOI" value="10.17487/RFC4210"/>
<organization/> </reference>
</author> <reference anchor="RFC4364" target="https://www.rfc-editor.org/info/rfc4
<author initials="S." surname="Farrell" fullname="S. Farrell"> 364" quoteTitle="true" derivedAnchor="RFC4364">
<organization/> <front>
</author> <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<author initials="T." surname="Kause" fullname="T. Kause"> <author initials="E." surname="Rosen" fullname="E. Rosen">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="T." surname="Mononen" fullname="T. Mononen"> <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2005" month="September"/> <date year="2006" month="February"/>
<abstract> <abstract>
<t>This document describes the Internet X.509 Public Key Infrastruct <t indent="0">This document describes a method by which a Service
ure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) fo
for X.509v3 certificate creation and management. CMP provides on-line interacti r its customers. This method uses a "peer model", in which the customers' edge
ons between PKI components, including an exchange between a Certification Author routers (CE routers) send their routes to the Service Provider's edge routers (P
ity (CA) and a client system. [STANDARDS-TRACK]</t> E routers); there is no "overlay" visible to the customer's routing algorithm, a
</abstract> nd CE routers at different sites do not peer with each other. Data packets are
</front> tunneled through the backbone, so that the core routers do not need to know the
</reference> VPN routes. [STANDARDS-TRACK]</t>
<reference anchor="RFC4364" target="https://www.rfc-editor.org/info/rfc436 </abstract>
4"> </front>
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<seriesInfo name="DOI" value="10.17487/RFC4364"/>
<seriesInfo name="RFC" value="4364"/> <seriesInfo name="RFC" value="4364"/>
<author initials="E." surname="Rosen" fullname="E. Rosen"> <seriesInfo name="DOI" value="10.17487/RFC4364"/>
<organization/> </reference>
</author> <reference anchor="RFC4429" target="https://www.rfc-editor.org/info/rfc4
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter"> 429" quoteTitle="true" derivedAnchor="RFC4429">
<organization/> <front>
</author> <title>Optimistic Duplicate Address Detection (DAD) for IPv6</title>
<date year="2006" month="February"/> <author initials="N." surname="Moore" fullname="N. Moore">
<abstract> <organization showOnFrontPage="true"/>
<t>This document describes a method by which a Service Provider may </author>
use an IP backbone to provide IP Virtual Private Networks (VPNs) for its custome <date year="2006" month="April"/>
rs. This method uses a "peer model", in which the customers' edge routers (CE r <abstract>
outers) send their routes to the Service Provider's edge routers (PE routers); t <t indent="0">Optimistic Duplicate Address Detection is an interop
here is no "overlay" visible to the customer's routing algorithm, and CE routers erable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and State
at different sites do not peer with each other. Data packets are tunneled thro less Address Autoconfiguration (RFC 2462) processes. The intention is to minimi
ugh the backbone, so that the core routers do not need to know the VPN routes. ze address configuration delays in the successful case, to reduce disruption as
[STANDARDS-TRACK]</t> far as possible in the failure case, and to remain interoperable with unmodified
</abstract> hosts and routers. [STANDARDS-TRACK]</t>
</front> </abstract>
</reference> </front>
<reference anchor="RFC4429" target="https://www.rfc-editor.org/info/rfc442
9">
<front>
<title>Optimistic Duplicate Address Detection (DAD) for IPv6</title>
<seriesInfo name="DOI" value="10.17487/RFC4429"/>
<seriesInfo name="RFC" value="4429"/> <seriesInfo name="RFC" value="4429"/>
<author initials="N." surname="Moore" fullname="N. Moore"> <seriesInfo name="DOI" value="10.17487/RFC4429"/>
<organization/> </reference>
</author> <reference anchor="RFC4541" target="https://www.rfc-editor.org/info/rfc4
<date year="2006" month="April"/> 541" quoteTitle="true" derivedAnchor="RFC4541">
<abstract> <front>
<t>Optimistic Duplicate Address Detection is an interoperable modifi <title>Considerations for Internet Group Management Protocol (IGMP)
cation of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address and Multicast Listener Discovery (MLD) Snooping Switches</title>
Autoconfiguration (RFC 2462) processes. The intention is to minimize address co <author initials="M." surname="Christensen" fullname="M. Christensen
nfiguration delays in the successful case, to reduce disruption as far as possib ">
le in the failure case, and to remain interoperable with unmodified hosts and ro <organization showOnFrontPage="true"/>
uters. [STANDARDS-TRACK]</t> </author>
</abstract> <author initials="K." surname="Kimball" fullname="K. Kimball">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
<reference anchor="RFC4541" target="https://www.rfc-editor.org/info/rfc454 <author initials="F." surname="Solensky" fullname="F. Solensky">
1"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Considerations for Internet Group Management Protocol (IGMP) an <date year="2006" month="May"/>
d Multicast Listener Discovery (MLD) Snooping Switches</title> <abstract>
<seriesInfo name="DOI" value="10.17487/RFC4541"/> <t indent="0">This memo describes the recommendations for Internet
Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snoopin
g switches. These are based on best current practices for IGMPv2, with further
considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, s
uch as link layer topology changes and Ethernet-specific encapsulation issues, a
re also considered. This memo provides information for the Internet community.<
/t>
</abstract>
</front>
<seriesInfo name="RFC" value="4541"/> <seriesInfo name="RFC" value="4541"/>
<author initials="M." surname="Christensen" fullname="M. Christensen"> <seriesInfo name="DOI" value="10.17487/RFC4541"/>
<organization/> </reference>
</author> <reference anchor="RFC4604" target="https://www.rfc-editor.org/info/rfc4
<author initials="K." surname="Kimball" fullname="K. Kimball"> 604" quoteTitle="true" derivedAnchor="RFC4604">
<organization/> <front>
</author> <title>Using Internet Group Management Protocol Version 3 (IGMPv3) a
<author initials="F." surname="Solensky" fullname="F. Solensky"> nd Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific M
<organization/> ulticast</title>
</author> <author initials="H." surname="Holbrook" fullname="H. Holbrook">
<date year="2006" month="May"/> <organization showOnFrontPage="true"/>
<abstract> </author>
<t>This memo describes the recommendations for Internet Group Manage <author initials="B." surname="Cain" fullname="B. Cain">
ment Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. <organization showOnFrontPage="true"/>
These are based on best current practices for IGMPv2, with further consideration </author>
s for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link l <author initials="B." surname="Haberman" fullname="B. Haberman">
ayer topology changes and Ethernet-specific encapsulation issues, are also consi <organization showOnFrontPage="true"/>
dered. This memo provides information for the Internet community.</t> </author>
</abstract> <date year="2006" month="August"/>
</front> <abstract>
</reference> <t indent="0">The Internet Group Management Protocol Version 3 (IG
<reference anchor="RFC4604" target="https://www.rfc-editor.org/info/rfc460 MPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protoc
4"> ols that allow a host to inform its neighboring routers of its desire to receive
<front> IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast
<title>Using Internet Group Management Protocol Version 3 (IGMPv3) and (SSM) is a form of multicast in which a receiver is required to specify both the
Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Mul network-layer address of the source and the multicast destination address in or
ticast</title> der to receive the multicast transmission. This document defines the notion of
<seriesInfo name="DOI" value="10.17487/RFC4604"/> an "SSM-aware" router and host, and clarifies and (in some cases) modifies the b
ehavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source
-specific multicast. This document updates the IGMPv3 and MLDv2 specifications.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4604"/> <seriesInfo name="RFC" value="4604"/>
<author initials="H." surname="Holbrook" fullname="H. Holbrook"> <seriesInfo name="DOI" value="10.17487/RFC4604"/>
<organization/> </reference>
</author> <reference anchor="RFC4607" target="https://www.rfc-editor.org/info/rfc4
<author initials="B." surname="Cain" fullname="B. Cain"> 607" quoteTitle="true" derivedAnchor="RFC4607">
<organization/> <front>
</author> <title>Source-Specific Multicast for IP</title>
<author initials="B." surname="Haberman" fullname="B. Haberman"> <author initials="H." surname="Holbrook" fullname="H. Holbrook">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2006" month="August"/> <author initials="B." surname="Cain" fullname="B. Cain">
<abstract> <organization showOnFrontPage="true"/>
<t>The Internet Group Management Protocol Version 3 (IGMPv3) and the </author>
Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allo <date year="2006" month="August"/>
w a host to inform its neighboring routers of its desire to receive IPv4 and IPv <abstract>
6 multicast transmissions, respectively. Source-specific multicast (SSM) is a fo <t indent="0">IP version 4 (IPv4) addresses in the 232/8 (232.0.0.
rm of multicast in which a receiver is required to specify both the network-laye 0 to 232.255.255.255) range are designated as source-specific multicast (SSM) de
r address of the source and the multicast destination address in order to receiv stination addresses and are reserved for use by source-specific applications and
e the multicast transmission. This document defines the notion of an "SSM-aware protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved f
" router and host, and clarifies and (in some cases) modifies the behavior of IG or source-specific multicast use. This document defines an extension to the Int
MPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific mul ernet network service that applies to datagrams sent to SSM addresses and define
ticast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS- s the host and router requirements to support this extension. [STANDARDS-TRACK]
TRACK]</t> </t>
</abstract> </abstract>
</front> </front>
</reference>
<reference anchor="RFC4607" target="https://www.rfc-editor.org/info/rfc460
7">
<front>
<title>Source-Specific Multicast for IP</title>
<seriesInfo name="DOI" value="10.17487/RFC4607"/>
<seriesInfo name="RFC" value="4607"/> <seriesInfo name="RFC" value="4607"/>
<author initials="H." surname="Holbrook" fullname="H. Holbrook"> <seriesInfo name="DOI" value="10.17487/RFC4607"/>
<organization/> </reference>
</author> <reference anchor="RFC4610" target="https://www.rfc-editor.org/info/rfc4
<author initials="B." surname="Cain" fullname="B. Cain"> 610" quoteTitle="true" derivedAnchor="RFC4610">
<organization/> <front>
</author> <title>Anycast-RP Using Protocol Independent Multicast (PIM)</title>
<date year="2006" month="August"/> <author initials="D." surname="Farinacci" fullname="D. Farinacci">
<abstract> <organization showOnFrontPage="true"/>
<t>IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255. </author>
255.255) range are designated as source-specific multicast (SSM) destination add <author initials="Y." surname="Cai" fullname="Y. Cai">
resses and are reserved for use by source-specific applications and protocols. <organization showOnFrontPage="true"/>
For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-spe </author>
cific multicast use. This document defines an extension to the Internet network <date year="2006" month="August"/>
service that applies to datagrams sent to SSM addresses and defines the host an <abstract>
d router requirements to support this extension. [STANDARDS-TRACK]</t> <t indent="0">This specification allows Anycast-RP (Rendezvous Poi
</abstract> nt) to be used inside a domain that runs Protocol Independent Multicast (PIM) on
</front> ly. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP
</reference> ), which has been used traditionally to solve this problem) are not required to
<reference anchor="RFC4610" target="https://www.rfc-editor.org/info/rfc461 support Anycast-RP. [STANDARDS-TRACK]</t>
0"> </abstract>
<front> </front>
<title>Anycast-RP Using Protocol Independent Multicast (PIM)</title>
<seriesInfo name="DOI" value="10.17487/RFC4610"/>
<seriesInfo name="RFC" value="4610"/> <seriesInfo name="RFC" value="4610"/>
<author initials="D." surname="Farinacci" fullname="D. Farinacci"> <seriesInfo name="DOI" value="10.17487/RFC4610"/>
<organization/> </reference>
</author> <reference anchor="RFC4985" target="https://www.rfc-editor.org/info/rfc4
<author initials="Y." surname="Cai" fullname="Y. Cai"> 985" quoteTitle="true" derivedAnchor="RFC4985">
<organization/> <front>
</author> <title>Internet X.509 Public Key Infrastructure Subject Alternative
<date year="2006" month="August"/> Name for Expression of Service Name</title>
<abstract> <author initials="S." surname="Santesson" fullname="S. Santesson">
<t>This specification allows Anycast-RP (Rendezvous Point) to be use <organization showOnFrontPage="true"/>
d inside a domain that runs Protocol Independent Multicast (PIM) only. Other mul </author>
ticast protocols (such as Multicast Source Discovery Protocol (MSDP), which has <date year="2007" month="August"/>
been used traditionally to solve this problem) are not required to support Anyca <abstract>
st-RP. [STANDARDS-TRACK]</t> <t indent="0">This document defines a new name form for inclusion
</abstract> in the otherName field of an X.509 Subject Alternative Name extension that allow
</front> s a certificate subject to be associated with the service name and domain name c
</reference> omponents of a DNS Service Resource Record. [STANDARDS-TRACK]</t>
<reference anchor="RFC4941" target="https://www.rfc-editor.org/info/rfc494 </abstract>
1"> </front>
<front>
<title>Privacy Extensions for Stateless Address Autoconfiguration in I
Pv6</title>
<seriesInfo name="DOI" value="10.17487/RFC4941"/>
<seriesInfo name="RFC" value="4941"/>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization/>
</author>
<author initials="R." surname="Draves" fullname="R. Draves">
<organization/>
</author>
<author initials="S." surname="Krishnan" fullname="S. Krishnan">
<organization/>
</author>
<date year="2007" month="September"/>
<abstract>
<t>Nodes use IPv6 stateless address autoconfiguration to generate ad
dresses using a combination of locally available information and information adv
ertised by routers. Addresses are formed by combining network prefixes with an
interface identifier. On an interface that contains an embedded IEEE Identifier
, the interface identifier is typically derived from it. On other interface typ
es, the interface identifier is generated through other means, for example, via
random number generation. This document describes an extension to IPv6 stateles
s address autoconfiguration for interfaces whose interface identifier is derived
from an IEEE identifier. Use of the extension causes nodes to generate global
scope addresses from interface identifiers that change over time, even in cases
where the interface contains an embedded IEEE identifier. Changing the interfac
e identifier (and the global scope addresses generated from it) over time makes
it more difficult for eavesdroppers and other information collectors to identify
when different addresses used in different transactions actually correspond to
the same node. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4985" target="https://www.rfc-editor.org/info/rfc498
5">
<front>
<title>Internet X.509 Public Key Infrastructure Subject Alternative Na
me for Expression of Service Name</title>
<seriesInfo name="DOI" value="10.17487/RFC4985"/>
<seriesInfo name="RFC" value="4985"/> <seriesInfo name="RFC" value="4985"/>
<author initials="S." surname="Santesson" fullname="S. Santesson"> <seriesInfo name="DOI" value="10.17487/RFC4985"/>
<organization/> </reference>
</author> <reference anchor="RFC5790" target="https://www.rfc-editor.org/info/rfc5
<date year="2007" month="August"/> 790" quoteTitle="true" derivedAnchor="RFC5790">
<abstract> <front>
<t>This document defines a new name form for inclusion in the otherN <title>Lightweight Internet Group Management Protocol Version 3 (IGM
ame field of an X.509 Subject Alternative Name extension that allows a certifica Pv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols</title>
te subject to be associated with the service name and domain name components of <author initials="H." surname="Liu" fullname="H. Liu">
a DNS Service Resource Record. [STANDARDS-TRACK]</t> <organization showOnFrontPage="true"/>
</abstract> </author>
</front> <author initials="W." surname="Cao" fullname="W. Cao">
</reference> <organization showOnFrontPage="true"/>
<reference anchor="RFC5790" target="https://www.rfc-editor.org/info/rfc579 </author>
0"> <author initials="H." surname="Asaeda" fullname="H. Asaeda">
<front> <organization showOnFrontPage="true"/>
<title>Lightweight Internet Group Management Protocol Version 3 (IGMPv </author>
3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols</title> <date year="2010" month="February"/>
<seriesInfo name="DOI" value="10.17487/RFC5790"/> <abstract>
<t indent="0">This document describes lightweight IGMPv3 and MLDv2
protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) version
s of IGMPv3 and MLDv2. The interoperability with the full versions and the prev
ious versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK]</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="5790"/> <seriesInfo name="RFC" value="5790"/>
<author initials="H." surname="Liu" fullname="H. Liu"> <seriesInfo name="DOI" value="10.17487/RFC5790"/>
<organization/> </reference>
</author> <reference anchor="RFC5880" target="https://www.rfc-editor.org/info/rfc5
<author initials="W." surname="Cao" fullname="W. Cao"> 880" quoteTitle="true" derivedAnchor="RFC5880">
<organization/> <front>
</author> <title>Bidirectional Forwarding Detection (BFD)</title>
<author initials="H." surname="Asaeda" fullname="H. Asaeda"> <author initials="D." surname="Katz" fullname="D. Katz">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2010" month="February"/> <author initials="D." surname="Ward" fullname="D. Ward">
<abstract> <organization showOnFrontPage="true"/>
<t>This document describes lightweight IGMPv3 and MLDv2 protocols (L </author>
W- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 a <date year="2010" month="June"/>
nd MLDv2. The interoperability with the full versions and the previous versions <abstract>
of IGMP and MLD is also taken into account. [STANDARDS-TRACK]</t> <t indent="0">This document describes a protocol intended to detec
</abstract> t faults in the bidirectional path between two forwarding engines, including int
</front> erfaces, data link(s), and to the extent possible the forwarding engines themsel
</reference> ves, with potentially very low latency. It operates independently of media, dat
<reference anchor="RFC5880" target="https://www.rfc-editor.org/info/rfc588 a protocols, and routing protocols. [STANDARDS-TRACK]</t>
0"> </abstract>
<front> </front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<seriesInfo name="DOI" value="10.17487/RFC5880"/>
<seriesInfo name="RFC" value="5880"/> <seriesInfo name="RFC" value="5880"/>
<author initials="D." surname="Katz" fullname="D. Katz"> <seriesInfo name="DOI" value="10.17487/RFC5880"/>
<organization/> </reference>
</author> <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5
<author initials="D." surname="Ward" fullname="D. Ward"> 905" quoteTitle="true" derivedAnchor="RFC5905">
<organization/> <front>
</author> <title>Network Time Protocol Version 4: Protocol and Algorithms Spec
<date year="2010" month="June"/> ification</title>
<abstract> <author initials="D." surname="Mills" fullname="D. Mills">
<t>This document describes a protocol intended to detect faults in t <organization showOnFrontPage="true"/>
he bidirectional path between two forwarding engines, including interfaces, data </author>
link(s), and to the extent possible the forwarding engines themselves, with pot <author initials="J." surname="Martin" fullname="J. Martin" role="ed
entially very low latency. It operates independently of media, data protocols, itor">
and routing protocols. [STANDARDS-TRACK]</t> <organization showOnFrontPage="true"/>
</abstract> </author>
</front> <author initials="J." surname="Burbank" fullname="J. Burbank">
</reference> <organization showOnFrontPage="true"/>
<reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc590 </author>
5"> <author initials="W." surname="Kasch" fullname="W. Kasch">
<front> <organization showOnFrontPage="true"/>
<title>Network Time Protocol Version 4: Protocol and Algorithms Specif </author>
ication</title> <date year="2010" month="June"/>
<seriesInfo name="DOI" value="10.17487/RFC5905"/> <abstract>
<t indent="0">The Network Time Protocol (NTP) is widely used to sy
nchronize computer clocks in the Internet. This document describes NTP version
4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described i
n RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modif
ied protocol header to accommodate the Internet Protocol version 6 address famil
y. NTPv4 includes fundamental improvements in the mitigation and discipline alg
orithms that extend the potential accuracy to the tens of microseconds with mode
rn workstations and fast LANs. It includes a dynamic server discovery scheme, s
o that in many cases, specific server configuration is not required. It correct
s certain errors in the NTPv3 design and implementation and includes an optional
extension mechanism. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5905"/> <seriesInfo name="RFC" value="5905"/>
<author initials="D." surname="Mills" fullname="D. Mills"> <seriesInfo name="DOI" value="10.17487/RFC5905"/>
<organization/> </reference>
</author> <reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5
<author initials="J." surname="Martin" fullname="J. Martin" role="edit 912" quoteTitle="true" derivedAnchor="RFC5912">
or"> <front>
<organization/> <title>New ASN.1 Modules for the Public Key Infrastructure Using X.5
</author> 09 (PKIX)</title>
<author initials="J." surname="Burbank" fullname="J. Burbank"> <author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="W." surname="Kasch" fullname="W. Kasch"> <author initials="J." surname="Schaad" fullname="J. Schaad">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2010" month="June"/> <date year="2010" month="June"/>
<abstract> <abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize com <t indent="0">The Public Key Infrastructure using X.509 (PKIX) cer
puter clocks in the Internet. This document describes NTP version 4 (NTPv4), wh tificate format, and many associated formats, are expressed using ASN.1. The cu
ich is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, a rrent ASN.1 modules conform to the 1988 version of ASN.1. This document updates
s well as previous versions of the protocol. NTPv4 includes a modified protocol those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-
header to accommodate the Internet Protocol version 6 address family. NTPv4 inc on-the-wire changes to any of the formats; this is simply a change to the syntax
ludes fundamental improvements in the mitigation and discipline algorithms that . This document is not an Internet Standards Track specification; it is publis
extend the potential accuracy to the tens of microseconds with modern workstatio hed for informational purposes.</t>
ns and fast LANs. It includes a dynamic server discovery scheme, so that in man </abstract>
y cases, specific server configuration is not required. It corrects certain err </front>
ors in the NTPv3 design and implementation and includes an optional extension me
chanism. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc591
2">
<front>
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.509
(PKIX)</title>
<seriesInfo name="DOI" value="10.17487/RFC5912"/>
<seriesInfo name="RFC" value="5912"/> <seriesInfo name="RFC" value="5912"/>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"> <seriesInfo name="DOI" value="10.17487/RFC5912"/>
<organization/> </reference>
</author> <reference anchor="RFC6120" target="https://www.rfc-editor.org/info/rfc6
<author initials="J." surname="Schaad" fullname="J. Schaad"> 120" quoteTitle="true" derivedAnchor="RFC6120">
<organization/> <front>
</author> <title>Extensible Messaging and Presence Protocol (XMPP): Core</titl
<date year="2010" month="June"/> e>
<abstract> <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
<t>The Public Key Infrastructure using X.509 (PKIX) certificate form ">
at, and many associated formats, are expressed using ASN.1. The current ASN.1 m <organization showOnFrontPage="true"/>
odules conform to the 1988 version of ASN.1. This document updates those ASN.1 </author>
modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire c <date year="2011" month="March"/>
hanges to any of the formats; this is simply a change to the syntax. This docum <abstract>
ent is not an Internet Standards Track specification; it is published for infor <t indent="0">The Extensible Messaging and Presence Protocol (XMPP
mational purposes.</t> ) is an application profile of the Extensible Markup Language (XML) that enables
</abstract> the near-real-time exchange of structured yet extensible data between any two o
</front> r more network entities. This document defines XMPP's core protocol methods: se
</reference> tup and teardown of XML streams, channel encryption, authentication, error handl
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc624 ing, and communication primitives for messaging, network availability ("presence
1"> "), and request-response interactions. This document obsoletes RFC 3920. [STAN
<front> DARDS-TRACK]</t>
<title>Network Configuration Protocol (NETCONF)</title> </abstract>
<seriesInfo name="DOI" value="10.17487/RFC6241"/> </front>
<seriesInfo name="RFC" value="6120"/>
<seriesInfo name="DOI" value="10.17487/RFC6120"/>
</reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
241" quoteTitle="true" derivedAnchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
lder" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="June"/>
<abstract>
<t indent="0">The Network Configuration Protocol (NETCONF) defined
in this document provides mechanisms to install, manipulate, and delete the con
figuration of network devices. It uses an Extensible Markup Language (XML)-base
d data encoding for the configuration data as well as the protocol messages. Th
e NETCONF protocol operations are realized as remote procedure calls (RPCs). Th
is document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6241"/> <seriesInfo name="RFC" value="6241"/>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor"> <seriesInfo name="DOI" value="10.17487/RFC6241"/>
<organization/> </reference>
</author> <reference anchor="RFC6335" target="https://www.rfc-editor.org/info/rfc6
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role 335" quoteTitle="true" derivedAnchor="RFC6335">
="editor"> <front>
<organization/> <title>Internet Assigned Numbers Authority (IANA) Procedures for the
</author> Management of the Service Name and Transport Protocol Port Number Registry</tit
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaeld le>
er" role="editor"> <author initials="M." surname="Cotton" fullname="M. Cotton">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="ed <author initials="L." surname="Eggert" fullname="L. Eggert">
itor"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <author initials="J." surname="Touch" fullname="J. Touch">
<date year="2011" month="June"/> <organization showOnFrontPage="true"/>
<abstract> </author>
<t>The Network Configuration Protocol (NETCONF) defined in this docu <author initials="M." surname="Westerlund" fullname="M. Westerlund">
ment provides mechanisms to install, manipulate, and delete the configuration of <organization showOnFrontPage="true"/>
network devices. It uses an Extensible Markup Language (XML)-based data encodi </author>
ng for the configuration data as well as the protocol messages. The NETCONF pro <author initials="S." surname="Cheshire" fullname="S. Cheshire">
tocol operations are realized as remote procedure calls (RPCs). This document o <organization showOnFrontPage="true"/>
bsoletes RFC 4741. [STANDARDS-TRACK]</t> </author>
</abstract> <date year="2011" month="August"/>
</front> <abstract>
</reference> <t indent="0">This document defines the procedures that the Intern
<reference anchor="RFC6335" target="https://www.rfc-editor.org/info/rfc633 et Assigned Numbers Authority (IANA) uses when handling assignment and other req
5"> uests related to the Service Name and Transport Protocol Port Number registry.
<front> It also discusses the rationale and principles behind these procedures and how t
<title>Internet Assigned Numbers Authority (IANA) Procedures for the M hey facilitate the long-term sustainability of the registry.</t>
anagement of the Service Name and Transport Protocol Port Number Registry</title <t indent="0">This document updates IANA's procedures by obsoletin
> g the previous UDP and TCP port assignment procedures defined in Sections 8 and
<seriesInfo name="DOI" value="10.17487/RFC6335"/> 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and
<seriesInfo name="RFC" value="6335"/> port assignment procedures for UDP-Lite, the Datagram Congestion Control Protoco
l (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates
the DNS SRV specification to clarify what a service name is and how it is regist
ered. This memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="165"/> <seriesInfo name="BCP" value="165"/>
<author initials="M." surname="Cotton" fullname="M. Cotton"> <seriesInfo name="RFC" value="6335"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC6335"/>
</author> </reference>
<author initials="L." surname="Eggert" fullname="L. Eggert"> <reference anchor="RFC6402" target="https://www.rfc-editor.org/info/rfc6
<organization/> 402" quoteTitle="true" derivedAnchor="RFC6402">
</author> <front>
<author initials="J." surname="Touch" fullname="J. Touch"> <title>Certificate Management over CMS (CMC) Updates</title>
<organization/> <author initials="J." surname="Schaad" fullname="J. Schaad">
</author> <organization showOnFrontPage="true"/>
<author initials="M." surname="Westerlund" fullname="M. Westerlund"> </author>
<organization/> <date year="2011" month="November"/>
</author> <abstract>
<author initials="S." surname="Cheshire" fullname="S. Cheshire"> <t indent="0">This document contains a set of updates to the base
<organization/> syntax for CMC, a Certificate Management protocol using the Cryptographic Messag
</author> e Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274.</t>
<date year="2011" month="August"/> <t indent="0">The new items in this document are: new controls for
<abstract> future work in doing server side key generation, definition of a Subject Inform
<t>This document defines the procedures that the Internet Assigned N ation Access value to identify CMC servers, and the registration of a port numbe
umbers Authority (IANA) uses when handling assignment and other requests related r for TCP/IP for the CMC service to run on. [STANDARDS-TRACK]</t>
to the Service Name and Transport Protocol Port Number registry. It also discu </abstract>
sses the rationale and principles behind these procedures and how they facilitat </front>
e the long-term sustainability of the registry.</t>
<t>This document updates IANA's procedures by obsoleting the previou
s UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IA
NA Allocation Guidelines, and it updates the IANA service name and port assignme
nt procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and
the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV s
pecification to clarify what a service name is and how it is registered. This m
emo documents an Internet Best Current Practice.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6402" target="https://www.rfc-editor.org/info/rfc640
2">
<front>
<title>Certificate Management over CMS (CMC) Updates</title>
<seriesInfo name="DOI" value="10.17487/RFC6402"/>
<seriesInfo name="RFC" value="6402"/> <seriesInfo name="RFC" value="6402"/>
<author initials="J." surname="Schaad" fullname="J. Schaad"> <seriesInfo name="DOI" value="10.17487/RFC6402"/>
<organization/> </reference>
</author> <reference anchor="RFC6407" target="https://www.rfc-editor.org/info/rfc6
<date year="2011" month="November"/> 407" quoteTitle="true" derivedAnchor="RFC6407">
<abstract> <front>
<t>This document contains a set of updates to the base syntax for CM <title>The Group Domain of Interpretation</title>
C, a Certificate Management protocol using the Cryptographic Message Syntax (CMS <author initials="B." surname="Weis" fullname="B. Weis">
). This document updates RFC 5272, RFC 5273, and RFC 5274.</t> <organization showOnFrontPage="true"/>
<t>The new items in this document are: new controls for future work </author>
in doing server side key generation, definition of a Subject Information Access <author initials="S." surname="Rowles" fullname="S. Rowles">
value to identify CMC servers, and the registration of a port number for TCP/IP <organization showOnFrontPage="true"/>
for the CMC service to run on. [STANDARDS-TRACK]</t> </author>
</abstract> <author initials="T." surname="Hardjono" fullname="T. Hardjono">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
<reference anchor="RFC6407" target="https://www.rfc-editor.org/info/rfc640 <date year="2011" month="October"/>
7"> <abstract>
<front> <t indent="0">This document describes the Group Domain of Interpre
<title>The Group Domain of Interpretation</title> tation (GDOI) protocol specified in RFC 3547. The GDOI provides group key manag
<seriesInfo name="DOI" value="10.17487/RFC6407"/> ement to support secure group communications according to the architecture speci
fied in RFC 4046. The GDOI manages group security associations, which are used
by IPsec and potentially other data security protocols. This document replaces
RFC 3547. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6407"/> <seriesInfo name="RFC" value="6407"/>
<author initials="B." surname="Weis" fullname="B. Weis"> <seriesInfo name="DOI" value="10.17487/RFC6407"/>
<organization/> </reference>
</author> <reference anchor="RFC6554" target="https://www.rfc-editor.org/info/rfc6
<author initials="S." surname="Rowles" fullname="S. Rowles"> 554" quoteTitle="true" derivedAnchor="RFC6554">
<organization/> <front>
</author> <title>An IPv6 Routing Header for Source Routes with the Routing Pro
<author initials="T." surname="Hardjono" fullname="T. Hardjono"> tocol for Low-Power and Lossy Networks (RPL)</title>
<organization/> <author initials="J." surname="Hui" fullname="J. Hui">
</author> <organization showOnFrontPage="true"/>
<date year="2011" month="October"/> </author>
<abstract> <author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<t>This document describes the Group Domain of Interpretation (GDOI) <organization showOnFrontPage="true"/>
protocol specified in RFC 3547. The GDOI provides group key management to supp </author>
ort secure group communications according to the architecture specified in RFC 4 <author initials="D." surname="Culler" fullname="D. Culler">
046. The GDOI manages group security associations, which are used by IPsec and <organization showOnFrontPage="true"/>
potentially other data security protocols. This document replaces RFC 3547. [ </author>
STANDARDS-TRACK]</t> <author initials="V." surname="Manral" fullname="V. Manral">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <date year="2012" month="March"/>
<reference anchor="RFC6554" target="https://www.rfc-editor.org/info/rfc655 <abstract>
4"> <t indent="0">In Low-Power and Lossy Networks (LLNs), memory const
<front> raints on routers may limit them to maintaining, at most, a few routes. In some
<title>An IPv6 Routing Header for Source Routes with the Routing Proto configurations, it is necessary to use these memory-constrained routers to deli
col for Low-Power and Lossy Networks (RPL)</title> ver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and L
<seriesInfo name="DOI" value="10.17487/RFC6554"/> ossy Networks (RPL) can be used in some deployments to store most, if not all, r
outes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and
forward the IPv6 datagram using a source routing technique to avoid large routin
g tables on memory-constrained routers. This document specifies a new IPv6 Rout
ing header type for delivering datagrams within a RPL routing domain. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6554"/> <seriesInfo name="RFC" value="6554"/>
<author initials="J." surname="Hui" fullname="J. Hui"> <seriesInfo name="DOI" value="10.17487/RFC6554"/>
<organization/> </reference>
</author> <reference anchor="RFC6724" target="https://www.rfc-editor.org/info/rfc6
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur"> 724" quoteTitle="true" derivedAnchor="RFC6724">
<organization/> <front>
</author> <title>Default Address Selection for Internet Protocol Version 6 (IP
<author initials="D." surname="Culler" fullname="D. Culler"> v6)</title>
<organization/> <author initials="D." surname="Thaler" fullname="D. Thaler" role="ed
</author> itor">
<author initials="V." surname="Manral" fullname="V. Manral"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <author initials="R." surname="Draves" fullname="R. Draves">
<date year="2012" month="March"/> <organization showOnFrontPage="true"/>
<abstract> </author>
<t>In Low-Power and Lossy Networks (LLNs), memory constraints on rou <author initials="A." surname="Matsumoto" fullname="A. Matsumoto">
ters may limit them to maintaining, at most, a few routes. In some configuratio <organization showOnFrontPage="true"/>
ns, it is necessary to use these memory-constrained routers to deliver datagrams </author>
to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks <author initials="T." surname="Chown" fullname="T. Chown">
(RPL) can be used in some deployments to store most, if not all, routes on one <organization showOnFrontPage="true"/>
(e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the I </author>
Pv6 datagram using a source routing technique to avoid large routing tables on m <date year="2012" month="September"/>
emory-constrained routers. This document specifies a new IPv6 Routing header ty <abstract>
pe for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]</t> <t indent="0">This document describes two algorithms, one for sour
</abstract> ce address selection and one for destination address selection. The algorithms
</front> specify default behavior for all Internet Protocol version 6 (IPv6) implementati
</reference> ons. They do not override choices made by applications or upper-layer protocols
<reference anchor="RFC6724" target="https://www.rfc-editor.org/info/rfc672 , nor do they preclude the development of more advanced mechanisms for address s
4"> election. The two algorithms share a common context, including an optional mech
<front> anism for allowing administrators to provide policy that can override the defaul
<title>Default Address Selection for Internet Protocol Version 6 (IPv6 t behavior. In dual-stack implementations, the destination address selection al
)</title> gorithm can consider both IPv4 and IPv6 addresses -- depending on the available
<seriesInfo name="DOI" value="10.17487/RFC6724"/> source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses,
or vice versa.</t>
<t indent="0">Default address selection as defined in this specifi
cation applies to all IPv6 nodes, including both hosts and routers. This docume
nt obsoletes RFC 3484. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6724"/> <seriesInfo name="RFC" value="6724"/>
<author initials="D." surname="Thaler" fullname="D. Thaler" role="edit <seriesInfo name="DOI" value="10.17487/RFC6724"/>
or"> </reference>
<organization/> <reference anchor="RFC6733" target="https://www.rfc-editor.org/info/rfc6
</author> 733" quoteTitle="true" derivedAnchor="RFC6733">
<author initials="R." surname="Draves" fullname="R. Draves"> <front>
<organization/> <title>Diameter Base Protocol</title>
</author> <author initials="V." surname="Fajardo" fullname="V. Fajardo" role="
<author initials="A." surname="Matsumoto" fullname="A. Matsumoto"> editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="T." surname="Chown" fullname="T. Chown"> <author initials="J." surname="Arkko" fullname="J. Arkko">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2012" month="September"/> <author initials="J." surname="Loughney" fullname="J. Loughney">
<abstract> <organization showOnFrontPage="true"/>
<t>This document describes two algorithms, one for source address se </author>
lection and one for destination address selection. The algorithms specify defau <author initials="G." surname="Zorn" fullname="G. Zorn" role="editor
lt behavior for all Internet Protocol version 6 (IPv6) implementations. They do ">
not override choices made by applications or upper-layer protocols, nor do they <organization showOnFrontPage="true"/>
preclude the development of more advanced mechanisms for address selection. Th </author>
e two algorithms share a common context, including an optional mechanism for all <date year="2012" month="October"/>
owing administrators to provide policy that can override the default behavior. <abstract>
In dual-stack implementations, the destination address selection algorithm can c <t indent="0">The Diameter base protocol is intended to provide an
onsider both IPv4 and IPv6 addresses -- depending on the available source addres Authentication, Authorization, and Accounting (AAA) framework for applications
ses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice vers such as network access or IP mobility in both local and roaming situations. Thi
a.</t> s document specifies the message format, transport, error reporting, accounting,
<t>Default address selection as defined in this specification applie and security services used by all Diameter applications. The Diameter base pro
s to all IPv6 nodes, including both hosts and routers. This document obsoletes tocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must b
RFC 3484. [STANDARDS-TRACK]</t> e supported by all new Diameter implementations. [STANDARDS-TRACK]</t>
</abstract> </abstract>
</front> </front>
</reference>
<reference anchor="RFC6733" target="https://www.rfc-editor.org/info/rfc673
3">
<front>
<title>Diameter Base Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC6733"/>
<seriesInfo name="RFC" value="6733"/> <seriesInfo name="RFC" value="6733"/>
<author initials="V." surname="Fajardo" fullname="V. Fajardo" role="ed <seriesInfo name="DOI" value="10.17487/RFC6733"/>
itor"> </reference>
<organization/> <reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6
</author> 762" quoteTitle="true" derivedAnchor="RFC6762">
<author initials="J." surname="Arkko" fullname="J. Arkko"> <front>
<organization/> <title>Multicast DNS</title>
</author> <author initials="S." surname="Cheshire" fullname="S. Cheshire">
<author initials="J." surname="Loughney" fullname="J. Loughney"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <author initials="M." surname="Krochmal" fullname="M. Krochmal">
<author initials="G." surname="Zorn" fullname="G. Zorn" role="editor"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <date year="2013" month="February"/>
<date year="2012" month="October"/> <abstract>
<abstract> <t indent="0">As networked devices become smaller, more portable,
<t>The Diameter base protocol is intended to provide an Authenticati and more ubiquitous, the ability to operate with less configured infrastructure
on, Authorization, and Accounting (AAA) framework for applications such as netwo is increasingly important. In particular, the ability to look up DNS resource r
rk access or IP mobility in both local and roaming situations. This document sp ecord data types (including, but not limited to, host names) in the absence of a
ecifies the message format, transport, error reporting, accounting, and security conventional managed DNS server is useful.</t>
services used by all Diameter applications. The Diameter base protocol as defi <t indent="0">Multicast DNS (mDNS) provides the ability to perform
ned in this document obsoletes RFC 3588 and RFC 5719, and it must be supported b DNS-like operations on the local link in the absence of any conventional Unicas
y all new Diameter implementations. [STANDARDS-TRACK]</t> t DNS server. In addition, Multicast DNS designates a portion of the DNS namesp
</abstract> ace to be free for local use, without the need to pay any annual fee, and withou
</front> t the need to set up delegations or otherwise configure a conventional DNS serve
</reference> r to answer for those names.</t>
<reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc676 <t indent="0">The primary benefits of Multicast DNS names are that
2"> (i) they require little or no administration or configuration to set them up, (
<front> ii) they work when no infrastructure is present, and (iii) they work during infr
<title>Multicast DNS</title> astructure failures.</t>
<seriesInfo name="DOI" value="10.17487/RFC6762"/> </abstract>
</front>
<seriesInfo name="RFC" value="6762"/> <seriesInfo name="RFC" value="6762"/>
<author initials="S." surname="Cheshire" fullname="S. Cheshire"> <seriesInfo name="DOI" value="10.17487/RFC6762"/>
<organization/> </reference>
</author> <reference anchor="RFC6763" target="https://www.rfc-editor.org/info/rfc6
<author initials="M." surname="Krochmal" fullname="M. Krochmal"> 763" quoteTitle="true" derivedAnchor="RFC6763">
<organization/> <front>
</author> <title>DNS-Based Service Discovery</title>
<date year="2013" month="February"/> <author initials="S." surname="Cheshire" fullname="S. Cheshire">
<abstract> <organization showOnFrontPage="true"/>
<t>As networked devices become smaller, more portable, and more ubiq </author>
uitous, the ability to operate with less configured infrastructure is increasing <author initials="M." surname="Krochmal" fullname="M. Krochmal">
ly important. In particular, the ability to look up DNS resource record data ty <organization showOnFrontPage="true"/>
pes (including, but not limited to, host names) in the absence of a conventional </author>
managed DNS server is useful.</t> <date year="2013" month="February"/>
<t>Multicast DNS (mDNS) provides the ability to perform DNS-like ope <abstract>
rations on the local link in the absence of any conventional Unicast DNS server. <t indent="0">This document specifies how DNS resource records are
In addition, Multicast DNS designates a portion of the DNS namespace to be fre named and structured to facilitate service discovery. Given a type of service
e for local use, without the need to pay any annual fee, and without the need to that a client is looking for, and a domain in which the client is looking for th
set up delegations or otherwise configure a conventional DNS server to answer f at service, this mechanism allows clients to discover a list of named instances
or those names.</t> of that desired service, using standard DNS queries. This mechanism is referred
<t>The primary benefits of Multicast DNS names are that (i) they req to as DNS-based Service Discovery, or DNS-SD.</t>
uire little or no administration or configuration to set them up, (ii) they work </abstract>
when no infrastructure is present, and (iii) they work during infrastructure fa </front>
ilures.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6763" target="https://www.rfc-editor.org/info/rfc676
3">
<front>
<title>DNS-Based Service Discovery</title>
<seriesInfo name="DOI" value="10.17487/RFC6763"/>
<seriesInfo name="RFC" value="6763"/> <seriesInfo name="RFC" value="6763"/>
<author initials="S." surname="Cheshire" fullname="S. Cheshire"> <seriesInfo name="DOI" value="10.17487/RFC6763"/>
<organization/> </reference>
</author> <reference anchor="RFC6824" target="https://www.rfc-editor.org/info/rfc6
<author initials="M." surname="Krochmal" fullname="M. Krochmal"> 824" quoteTitle="true" derivedAnchor="RFC6824">
<organization/> <front>
</author> <title>TCP Extensions for Multipath Operation with Multiple Addresse
<date year="2013" month="February"/> s</title>
<abstract> <author initials="A." surname="Ford" fullname="A. Ford">
<t>This document specifies how DNS resource records are named and st <organization showOnFrontPage="true"/>
ructured to facilitate service discovery. Given a type of service that a client </author>
is looking for, and a domain in which the client is looking for that service, t <author initials="C." surname="Raiciu" fullname="C. Raiciu">
his mechanism allows clients to discover a list of named instances of that desir <organization showOnFrontPage="true"/>
ed service, using standard DNS queries. This mechanism is referred to as DNS-bas </author>
ed Service Discovery, or DNS-SD.</t> <author initials="M." surname="Handley" fullname="M. Handley">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <author initials="O." surname="Bonaventure" fullname="O. Bonaventure
<reference anchor="RFC6824" target="https://www.rfc-editor.org/info/rfc682 ">
4"> <organization showOnFrontPage="true"/>
<front> </author>
<title>TCP Extensions for Multipath Operation with Multiple Addresses< <date year="2013" month="January"/>
/title> <abstract>
<seriesInfo name="DOI" value="10.17487/RFC6824"/> <t indent="0">TCP/IP communication is currently restricted to a si
ngle path per connection, yet multiple paths often exist between peers. The sim
ultaneous use of these multiple paths for a TCP/IP session would improve resourc
e usage within the network and, thus, improve user experience through higher thr
oughput and improved resilience to network failure.</t>
<t indent="0">Multipath TCP provides the ability to simultaneously
use multiple paths between peers. This document presents a set of extensions t
o traditional TCP to support multipath operation. The protocol offers the same
type of service to applications as TCP (i.e., reliable bytestream), and it provi
des the components necessary to establish and use multiple TCP flows across pote
ntially disjoint paths. This document defines an Experimental Protocol for the
Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6824"/> <seriesInfo name="RFC" value="6824"/>
<author initials="A." surname="Ford" fullname="A. Ford"> <seriesInfo name="DOI" value="10.17487/RFC6824"/>
<organization/> </reference>
</author> <reference anchor="RFC6830" target="https://www.rfc-editor.org/info/rfc6
<author initials="C." surname="Raiciu" fullname="C. Raiciu"> 830" quoteTitle="true" derivedAnchor="RFC6830">
<organization/> <front>
</author> <title>The Locator/ID Separation Protocol (LISP)</title>
<author initials="M." surname="Handley" fullname="M. Handley"> <author initials="D." surname="Farinacci" fullname="D. Farinacci">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="O." surname="Bonaventure" fullname="O. Bonaventure"> <author initials="V." surname="Fuller" fullname="V. Fuller">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2013" month="January"/> <author initials="D." surname="Meyer" fullname="D. Meyer">
<abstract> <organization showOnFrontPage="true"/>
<t>TCP/IP communication is currently restricted to a single path per </author>
connection, yet multiple paths often exist between peers. The simultaneous use <author initials="D." surname="Lewis" fullname="D. Lewis">
of these multiple paths for a TCP/IP session would improve resource usage withi <organization showOnFrontPage="true"/>
n the network and, thus, improve user experience through higher throughput and i </author>
mproved resilience to network failure.</t> <date year="2013" month="January"/>
<t>Multipath TCP provides the ability to simultaneously use multiple <abstract>
paths between peers. This document presents a set of extensions to traditional <t indent="0">This document describes a network-layer-based protoc
TCP to support multipath operation. The protocol offers the same type of servi ol that enables separation of IP addresses into two new numbering spaces: Endpoi
ce to applications as TCP (i.e., reliable bytestream), and it provides the compo nt Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to
nents necessary to establish and use multiple TCP flows across potentially disjo either host protocol stacks or to the "core" of the Internet infrastructure. Th
int paths. This document defines an Experimental Protocol for the Internet com e Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a
munity.</t> "flag day", and offers Traffic Engineering, multihoming, and mobility benefits
</abstract> to early adopters, even when there are relatively few LISP-capable sites.</t>
</front> <t indent="0">Design and development of LISP was largely motivated
</reference> by the problem statement produced by the October 2006 IAB Routing and Addressin
<reference anchor="RFC6830" target="https://www.rfc-editor.org/info/rfc683 g Workshop. This document defines an Experimental Protocol for the Internet com
0"> munity.</t>
<front> </abstract>
<title>The Locator/ID Separation Protocol (LISP)</title> </front>
<seriesInfo name="DOI" value="10.17487/RFC6830"/>
<seriesInfo name="RFC" value="6830"/> <seriesInfo name="RFC" value="6830"/>
<author initials="D." surname="Farinacci" fullname="D. Farinacci"> <seriesInfo name="DOI" value="10.17487/RFC6830"/>
<organization/> </reference>
</author> <reference anchor="RFC7011" target="https://www.rfc-editor.org/info/rfc7
<author initials="V." surname="Fuller" fullname="V. Fuller"> 011" quoteTitle="true" derivedAnchor="RFC7011">
<organization/> <front>
</author> <title>Specification of the IP Flow Information Export (IPFIX) Proto
<author initials="D." surname="Meyer" fullname="D. Meyer"> col for the Exchange of Flow Information</title>
<organization/> <author initials="B." surname="Claise" fullname="B. Claise" role="ed
</author> itor">
<author initials="D." surname="Lewis" fullname="D. Lewis"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <author initials="B." surname="Trammell" fullname="B. Trammell" role
<date year="2013" month="January"/> ="editor">
<abstract> <organization showOnFrontPage="true"/>
<t>This document describes a network-layer-based protocol that enabl </author>
es separation of IP addresses into two new numbering spaces: Endpoint Identifier <author initials="P." surname="Aitken" fullname="P. Aitken">
s (EIDs) and Routing Locators (RLOCs). No changes are required to either host p <organization showOnFrontPage="true"/>
rotocol stacks or to the "core" of the Internet infrastructure. The Locator/ID </author>
Separation Protocol (LISP) can be incrementally deployed, without a "flag day", <date year="2013" month="September"/>
and offers Traffic Engineering, multihoming, and mobility benefits to early adop <abstract>
ters, even when there are relatively few LISP-capable sites.</t> <t indent="0">This document specifies the IP Flow Information Expo
<t>Design and development of LISP was largely motivated by the probl rt (IPFIX) protocol, which serves as a means for transmitting Traffic Flow infor
em statement produced by the October 2006 IAB Routing and Addressing Workshop. mation over the network. In order to transmit Traffic Flow information from an
This document defines an Experimental Protocol for the Internet community.</t> Exporting Process to a Collecting Process, a common representation of flow data
</abstract> and a standard means of communicating them are required. This document describe
</front> s how the IPFIX Data and Template Records are carried over a number of transport
</reference> protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This
<reference anchor="RFC7011" target="https://www.rfc-editor.org/info/rfc701 document obsoletes RFC 5101.</t>
1"> </abstract>
<front> </front>
<title>Specification of the IP Flow Information Export (IPFIX) Protoco
l for the Exchange of Flow Information</title>
<seriesInfo name="DOI" value="10.17487/RFC7011"/>
<seriesInfo name="RFC" value="7011"/>
<seriesInfo name="STD" value="77"/> <seriesInfo name="STD" value="77"/>
<author initials="B." surname="Claise" fullname="B. Claise" role="edit <seriesInfo name="RFC" value="7011"/>
or"> <seriesInfo name="DOI" value="10.17487/RFC7011"/>
<organization/> </reference>
</author> <reference anchor="RFC7404" target="https://www.rfc-editor.org/info/rfc7
<author initials="B." surname="Trammell" fullname="B. Trammell" role=" 404" quoteTitle="true" derivedAnchor="RFC7404">
editor"> <front>
<organization/> <title>Using Only Link-Local Addressing inside an IPv6 Network</titl
</author> e>
<author initials="P." surname="Aitken" fullname="P. Aitken"> <author initials="M." surname="Behringer" fullname="M. Behringer">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2013" month="September"/> <author initials="E." surname="Vyncke" fullname="E. Vyncke">
<abstract> <organization showOnFrontPage="true"/>
<t>This document specifies the IP Flow Information Export (IPFIX) pr </author>
otocol, which serves as a means for transmitting Traffic Flow information over t <date year="2014" month="November"/>
he network. In order to transmit Traffic Flow information from an Exporting Pro <abstract>
cess to a Collecting Process, a common representation of flow data and a standar <t indent="0">In an IPv6 network, it is possible to use only link-
d means of communicating them are required. This document describes how the IPF local addresses on infrastructure links between routers. This document discusse
IX Data and Template Records are carried over a number of transport protocols fr s the advantages and disadvantages of this approach to facilitate the decision p
om an IPFIX Exporting Process to an IPFIX Collecting Process. This document obs rocess for a given network.</t>
oletes RFC 5101.</t> </abstract>
</abstract> </front>
</front>
</reference>
<reference anchor="RFC7404" target="https://www.rfc-editor.org/info/rfc740
4">
<front>
<title>Using Only Link-Local Addressing inside an IPv6 Network</title>
<seriesInfo name="DOI" value="10.17487/RFC7404"/>
<seriesInfo name="RFC" value="7404"/> <seriesInfo name="RFC" value="7404"/>
<author initials="M." surname="Behringer" fullname="M. Behringer"> <seriesInfo name="DOI" value="10.17487/RFC7404"/>
<organization/> </reference>
</author> <reference anchor="RFC7426" target="https://www.rfc-editor.org/info/rfc7
<author initials="E." surname="Vyncke" fullname="E. Vyncke"> 426" quoteTitle="true" derivedAnchor="RFC7426">
<organization/> <front>
</author> <title>Software-Defined Networking (SDN): Layers and Architecture Te
<date year="2014" month="November"/> rminology</title>
<abstract> <author initials="E." surname="Haleplidis" fullname="E. Haleplidis"
<t>In an IPv6 network, it is possible to use only link-local address role="editor">
es on infrastructure links between routers. This document discusses the advanta <organization showOnFrontPage="true"/>
ges and disadvantages of this approach to facilitate the decision process for a </author>
given network.</t> <author initials="K." surname="Pentikousis" fullname="K. Pentikousis
</abstract> " role="editor">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
<reference anchor="RFC7426" target="https://www.rfc-editor.org/info/rfc742 <author initials="S." surname="Denazis" fullname="S. Denazis">
6"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Software-Defined Networking (SDN): Layers and Architecture Term <author initials="J." surname="Hadi Salim" fullname="J. Hadi Salim">
inology</title> <organization showOnFrontPage="true"/>
<seriesInfo name="DOI" value="10.17487/RFC7426"/> </author>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization showOnFrontPage="true"/>
</author>
<author initials="O." surname="Koufopavlou" fullname="O. Koufopavlou
">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="January"/>
<abstract>
<t indent="0">Software-Defined Networking (SDN) refers to a new ap
proach for network programmability, that is, the capacity to initialize, control
, change, and manage network behavior dynamically via open interfaces. SDN emph
asizes the role of software in running networks through the introduction of an a
bstraction for the data forwarding plane and, by doing so, separates it from the
control plane. This separation allows faster innovation cycles at both planes
as experience has already shown. However, there is increasing confusion as to w
hat exactly SDN is, what the layer structure is in an SDN architecture, and how
layers interface with each other. This document, a product of the IRTF Software
-Defined Networking Research Group (SDNRG), addresses these questions and provid
es a concise reference for the SDN research community based on relevant peer-rev
iewed literature, the RFC series, and relevant documents by other standards orga
nizations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7426"/> <seriesInfo name="RFC" value="7426"/>
<author initials="E." surname="Haleplidis" fullname="E. Haleplidis" ro <seriesInfo name="DOI" value="10.17487/RFC7426"/>
le="editor"> </reference>
<organization/> <reference anchor="RFC7435" target="https://www.rfc-editor.org/info/rfc7
</author> 435" quoteTitle="true" derivedAnchor="RFC7435">
<author initials="K." surname="Pentikousis" fullname="K. Pentikousis"
role="editor">
<organization/>
</author>
<author initials="S." surname="Denazis" fullname="S. Denazis">
<organization/>
</author>
<author initials="J." surname="Hadi Salim" fullname="J. Hadi Salim">
<organization/>
</author>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization/>
</author>
<author initials="O." surname="Koufopavlou" fullname="O. Koufopavlou">
<organization/>
</author>
<date year="2015" month="January"/>
<abstract>
<t>Software-Defined Networking (SDN) refers to a new approach for ne
twork programmability, that is, the capacity to initialize, control, change, and
manage network behavior dynamically via open interfaces. SDN emphasizes the ro
le of software in running networks through the introduction of an abstraction fo
r the data forwarding plane and, by doing so, separates it from the control plan
e. This separation allows faster innovation cycles at both planes as experience
has already shown. However, there is increasing confusion as to what exactly S
DN is, what the layer structure is in an SDN architecture, and how layers interf
ace with each other. This document, a product of the IRTF Software-Defined Netw
orking Research Group (SDNRG), addresses these questions and provides a concise
reference for the SDN research community based on relevant peer-reviewed literat
ure, the RFC series, and relevant documents by other standards organizations.</t
>
</abstract>
</front>
</reference>
<reference anchor="RFC7435" target="https://www.rfc-editor.org/info/rfc7
435" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.74
35.xml">
<front> <front>
<title>Opportunistic Security: Some Protection Most of the Time</tit le> <title>Opportunistic Security: Some Protection Most of the Time</tit le>
<seriesInfo name="DOI" value="10.17487/RFC7435"/>
<seriesInfo name="RFC" value="7435"/>
<author initials="V." surname="Dukhovni" fullname="V. Dukhovni"> <author initials="V." surname="Dukhovni" fullname="V. Dukhovni">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2014" month="December"/> <date year="2014" month="December"/>
<abstract> <abstract>
<t>This document defines the concept "Opportunistic Security" in t he context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use auth entication when possible, thereby removing barriers to the widespread use of enc ryption on the Internet.</t> <t indent="0">This document defines the concept "Opportunistic Sec urity" in the context of communications protocols. Protocol designs based on Op portunistic Security use encryption even when authentication is not available, a nd use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="7435"/>
<seriesInfo name="DOI" value="10.17487/RFC7435"/>
</reference> </reference>
<reference anchor="RFC7575" target="https://www.rfc-editor.org/info/rfc757 <reference anchor="RFC7575" target="https://www.rfc-editor.org/info/rfc7
5"> 575" quoteTitle="true" derivedAnchor="RFC7575">
<front> <front>
<title>Autonomic Networking: Definitions and Design Goals</title> <title>Autonomic Networking: Definitions and Design Goals</title>
<seriesInfo name="DOI" value="10.17487/RFC7575"/> <author initials="M." surname="Behringer" fullname="M. Behringer">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Pritikin" fullname="M. Pritikin">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Bjarnason" fullname="S. Bjarnason">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Clemm" fullname="A. Clemm">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Jiang" fullname="S. Jiang">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Ciavaglia" fullname="L. Ciavaglia">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="June"/>
<abstract>
<t indent="0">Autonomic systems were first described in 2001. The
fundamental goal is self-management, including self-configuration, self-optimiz
ation, self-healing, and self-protection. This is achieved by an autonomic func
tion having minimal dependencies on human administrators or centralized manageme
nt systems. It usually implies distribution across network elements.</t>
<t indent="0">This document defines common language and outlines d
esign goals (and what are not design goals) for autonomic functions. A high-lev
el reference model illustrates how functional elements in an Autonomic Network i
nteract. This document is a product of the IRTF's Network Management Research G
roup.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7575"/> <seriesInfo name="RFC" value="7575"/>
<author initials="M." surname="Behringer" fullname="M. Behringer"> <seriesInfo name="DOI" value="10.17487/RFC7575"/>
<organization/> </reference>
</author> <reference anchor="RFC7576" target="https://www.rfc-editor.org/info/rfc7
<author initials="M." surname="Pritikin" fullname="M. Pritikin"> 576" quoteTitle="true" derivedAnchor="RFC7576">
<organization/> <front>
</author> <title>General Gap Analysis for Autonomic Networking</title>
<author initials="S." surname="Bjarnason" fullname="S. Bjarnason"> <author initials="S." surname="Jiang" fullname="S. Jiang">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="A." surname="Clemm" fullname="A. Clemm"> <author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter"> <author initials="M." surname="Behringer" fullname="M. Behringer">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="S." surname="Jiang" fullname="S. Jiang"> <date year="2015" month="June"/>
<organization/> <abstract>
</author> <t indent="0">This document provides a problem statement and gener
<author initials="L." surname="Ciavaglia" fullname="L. Ciavaglia"> al gap analysis for an IP-based Autonomic Network that is mainly based on distri
<organization/> buted network devices. The document provides background by reviewing the curren
</author> t status of autonomic aspects of IP networks and the extent to which current net
<date year="2015" month="June"/> work management depends on centralization and human administrators. Finally, th
<abstract> e document outlines the general features that are missing from current network a
<t>Autonomic systems were first described in 2001. The fundamental bilities and are needed in the ideal Autonomic Network concept.</t>
goal is self-management, including self-configuration, self-optimization, self-h <t indent="0">This document is a product of the IRTF's Network Man
ealing, and self-protection. This is achieved by an autonomic function having m agement Research Group.</t>
inimal dependencies on human administrators or centralized management systems. </abstract>
It usually implies distribution across network elements.</t> </front>
<t>This document defines common language and outlines design goals (
and what are not design goals) for autonomic functions. A high-level reference
model illustrates how functional elements in an Autonomic Network interact. Thi
s document is a product of the IRTF's Network Management Research Group.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7576" target="https://www.rfc-editor.org/info/rfc757
6">
<front>
<title>General Gap Analysis for Autonomic Networking</title>
<seriesInfo name="DOI" value="10.17487/RFC7576"/>
<seriesInfo name="RFC" value="7576"/> <seriesInfo name="RFC" value="7576"/>
<author initials="S." surname="Jiang" fullname="S. Jiang"> <seriesInfo name="DOI" value="10.17487/RFC7576"/>
<organization/> </reference>
</author> <reference anchor="RFC7585" target="https://www.rfc-editor.org/info/rfc7
<author initials="B." surname="Carpenter" fullname="B. Carpenter"> 585" quoteTitle="true" derivedAnchor="RFC7585">
<organization/> <front>
</author> <title>Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based o
<author initials="M." surname="Behringer" fullname="M. Behringer"> n the Network Access Identifier (NAI)</title>
<organization/> <author initials="S." surname="Winter" fullname="S. Winter">
</author> <organization showOnFrontPage="true"/>
<date year="2015" month="June"/> </author>
<abstract> <author initials="M." surname="McCauley" fullname="M. McCauley">
<t>This document provides a problem statement and general gap analys <organization showOnFrontPage="true"/>
is for an IP-based Autonomic Network that is mainly based on distributed network </author>
devices. The document provides background by reviewing the current status of a <date year="2015" month="October"/>
utonomic aspects of IP networks and the extent to which current network manageme <abstract>
nt depends on centralization and human administrators. Finally, the document ou <t indent="0">This document specifies a means to find authoritativ
tlines the general features that are missing from current network abilities and e RADIUS servers for a given realm. It is used in conjunction with either RADIU
are needed in the ideal Autonomic Network concept.</t> S over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport L
<t>This document is a product of the IRTF's Network Management Resea ayer Security (RADIUS/DTLS).</t>
rch Group.</t> </abstract>
</abstract> </front>
</front>
</reference>
<reference anchor="RFC7585" target="https://www.rfc-editor.org/info/rfc758
5">
<front>
<title>Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on
the Network Access Identifier (NAI)</title>
<seriesInfo name="DOI" value="10.17487/RFC7585"/>
<seriesInfo name="RFC" value="7585"/> <seriesInfo name="RFC" value="7585"/>
<author initials="S." surname="Winter" fullname="S. Winter"> <seriesInfo name="DOI" value="10.17487/RFC7585"/>
<organization/> </reference>
</author> <reference anchor="RFC7721" target="https://www.rfc-editor.org/info/rfc7
<author initials="M." surname="McCauley" fullname="M. McCauley"> 721" quoteTitle="true" derivedAnchor="RFC7721">
<organization/> <front>
</author> <title>Security and Privacy Considerations for IPv6 Address Generati
<date year="2015" month="October"/> on Mechanisms</title>
<abstract> <author initials="A." surname="Cooper" fullname="A. Cooper">
<t>This document specifies a means to find authoritative RADIUS serv <organization showOnFrontPage="true"/>
ers for a given realm. It is used in conjunction with either RADIUS over Transp </author>
ort Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security <author initials="F." surname="Gont" fullname="F. Gont">
(RADIUS/DTLS).</t> <organization showOnFrontPage="true"/>
</abstract> </author>
</front> <author initials="D." surname="Thaler" fullname="D. Thaler">
</reference> <organization showOnFrontPage="true"/>
<reference anchor="RFC7721" target="https://www.rfc-editor.org/info/rfc772 </author>
1"> <date year="2016" month="March"/>
<front> <abstract>
<title>Security and Privacy Considerations for IPv6 Address Generation <t indent="0">This document discusses privacy and security conside
Mechanisms</title> rations for several IPv6 address generation mechanisms, both standardized and no
<seriesInfo name="DOI" value="10.17487/RFC7721"/> n-standardized. It evaluates how different mechanisms mitigate different threat
s and the trade-offs that implementors, developers, and users face in choosing d
ifferent addresses or address generation mechanisms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7721"/> <seriesInfo name="RFC" value="7721"/>
<author initials="A." surname="Cooper" fullname="A. Cooper"> <seriesInfo name="DOI" value="10.17487/RFC7721"/>
<organization/> </reference>
</author> <reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc7
<author initials="F." surname="Gont" fullname="F. Gont"> 761" quoteTitle="true" derivedAnchor="RFC7761">
<organization/> <front>
</author> <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protoc
<author initials="D." surname="Thaler" fullname="D. Thaler"> ol Specification (Revised)</title>
<organization/> <author initials="B." surname="Fenner" fullname="B. Fenner">
</author> <organization showOnFrontPage="true"/>
<date year="2016" month="March"/> </author>
<abstract> <author initials="M." surname="Handley" fullname="M. Handley">
<t>This document discusses privacy and security considerations for s <organization showOnFrontPage="true"/>
everal IPv6 address generation mechanisms, both standardized and non-standardize </author>
d. It evaluates how different mechanisms mitigate different threats and the tra <author initials="H." surname="Holbrook" fullname="H. Holbrook">
de-offs that implementors, developers, and users face in choosing different addr <organization showOnFrontPage="true"/>
esses or address generation mechanisms.</t> </author>
</abstract> <author initials="I." surname="Kouvelas" fullname="I. Kouvelas">
</front> <organization showOnFrontPage="true"/>
</reference> </author>
<reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc776 <author initials="R." surname="Parekh" fullname="R. Parekh">
1"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol <author initials="Z." surname="Zhang" fullname="Z. Zhang">
Specification (Revised)</title> <organization showOnFrontPage="true"/>
<seriesInfo name="DOI" value="10.17487/RFC7761"/> </author>
<seriesInfo name="RFC" value="7761"/> <author initials="L." surname="Zheng" fullname="L. Zheng">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="March"/>
<abstract>
<t indent="0">This document specifies Protocol Independent Multica
st - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use
the underlying unicast routing information base or a separate multicast-capable
routing information base. It builds unidirectional shared trees rooted at a Ren
dezvous Point (RP) per group, and it optionally creates shortest-path trees per
source.</t>
<t indent="0">This document obsoletes RFC 4601 by replacing it, ad
dresses the errata filed against it, removes the optional (*,*,RP), PIM Multicas
t Border Router features and authentication using IPsec that lack sufficient dep
loyment experience (see Appendix A), and moves the PIM specification to Internet
Standard.</t>
</abstract>
</front>
<seriesInfo name="STD" value="83"/> <seriesInfo name="STD" value="83"/>
<author initials="B." surname="Fenner" fullname="B. Fenner"> <seriesInfo name="RFC" value="7761"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC7761"/>
</author> </reference>
<author initials="M." surname="Handley" fullname="M. Handley"> <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7
<organization/> 950" quoteTitle="true" derivedAnchor="RFC7950">
</author> <front>
<author initials="H." surname="Holbrook" fullname="H. Holbrook"> <title>The YANG 1.1 Data Modeling Language</title>
<organization/> <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
</author> le="editor">
<author initials="I." surname="Kouvelas" fullname="I. Kouvelas"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <date year="2016" month="August"/>
<author initials="R." surname="Parekh" fullname="R. Parekh"> <abstract>
<organization/> <t indent="0">YANG is a data modeling language used to model confi
</author> guration data, state data, Remote Procedure Calls, and notifications for network
<author initials="Z." surname="Zhang" fullname="Z. Zhang"> management protocols. This document describes the syntax and semantics of vers
<organization/> ion 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the
</author> YANG language, addressing ambiguities and defects in the original specification.
<author initials="L." surname="Zheng" fullname="L. Zheng"> There are a small number of backward incompatibilities from YANG version 1. T
<organization/> his document also specifies the YANG mappings to the Network Configuration Proto
</author> col (NETCONF).</t>
<date year="2016" month="March"/> </abstract>
<abstract> </front>
<t>This document specifies Protocol Independent Multicast - Sparse M
ode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlyin
g unicast routing information base or a separate multicast-capable routing infor
mation base. It builds unidirectional shared trees rooted at a Rendezvous Point
(RP) per group, and it optionally creates shortest-path trees per source.</t>
<t>This document obsoletes RFC 4601 by replacing it, addresses the e
rrata filed against it, removes the optional (*,*,RP), PIM Multicast Border Rout
er features and authentication using IPsec that lack sufficient deployment exper
ience (see Appendix A), and moves the PIM specification to Internet Standard.</t
>
</abstract>
</front>
</reference>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc795
0">
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
<seriesInfo name="RFC" value="7950"/> <seriesInfo name="RFC" value="7950"/>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role <seriesInfo name="DOI" value="10.17487/RFC7950"/>
="editor"> </reference>
<organization/> <reference anchor="RFC8028" target="https://www.rfc-editor.org/info/rfc8
</author> 028" quoteTitle="true" derivedAnchor="RFC8028">
<date year="2016" month="August"/> <front>
<abstract> <title>First-Hop Router Selection by Hosts in a Multi-Prefix Network
<t>YANG is a data modeling language used to model configuration data </title>
, state data, Remote Procedure Calls, and notifications for network management p <author initials="F." surname="Baker" fullname="F. Baker">
rotocols. This document describes the syntax and semantics of version 1.1 of th <organization showOnFrontPage="true"/>
e YANG language. YANG version 1.1 is a maintenance release of the YANG language </author>
, addressing ambiguities and defects in the original specification. There are a <author initials="B." surname="Carpenter" fullname="B. Carpenter">
small number of backward incompatibilities from YANG version 1. This document <organization showOnFrontPage="true"/>
also specifies the YANG mappings to the Network Configuration Protocol (NETCONF) </author>
.</t> <date year="2016" month="November"/>
</abstract> <abstract>
</front> <t indent="0">This document describes expected IPv6 host behavior
</reference> in a scenario that has more than one prefix, each allocated by an upstream netwo
<reference anchor="RFC8028" target="https://www.rfc-editor.org/info/rfc802 rk that is assumed to implement BCP 38 ingress filtering, when the host has mult
8"> iple routers to choose from. It also applies to other scenarios such as the usa
<front> ge of stateful firewalls that effectively act as address-based filters. Host be
<title>First-Hop Router Selection by Hosts in a Multi-Prefix Network</ havior in choosing a first-hop router may interact with source address selection
title> in a given implementation. However, the selection of the source address for a
<seriesInfo name="DOI" value="10.17487/RFC8028"/> packet is done before the first-hop router for that packet is chosen. Given that
the network or host is, or appears to be, multihomed with multiple provider-all
ocated addresses, that the host has elected to use a source address in a given p
refix, and that some but not all neighboring routers are advertising that prefix
in their Router Advertisement Prefix Information Options, this document specifi
es to which router a host should present its transmission. It updates RFC 4861.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8028"/> <seriesInfo name="RFC" value="8028"/>
<author initials="F." surname="Baker" fullname="F. Baker"> <seriesInfo name="DOI" value="10.17487/RFC8028"/>
<organization/> </reference>
</author> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
<author initials="B." surname="Carpenter" fullname="B. Carpenter"> 126" quoteTitle="true" derivedAnchor="RFC8126">
<organization/> <front>
</author> <title>Guidelines for Writing an IANA Considerations Section in RFCs
<date year="2016" month="November"/> </title>
<abstract> <author initials="M." surname="Cotton" fullname="M. Cotton">
<t>This document describes expected IPv6 host behavior in a scenario <organization showOnFrontPage="true"/>
that has more than one prefix, each allocated by an upstream network that is as </author>
sumed to implement BCP 38 ingress filtering, when the host has multiple routers <author initials="B." surname="Leiba" fullname="B. Leiba">
to choose from. It also applies to other scenarios such as the usage of statefu <organization showOnFrontPage="true"/>
l firewalls that effectively act as address-based filters. Host behavior in cho </author>
osing a first-hop router may interact with source address selection in a given i <author initials="T." surname="Narten" fullname="T. Narten">
mplementation. However, the selection of the source address for a packet is don <organization showOnFrontPage="true"/>
e before the first-hop router for that packet is chosen. Given that the network </author>
or host is, or appears to be, multihomed with multiple provider-allocated addres <date year="2017" month="June"/>
ses, that the host has elected to use a source address in a given prefix, and th <abstract>
at some but not all neighboring routers are advertising that prefix in their Rou <t indent="0">Many protocols make use of points of extensibility t
ter Advertisement Prefix Information Options, this document specifies to which r hat use constants to identify various protocol parameters. To ensure that the v
outer a host should present its transmission. It updates RFC 4861.</t> alues in these fields do not have conflicting uses and to promote interoperabili
</abstract> ty, their allocations are often coordinated by a central record keeper. For IET
</front> F protocols, that role is filled by the Internet Assigned Numbers Authority (IAN
</reference> A).</t>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc812 <t indent="0">To make assignments in a given registry prudently, g
6"> uidance describing the conditions under which new values should be assigned, as
<front> well as when and how modifications to existing values can be made, is needed. T
<title>Guidelines for Writing an IANA Considerations Section in RFCs</ his document defines a framework for the documentation of these guidelines by sp
title> ecification authors, in order to assure that the provided guidance for the IANA
<seriesInfo name="DOI" value="10.17487/RFC8126"/> Considerations is clear and addresses the various issues that are likely in the
<seriesInfo name="RFC" value="8126"/> 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="BCP" value="26"/>
<author initials="M." surname="Cotton" fullname="M. Cotton"> <seriesInfo name="RFC" value="8126"/>
<organization/> <seriesInfo name="DOI" value="10.17487/RFC8126"/>
</author> </reference>
<author initials="B." surname="Leiba" fullname="B. Leiba"> <reference anchor="RFC8316" target="https://www.rfc-editor.org/info/rfc8
<organization/> 316" quoteTitle="true" derivedAnchor="RFC8316">
</author> <front>
<author initials="T." surname="Narten" fullname="T. Narten"> <title>Autonomic Networking Use Case for Distributed Detection of Se
<organization/> rvice Level Agreement (SLA) Violations</title>
</author> <author initials="J." surname="Nobre" fullname="J. Nobre">
<date year="2017" month="June"/> <organization showOnFrontPage="true"/>
<abstract> </author>
<t>Many protocols make use of points of extensibility that use const <author initials="L." surname="Granville" fullname="L. Granville">
ants to identify various protocol parameters. To ensure that the values in thes <organization showOnFrontPage="true"/>
e fields do not have conflicting uses and to promote interoperability, their all </author>
ocations are often coordinated by a central record keeper. For IETF protocols, <author initials="A." surname="Clemm" fullname="A. Clemm">
that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <organization showOnFrontPage="true"/>
<t>To make assignments in a given registry prudently, guidance descr </author>
ibing the conditions under which new values should be assigned, as well as when <author initials="A." surname="Gonzalez Prieto" fullname="A. Gonzale
and how modifications to existing values can be made, is needed. This document z Prieto">
defines a framework for the documentation of these guidelines by specification a <organization showOnFrontPage="true"/>
uthors, in order to assure that the provided guidance for the IANA Consideration </author>
s is clear and addresses the various issues that are likely in the operation of <date year="2018" month="February"/>
a registry.</t> <abstract>
<t>This is the third edition of this document; it obsoletes RFC 5226 <t indent="0">This document describes an experimental use case tha
.</t> t employs autonomic networking for the monitoring of Service Level Agreements (S
</abstract> LAs). The use case is for detecting violations of SLAs in a distributed fashion
</front> . It strives to optimize and dynamically adapt the autonomic deployment of acti
</reference> ve measurement probes in a way that maximizes the likelihood of detecting servic
<reference anchor="RFC8366" target="https://www.rfc-editor.org/info/rfc836 e-level violations with a given resource budget to perform active measurements.
6"> This optimization and adaptation should be done without any outside guidance or
<front> intervention.</t>
<title>A Voucher Artifact for Bootstrapping Protocols</title> <t indent="0">This document is a product of the IRTF Network Manag
<seriesInfo name="DOI" value="10.17487/RFC8366"/> ement Research Group (NMRG). It is published for informational purposes.</t>
<seriesInfo name="RFC" value="8366"/> </abstract>
<author initials="K." surname="Watsen" fullname="K. Watsen"> </front>
<organization/>
</author>
<author initials="M." surname="Richardson" fullname="M. Richardson">
<organization/>
</author>
<author initials="M." surname="Pritikin" fullname="M. Pritikin">
<organization/>
</author>
<author initials="T." surname="Eckert" fullname="T. Eckert">
<organization/>
</author>
<date year="2018" month="May"/>
<abstract>
<t>This document defines a strategy to securely assign a pledge to a
n owner using an artifact signed, directly or indirectly, by the pledge's manufa
cturer. This artifact is known as a "voucher".</t>
<t>This document defines an artifact format as a YANG-defined JSON d
ocument that has been signed using a Cryptographic Message Syntax (CMS) structur
e. Other YANG-derived formats are possible. The voucher artifact is normally g
enerated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing
Authority (MASA).</t>
<t>This document only defines the voucher artifact, leaving it to ot
her documents to describe specialized protocols for accessing it.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8316" target="https://www.rfc-editor.org/info/rfc831
6">
<front>
<title>Autonomic Networking Use Case for Distributed Detection of Serv
ice Level Agreement (SLA) Violations</title>
<seriesInfo name="DOI" value="10.17487/RFC8316"/>
<seriesInfo name="RFC" value="8316"/> <seriesInfo name="RFC" value="8316"/>
<author initials="J." surname="Nobre" fullname="J. Nobre"> <seriesInfo name="DOI" value="10.17487/RFC8316"/>
<organization/> </reference>
</author> <reference anchor="RFC8366" target="https://www.rfc-editor.org/info/rfc8
<author initials="L." surname="Granville" fullname="L. Granville"> 366" quoteTitle="true" derivedAnchor="RFC8366">
<organization/> <front>
</author> <title>A Voucher Artifact for Bootstrapping Protocols</title>
<author initials="A." surname="Clemm" fullname="A. Clemm"> <author initials="K." surname="Watsen" fullname="K. Watsen">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="A." surname="Gonzalez Prieto" fullname="A. Gonzalez <author initials="M." surname="Richardson" fullname="M. Richardson">
Prieto"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <author initials="M." surname="Pritikin" fullname="M. Pritikin">
<date year="2018" month="February"/> <organization showOnFrontPage="true"/>
<abstract> </author>
<t>This document describes an experimental use case that employs aut <author initials="T." surname="Eckert" fullname="T. Eckert">
onomic networking for the monitoring of Service Level Agreements (SLAs). The us <organization showOnFrontPage="true"/>
e case is for detecting violations of SLAs in a distributed fashion. It strives </author>
to optimize and dynamically adapt the autonomic deployment of active measuremen <date year="2018" month="May"/>
t probes in a way that maximizes the likelihood of detecting service-level viola <abstract>
tions with a given resource budget to perform active measurements. This optimiz <t indent="0">This document defines a strategy to securely assign
ation and adaptation should be done without any outside guidance or intervention a pledge to an owner using an artifact signed, directly or indirectly, by the pl
.</t> edge's manufacturer. This artifact is known as a "voucher".</t>
<t>This document is a product of the IRTF Network Management Researc <t indent="0">This document defines an artifact format as a YANG-d
h Group (NMRG). It is published for informational purposes.</t> efined JSON document that has been signed using a Cryptographic Message Syntax (
</abstract> CMS) structure. Other YANG-derived formats are possible. The voucher artifact
</front> is normally generated by the pledge's manufacturer (i.e., the Manufacturer Autho
</reference> rized Signing Authority (MASA)).</t>
<reference anchor="RFC8368" target="https://www.rfc-editor.org/info/rfc836 <t indent="0">This document only defines the voucher artifact, lea
8"> ving it to other documents to describe specialized protocols for accessing it.</
<front> t>
<title>Using an Autonomic Control Plane for Stable Connectivity of Net </abstract>
work Operations, Administration, and Maintenance (OAM)</title> </front>
<seriesInfo name="DOI" value="10.17487/RFC8368"/> <seriesInfo name="RFC" value="8366"/>
<seriesInfo name="DOI" value="10.17487/RFC8366"/>
</reference>
<reference anchor="RFC8368" target="https://www.rfc-editor.org/info/rfc8
368" quoteTitle="true" derivedAnchor="RFC8368">
<front>
<title>Using an Autonomic Control Plane for Stable Connectivity of N
etwork Operations, Administration, and Maintenance (OAM)</title>
<author initials="T." surname="Eckert" fullname="T. Eckert" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Behringer" fullname="M. Behringer">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="May"/>
<abstract>
<t indent="0">Operations, Administration, and Maintenance (OAM), a
s per BCP 161, for data networks is often subject to the problem of circular dep
endencies when relying on connectivity provided by the network to be managed for
the OAM purposes.</t>
<t indent="0">Provisioning while bringing up devices and networks
tends to be more difficult to automate than service provisioning later on. Chan
ges in core network functions impacting reachability cannot be automated because
of ongoing connectivity requirements for the OAM equipment itself, and widely u
sed OAM protocols are not secure enough to be carried across the network without
security concerns.</t>
<t indent="0">This document describes how to integrate OAM process
es with an autonomic control plane in order to provide stable and secure connect
ivity for those OAM processes. This connectivity is not subject to the aforemen
tioned circular dependencies.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8368"/> <seriesInfo name="RFC" value="8368"/>
<author initials="T." surname="Eckert" fullname="T. Eckert" role="edit <seriesInfo name="DOI" value="10.17487/RFC8368"/>
or"> </reference>
<organization/> <reference anchor="RFC8398" target="https://www.rfc-editor.org/info/rfc8
</author> 398" quoteTitle="true" derivedAnchor="RFC8398">
<author initials="M." surname="Behringer" fullname="M. Behringer"> <front>
<organization/> <title>Internationalized Email Addresses in X.509 Certificates</titl
</author> e>
<date year="2018" month="May"/> <author initials="A." surname="Melnikov" fullname="A. Melnikov" role
<abstract> ="editor">
<t>Operations, Administration, and Maintenance (OAM), as per BCP 161 <organization showOnFrontPage="true"/>
, for data networks is often subject to the problem of circular dependencies whe </author>
n relying on connectivity provided by the network to be managed for the OAM purp <author initials="W." surname="Chuang" fullname="W. Chuang" role="ed
oses.</t> itor">
<t>Provisioning while bringing up devices and networks tends to be m <organization showOnFrontPage="true"/>
ore difficult to automate than service provisioning later on. Changes in core n </author>
etwork functions impacting reachability cannot be automated because of ongoing c <date year="2018" month="May"/>
onnectivity requirements for the OAM equipment itself, and widely used OAM proto <abstract>
cols are not secure enough to be carried across the network without security con <t indent="0">This document defines a new name form for inclusion
cerns.</t> in the otherName field of an X.509 Subject Alternative Name and Issuer Alternati
<t>This document describes how to integrate OAM processes with an au ve Name extension that allows a certificate subject to be associated with an int
tonomic control plane in order to provide stable and secure connectivity for tho ernationalized email address.</t>
se OAM processes. This connectivity is not subject to the aforementioned circul <t indent="0">This document updates RFC 5280.</t>
ar dependencies.</t> </abstract>
</abstract> </front>
</front>
</reference>
<reference anchor="RFC8398" target="https://www.rfc-editor.org/info/rfc839
8">
<front>
<title>Internationalized Email Addresses in X.509 Certificates</title>
<seriesInfo name="DOI" value="10.17487/RFC8398"/>
<seriesInfo name="RFC" value="8398"/> <seriesInfo name="RFC" value="8398"/>
<author initials="A." surname="Melnikov" fullname="A. Melnikov" role=" <seriesInfo name="DOI" value="10.17487/RFC8398"/>
editor"> </reference>
<organization/> <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8
</author> 402" quoteTitle="true" derivedAnchor="RFC8402">
<author initials="W." surname="Chuang" fullname="W. Chuang" role="edit <front>
or"> <title>Segment Routing Architecture</title>
<organization/> <author initials="C." surname="Filsfils" fullname="C. Filsfils" role
</author> ="editor">
<date year="2018" month="May"/> <organization showOnFrontPage="true"/>
<abstract> </author>
<t>This document defines a new name form for inclusion in the otherN <author initials="S." surname="Previdi" fullname="S. Previdi" role="
ame field of an X.509 Subject Alternative Name and Issuer Alternative Name exten editor">
sion that allows a certificate subject to be associated with an internationalize <organization showOnFrontPage="true"/>
d email address.</t> </author>
<t>This document updates RFC 5280.</t> <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
</abstract> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <author initials="B." surname="Decraene" fullname="B. Decraene">
<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc840 <organization showOnFrontPage="true"/>
2"> </author>
<front> <author initials="S." surname="Litkowski" fullname="S. Litkowski">
<title>Segment Routing Architecture</title> <organization showOnFrontPage="true"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/> </author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t indent="0">Segment Routing (SR) leverages the source routing pa
radigm. A node steers a packet through an ordered list of instructions, called
"segments". A segment can represent any instruction, topological or service bas
ed. A segment can have a semantic local to an SR node or global within an SR do
main. SR provides a mechanism that allows a flow to be restricted to a specific
topological path, while maintaining per-flow state only at the ingress node(s)
to the SR domain.</t>
<t indent="0">SR can be directly applied to the MPLS architecture
with no change to the forwarding plane. A segment is encoded as an MPLS label.
An ordered list of segments is encoded as a stack of labels. The segment to pr
ocess is on the top of the stack. Upon completion of a segment, the related lab
el is popped from the stack.</t>
<t indent="0">SR can be applied to the IPv6 architecture, with a n
ew type of routing header. A segment is encoded as an IPv6 address. An ordered
list of segments is encoded as an ordered list of IPv6 addresses in the routing
header. The active segment is indicated by the Destination Address (DA) of the
packet. The next active segment is indicated by a pointer in the new routing h
eader.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8402"/> <seriesInfo name="RFC" value="8402"/>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role=" <seriesInfo name="DOI" value="10.17487/RFC8402"/>
editor"> </reference>
<organization/> <reference anchor="RFC8572" target="https://www.rfc-editor.org/info/rfc8
</author> 572" quoteTitle="true" derivedAnchor="RFC8572">
<author initials="S." surname="Previdi" fullname="S. Previdi" role="ed <front>
itor"> <title>Secure Zero Touch Provisioning (SZTP)</title>
<organization/> <author initials="K." surname="Watsen" fullname="K. Watsen">
</author> <organization showOnFrontPage="true"/>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg"> </author>
<organization/> <author initials="I." surname="Farrer" fullname="I. Farrer">
</author> <organization showOnFrontPage="true"/>
<author initials="B." surname="Decraene" fullname="B. Decraene"> </author>
<organization/> <author initials="M." surname="Abrahamsson" fullname="M. Abrahamsson
</author> ">
<author initials="S." surname="Litkowski" fullname="S. Litkowski"> <organization showOnFrontPage="true"/>
<organization/> </author>
</author> <date year="2019" month="April"/>
<author initials="R." surname="Shakir" fullname="R. Shakir"> <abstract>
<organization/> <t indent="0">This document presents a technique to securely provi
</author> sion a networking device when it is booting in a factory-default state. Variati
<date year="2018" month="July"/> ons in the solution enable it to be used on both public and private networks. T
<abstract> he provisioning steps are able to update the boot image, commit an initial confi
<t>Segment Routing (SR) leverages the source routing paradigm. A no guration, and execute arbitrary scripts to address auxiliary needs. The updated
de steers a packet through an ordered list of instructions, called "segments". device is subsequently able to establish secure connections with other systems.
A segment can represent any instruction, topological or service based. A segmen For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8
t can have a semantic local to an SR node or global within an SR domain. SR pro 040) connections with deployment-specific network management systems.</t>
vides a mechanism that allows a flow to be restricted to a specific topological </abstract>
path, while maintaining per-flow state only at the ingress node(s) to the SR dom </front>
ain.</t>
<t>SR can be directly applied to the MPLS architecture with no chang
e to the forwarding plane. A segment is encoded as an MPLS label. An ordered l
ist of segments is encoded as a stack of labels. The segment to process is on t
he top of the stack. Upon completion of a segment, the related label is popped
from the stack.</t>
<t>SR can be applied to the IPv6 architecture, with a new type of ro
uting header. A segment is encoded as an IPv6 address. An ordered list of segm
ents is encoded as an ordered list of IPv6 addresses in the routing header. The
active segment is indicated by the Destination Address (DA) of the packet. The
next active segment is indicated by a pointer in the new routing header.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8572" target="https://www.rfc-editor.org/info/rfc857
2">
<front>
<title>Secure Zero Touch Provisioning (SZTP)</title>
<seriesInfo name="DOI" value="10.17487/RFC8572"/>
<seriesInfo name="RFC" value="8572"/> <seriesInfo name="RFC" value="8572"/>
<author initials="K." surname="Watsen" fullname="K. Watsen"> <seriesInfo name="DOI" value="10.17487/RFC8572"/>
<organization/> </reference>
</author> <reference anchor="RFC8684" target="https://www.rfc-editor.org/info/rfc8
<author initials="I." surname="Farrer" fullname="I. Farrer"> 684" quoteTitle="true" derivedAnchor="RFC8684">
<organization/>
</author>
<author initials="M." surname="Abrahamsson" fullname="M. Abrahamsson">
<organization/>
</author>
<date year="2019" month="April"/>
<abstract>
<t>This document presents a technique to securely provision a networ
king device when it is booting in a factory-default state. Variations in the so
lution enable it to be used on both public and private networks. The provisioni
ng steps are able to update the boot image, commit an initial configuration, and
execute arbitrary scripts to address auxiliary needs. The updated device is su
bsequently able to establish secure connections with other systems. For instanc
e, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connecti
ons with deployment-specific network management systems.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-anima-reference-model" target="http://www.ietf
.org/internet-drafts/draft-ietf-anima-reference-model-10.txt">
<front>
<title>A Reference Model for Autonomic Networking</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-reference-mo
del-10"/>
<author initials="M" surname="Behringer" fullname="Michael Behringer">
<organization/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization/>
</author>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/>
</author>
<author initials="L" surname="Ciavaglia" fullname="Laurent Ciavaglia">
<organization/>
</author>
<author initials="J" surname="Nobre" fullname="Jeferson Nobre">
<organization/>
</author>
<date month="November" day="22" year="2018"/>
<abstract>
<t>This document describes a reference model for Autonomic Networkin
g for managed networks. It defines the behaviour of an autonomic node, how the
various elements in an autonomic context work together, and how autonomic servic
es can use the infrastructure.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.eckert-anima-noc-autoconfig" target="http://www.iet
f.org/internet-drafts/draft-eckert-anima-noc-autoconfig-00.txt">
<front>
<title>Autoconfiguration of NOC services in ACP networks via GRASP</ti
tle>
<seriesInfo name="Internet-Draft" value="draft-eckert-anima-noc-autoco
nfig-00"/>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/>
</author>
<date month="July" day="2" year="2018"/>
<abstract>
<t>This document defines standards for the autoconfiguration of cruc
ial NOC services on ACP nodes via GRASP. It enables secure remote access to zer
o-touch bootstrapped ANI devices via SSH/NETCONF with RADIUS/Diameter authentica
tion and authorization and provides lifecycle autoconfiguration for other crucia
l services such as syslog, NTP (clock synchronization) and DNS for operational p
urposes.</t>
</abstract>
</front>
</reference>
<reference anchor="IEEE-1588-2008" target="http://standards.ieee.org/finds
tds/standard/1588-2008.html">
<front>
<title>
IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems
</title>
<author fullname="IEEE">
<organization>IEEE Standards Board</organization>
</author>
<date month="December" year="2008"/>
</front>
</reference>
<reference anchor="AR8021" target="http://standards.ieee.org/findstds/stan
dard/802.1AR-2009.html">
<front>
<title>
IEEE Standard for Local and metropolitan area networ
ks - Secure Device Identity
</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
<organization>IEEE SA-Standards Board</organization>
</author>
<date month="December" year="2009"/>
</front>
</reference>
<reference anchor="IEEE-802.1X" target="http://standards.ieee.org/findstds
/standard/802.1X-2010.html">
<front>
<title>
IEEE Standard for Local and Metropolitan Area Networ
ks: Port-Based Network Access Control
</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
<organization>IEEE SA-Standards Board</organization>
</author>
<date month="February" year="2010"/>
</front>
</reference>
<reference anchor="MACSEC" target="https://standards.ieee.org/findstds/sta
ndard/802.1AE-2006.html">
<front>
<title>
IEEE Standard for Local and Metropolitan Area Networ
ks: Media Access Control (MAC) Security
</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
<organization>IEEE SA-Standards Board</organization>
</author>
<date month="June" year="2006"/>
</front>
</reference>
<reference anchor="LLDP" target="https://standards.ieee.org/findstds/stand
ard/802.1AB-2016.html">
<front>
<title>
IEEE Standard for Local and Metropolitan Area Networ
ks: Station and Media Access Control Connectivity Discovery
</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
<organization>IEEE SA-Standards Board</organization>
</author>
<date month="June" year="2016"/>
</front>
</reference>
<reference anchor="CABFORUM" target="https://cabforum.org/baseline-require
ments-certificate-contents/">
<front>
<title>
Certificate Contents for Baseline SSL
</title>
<author>
<organization>CA/Browser Forum</organization>
</author>
<date month="Nov" year="2019"/>
</front>
</reference>
<reference anchor="X.509" target="https://www.itu.int/rec/T-REC-X.509">
<front>
<title>Information technology - Open Systems Interconnection - The Dir
ectory: Public-key and attribute certificate frameworks</title>
<seriesInfo name="ITU-T Recommendation X.509," value="ISO/IEC 9594-8"/
>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="October" year="2016"/>
</front>
</reference>
<reference anchor="X.520" target="https://www.itu.int/rec/T-REC-X.520">
<front>
<title>Information technology - Open Systems Interconnection - The Dir
ectory: Selected attribute types</title>
<seriesInfo name="ITU-T Recommendation X.520," value="ISO/IEC 9594-6"/
>
<author>
<organization>International Telecommunication Union</organization>
</author>
<date month="October" year="2016"/>
</front>
</reference>
<reference anchor="ACPDRAFT" target="https://tools.ietf.org/html/draft-
ietf-anima-autonomic-control-plane-30.pdf">
<front> <front>
<title>An Autonomic Control Plane (ACP)</title> <title>TCP Extensions for Multipath Operation with Multiple Addresse
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-autonomic- s</title>
control-plane-30"/> <author initials="A." surname="Ford" fullname="A. Ford">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Raiciu" fullname="C. Raiciu">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization showOnFrontPage="true"/>
</author>
<author initials="O." surname="Bonaventure" fullname="O. Bonaventure
">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Paasch" fullname="C. Paasch">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="March"/>
<abstract>
<t indent="0">TCP/IP communication is currently restricted to a si
ngle path per connection, yet multiple paths often exist between peers. The simu
ltaneous use of these multiple paths for a TCP/IP session would improve resource
usage within the network and thus improve user experience through higher throug
hput and improved resilience to network failure.</t>
<t indent="0">Multipath TCP provides the ability to simultaneously
use multiple paths between peers. This document presents a set of extensions to
traditional TCP to support multipath operation. The protocol offers the same ty
pe of service to applications as TCP (i.e., a reliable bytestream), and it provi
des the components necessary to establish and use multiple TCP flows across pote
ntially disjoint paths.</t>
<t indent="0">This document specifies v1 of Multipath TCP, obsolet
ing v0 as specified in RFC 6824, through clarifications and modifications primar
ily driven by deployment experience.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8684"/>
<seriesInfo name="DOI" value="10.17487/RFC8684"/>
</reference>
<reference anchor="RFC8739" target="https://www.rfc-editor.org/info/rfc8
739" quoteTitle="true" derivedAnchor="RFC8739">
<front>
<title>Support for Short-Term, Automatically Renewed (STAR) Certific
ates in the Automated Certificate Management Environment (ACME)</title>
<author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Lopez" fullname="D. Lopez">
<organization showOnFrontPage="true"/>
</author>
<author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzal
ez de Dios">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Pastor Perales" fullname="A. Pastor P
erales">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Fossati" fullname="T. Fossati">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="March"/>
<abstract>
<t indent="0">Public key certificates need to be revoked when they
are compromised, that is, when the associated private key is exposed to an unau
thorized entity. However, the revocation process is often unreliable. An altern
ative to revocation is issuing a sequence of certificates, each with a short val
idity period, and terminating the sequence upon compromise. This memo proposes
an Automated Certificate Management Environment (ACME) extension to enable the i
ssuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8739"/>
<seriesInfo name="DOI" value="10.17487/RFC8739"/>
</reference>
<reference anchor="RFC8981" target="https://www.rfc-editor.org/info/rfc8
981" quoteTitle="true" derivedAnchor="RFC8981">
<front>
<title>Temporary Address Extensions for Stateless Address Autoconfig
uration in IPv6</title>
<author initials="F." surname="Gont" fullname="F. Gont">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Krishnan" fullname="S. Krishnan">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Draves" fullname="R. Draves">
<organization showOnFrontPage="true"/>
</author>
<date year="2021" month="February"/>
<abstract>
<t indent="0">This document describes an extension to IPv6 Statele
ss Address Autoconfiguration that causes hosts to generate temporary addresses w
ith randomized interface identifiers for each prefix advertised with autoconfigu
ration enabled. Changing addresses over time limits the window of time during wh
ich eavesdroppers and other information collectors may trivially perform address
-based network-activity correlation when the same address is employed for multip
le transactions by the same host. Additionally, it reduces the window of exposur
e of a host as being accessible via an address that becomes revealed as a result
of active communication. This document obsoletes RFC 4941.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8981"/>
<seriesInfo name="DOI" value="10.17487/RFC8981"/>
</reference>
<reference anchor="RFC8992" target="https://www.rfc-editor.org/info/rfc8
992" quoteTitle="true" derivedAnchor="RFC8992">
<front>
<title>Autonomic IPv6 Edge Prefix Management in Large-Scale Networks
</title>
<author initials="S" surname="Jiang" fullname="Sheng Jiang" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="Z" surname="Du" fullname="Zongpeng Du">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization showOnFrontPage="true"/>
</author>
<author initials="Q" surname="Sun" fullname="Qiong Sun">
<organization showOnFrontPage="true"/>
</author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="8992"/>
<seriesInfo name="DOI" value="10.17487/RFC8992"/>
</reference>
<reference anchor="RFC8993" target="https://www.rfc-editor.org/info/rfc8
993" quoteTitle="true" derivedAnchor="RFC8993">
<front>
<title>A Reference Model for Autonomic Networking</title>
<author initials="M" surname="Behringer" fullname="Michael H. Behrin
ger" role="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization showOnFrontPage="true"/>
</author>
<author initials="T" surname="Eckert" fullname="Toerless Eckert"> <author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M" surname="Behringer" fullname="Michael Behringer <author initials="L" surname="Ciavaglia" fullname="Laurent Ciavaglia
"> ">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="S" surname="Bjarnason" fullname="Steinthor Bjarnas <author initials="J" surname="Nobre" fullname="Jéferson Campos Nobre
on"> ">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date month="May" year="2021"/>
</front>
<seriesInfo name="RFC" value="8993"/>
<seriesInfo name="DOI" value="10.17487/RFC8993"/>
</reference>
<reference anchor="I-D.ietf-roll-applicability-template" quoteTitle="tru
e" target="https://tools.ietf.org/html/draft-ietf-roll-applicability-template-09
" derivedAnchor="ROLL-APPLICABILITY">
<front>
<title>ROLL Applicability Statement Template</title>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization showOnFrontPage="true"/>
</author>
<date month="May" day="3" year="2016"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-roll-applicability
-template-09"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
roll-applicability-template-09.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="SR" target="https://en.wikipedia.org/w/index.php?titl
e=Single-root_input/output_virtualization&amp;oldid=978867619" quoteTitle="true"
derivedAnchor="SR">
<front>
<title>Single-root input/output virtualization</title>
<author>
<organization showOnFrontPage="true">Wikipedia</organization>
</author>
<date month="September" year="2020"/>
</front> </front>
<annotation>[RFC-Editor: Please remove this complete reference from th
e RFC] Refer to the IETF working group draft for the few sections removed from t
his document for various reasons. They capture the state of discussion about unr
esolved issues that may need to be revisited in future work.
</annotation>
</reference> </reference>
<reference anchor="I-D.ietf-tls-dtls13" quoteTitle="true" target="https:
//tools.ietf.org/html/draft-ietf-tls-dtls13-43" derivedAnchor="TLS-DTLS13">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="Eric Rescorla">
<organization showOnFrontPage="true">RTFM, Inc.</organization>
</author>
<author fullname="Hannes Tschofenig">
<organization showOnFrontPage="true">Arm Limited</organization>
</author>
<author fullname="Nagendra Modadugu">
<organization showOnFrontPage="true">Google, Inc.</organization>
</author>
<date month="April" day="30" year="2021"/>
<abstract>
<t indent="0"> This document specifies Version 1.3 of the Datagr
am Transport Layer
Security (DTLS) protocol. DTLS 1.3 allows client/server applications
to communicate over the Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery.
<reference anchor="FCC" target="https://docs.fcc.gov/public/attachments/DO The DTLS 1.3 protocol is intentionally based on the Transport Layer
C-367699A1.docx"> Security (TLS) 1.3 protocol and provides equivalent security
<front> guarantees with the exception of order protection/non-replayability.
<title>FCC STAFF REPORT ON NATIONWIDE T-MOBILE NETWORK OUTAGE ON JUNE Datagram semantics of the underlying transport are preserved by the
15, 2020 (PS Docket No. 20-183)</title> DTLS protocol.
<author>
<organization>FCC</organization>
</author>
<date year="2020" />
</front>
<annotation>The FCC's Public Safety and Homeland Security Bureau issues
a report on a nationwide T-Mobile outage that occurred on June 15, 2020. Action
by: Public Safety and Homeland Security Bureau.</annotation>
</reference>
<reference anchor="I-D.ietf-roll-applicability-template" target="http://ww This document obsoletes RFC 6347.
w.ietf.org/internet-drafts/draft-ietf-roll-applicability-template-09.txt">
<front> </t>
<title>ROLL Applicability Statement Template</title> </abstract>
<seriesInfo name="Internet-Draft" value="draft-ietf-roll-applicability </front>
-template-09"/> <seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-43"/>
<author initials="M" surname="Richardson" fullname="Michael Richardson <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-
"> tls-dtls13-43.txt"/>
<organization/> <refcontent>Work in Progress</refcontent>
</author> </reference>
<date month="May" day="3" year="2016"/> <reference anchor="X.509" target="https://www.itu.int/rec/T-REC-X.509" q
<abstract> uoteTitle="true" derivedAnchor="X.509">
<t>This document is a template applicability statement for the Routi <front>
ng over Low-power and Lossy Networks (ROLL) WG. This document is not for public <title>Information technology - Open Systems Interconnection - The D
ation, but rather is to be used as a template.</t> irectory: Public-key and attribute certificate frameworks</title>
</abstract> <seriesInfo name="ITU-T Recommendation" value="X.509"/>
</front> <author>
</reference> <organization showOnFrontPage="true">ITU-T</organization>
</author>
<date month="October" year="2016"/>
</front>
</reference>
<reference anchor="X.520" target="https://www.itu.int/rec/T-REC-X.520" q
uoteTitle="true" derivedAnchor="X.520">
<front>
<title>Information technology - Open Systems Interconnection - The D
irectory: Selected attribute types</title>
<seriesInfo name="ITU-T Recommendation" value="X.520"/>
<author>
<organization showOnFrontPage="true">ITU-T</organization>
</author>
<date month="October" year="2016"/>
</front>
</reference>
</references>
</references> </references>
<section anchor="further" numbered="true" toc="default"> <section anchor="further" numbered="true" toc="include" removeInRFC="false"
<name>Background and Futures (Informative)</name> pn="section-appendix.a">
<t>The following sections discuss additional background information about <name slugifiedName="name-background-and-future-infor">Background and Futu
aspects of the normative parts of this document or associated mechanisms such as re (Informative)</name>
BRSKI (such as why specific choices were made by the ACP) and they provide disc <t indent="0" pn="section-appendix.a-1">The following sections provide bac
ussion about possible future variations of the ACP.</t> kground information about aspects of the normative parts of this document or ass
<section anchor="address-spaces" numbered="true" toc="default"> ociated mechanisms such as BRSKI (such as why specific choices were made by the
<name>ACP Address Space Schemes</name> ACP), and they discuss possible future variations of the ACP.</t>
<t>This document defines the Zone, Vlong and Manual sub <section anchor="address-spaces" numbered="true" toc="include" removeInRFC
address schemes primarily to support address prefix assignment ="false" pn="section-a.1">
<name slugifiedName="name-acp-address-space-schemes">ACP Address Space S
chemes</name>
<t indent="0" pn="section-a.1-1">This document defines the Zone, Vlong,
and Manual Addressing Sub-Schemes primarily to support address prefix assignment
via distributed, potentially uncoordinated ACP registrars as defined via distributed, potentially uncoordinated ACP registrars as defined
in <xref target="acp-registrars" format="default"/>. This in <xref target="acp-registrars" format="default" sectionFormat="of" derivedCont
costs 48/46-bit identifier so that these ACP registrar can assign ent="Section 6.11.7"/>. This
non-conflicting address prefixes. This design does not leave enough costs a 48/46-bit identifier so that these ACP registrars can assign
bits to simultaneously support a large number of nodes (Node-ID) nonconflicting address prefixes. This design does not leave enough
plus a large prefix of local addresses for every node plus a bits to simultaneously support a large number of nodes (Node-ID),
large enough set of bits to identify a routing Zone. In result, plus a large prefix of local addresses for every node, plus a
Zone, Vlong 8/16 attempt to support all features, but via large enough set of bits to identify a routing zone. As a result,
the Zone and Vlong 8/16 Addressing Sub-Schemes attempt to support all features b
ut via
separate prefixes.</t> separate prefixes.</t>
<t>In networks that always expect to rely on a centralized PMS <t indent="0" pn="section-a.1-2">In networks that expect always to rely
as described above (<xref target="pms" format="default"/>), the 48/46-bits for on a centralized PMS
as described <xref target="pms" format="default" sectionFormat="of" derivedConte
nt="Section 9.2.5"/>, the 48/46-bits for
the Registrar-ID could be saved. Such variations of the ACP the Registrar-ID could be saved. Such variations of the ACP
addressing mechanisms could be introduced through future work addressing mechanisms could be introduced through future work
in different ways. If a new otherName was introduced, in different ways. If a new otherName was introduced,
incompatible ACP variations could be created incompatible ACP variations could be created
where every design aspect of the ACP could be changed. Including where every design aspect of the ACP could be changed, including
all addressing choices. If instead a new addressing sub-type all addressing choices. If instead a new addressing sub-scheme
would be defined, it could be a backward compatible extension would be defined, it could be a backward-compatible extension
of this ACP specification. Information such as the size of a of this ACP specification. Information such as the size of a
zone-prefix and the length of the prefix assigned to the ACP zone prefix and the length of the prefix assigned to the ACP
node itself could be encoded via the extension field of the node itself could be encoded via the extension field of the
acp-node-name.</t> acp-node-name.</t>
<t>Note that an explicitly defined "Manual" addressing sub-scheme <t indent="0" pn="section-a.1-3">Note that an explicitly defined Manual Addressing Sub-Scheme
is always beneficial to provide an easy way for ACP nodes to prohibit is always beneficial to provide an easy way for ACP nodes to prohibit
incorrect manual configuration of any non-"Manual" ACP address spaces incorrect non-autonomic configuration of any non-"Manual" ACP address spaces
and therefore ensure that "Manual" operations will never impact and therefore ensure that such non-autonomic operations will never impact
correct routing for any non-"Manual" ACP addresses assigned via correct routing for any non-"Manual" ACP addresses assigned via
ACP certificates.</t> ACP certificates.</t>
</section> </section>
<section anchor="bootstrap" numbered="true" toc="default"> <section anchor="bootstrap" numbered="true" toc="include" removeInRFC="fal
<name>BRSKI Bootstrap (ANI)</name> se" pn="section-a.2">
<t>BRSKI describes how nodes with an IDevID certificate can securely and <name slugifiedName="name-brski-bootstrap-ani">BRSKI Bootstrap (ANI)</na
zero-touch enroll with an LDevID certificate to support the ACP. BRSKI also le me>
verages the ACP to enable zero-touch bootstrap of new nodes across networks with <t indent="0" pn="section-a.2-1">BRSKI describes how nodes with an IDevI
out any configuration requirements across the transit nodes (e.g., no DHCP/DNS f D certificate can securely and zero-touch enroll with an LDevID certificate to s
orwarding/server setup). This includes otherwise not configured networks as des upport the ACP. BRSKI also leverages the ACP to enable zero-touch bootstrap of
cribed in <xref target="secure-bootstrap" format="default"/>. Therefore, BRSKI new nodes across networks without any configuration requirements across the tran
in conjunction with ACP provides for a secure and zero-touch management solution sit nodes (e.g., no DHCP, DNS forwarding, and/or server setup). This includes o
for complete networks. Nodes supporting such an infrastructure (BRSKI and ACP) therwise unconfigured networks as described in <xref target="secure-bootstrap" f
are called ANI nodes (Autonomic Networking Infrastructure), see <xref target="I ormat="default" sectionFormat="of" derivedContent="Section 3.2"/>. Therefore, B
-D.ietf-anima-reference-model" format="default"/>. Nodes that do not support an RSKI in conjunction with ACP provides for a secure and zero-touch management sol
IDevID certificate but only an (insecure) vendor specific Unique Device Identif ution for complete networks. Nodes supporting such an infrastructure (BRSKI and
ier (UDI) or nodes whose manufacturer does not support a MASA could use some fut ACP) are called ANI nodes (Autonomic Networking Infrastructure), see <xref targ
ure security reduced version of BRSKI.</t> et="RFC8993" format="default" sectionFormat="of" derivedContent="RFC8993"/>. No
<t>When BRSKI is used to provision a domain certificate (which is called des that do not support an IDevID certificate but only an (insecure) vendor-spec
enrollment), the BRSKI registrar (acting as an enhanced EST server) must includ ific Unique Device Identifier (UDI) or nodes whose manufacturer does not support
e the otherName / AcpNodeName encoded ACP address and domain name to the enrolli a MASA could use some future, reduced-security version of BRSKI.</t>
ng node (called pledge) via its response to the pledges EST CSR Attribute reques <t indent="0" pn="section-a.2-2">When BRSKI is used to provision a domai
t that is mandatory in BRSKI.</t> n certificate (which is called enrollment), the BRSKI registrar (acting as an en
<t>The Certification Authority in an ACP network must not change the oth hanced EST server) must include the otherName / AcpNodeName encoded ACP address
erName / AcpNodeName in the certificate. The ACP nodes can therefore find their and domain name to the enrolling node (called a pledge) via its response to the
ACP address and domain using this field in the domain certificate, both for the pledge's EST CSR Attributes Request that is mandatory in BRSKI.</t>
mselves, as well as for other nodes.</t> <t indent="0" pn="section-a.2-3">The CA in an ACP network must not chang
<t>The use of BRSKI in conjunction with the ACP can also help to further e the otherName / AcpNodeName in the certificate. The ACP nodes can therefore f
simplify maintenance and renewal of domain certificates. Instead of relying on ind their ACP addresses and domain using this field in the domain certificate, b
CRL, the lifetime of certificates can be made extremely small, for example in t oth for themselves as well as for other nodes.</t>
he order of hours. When a node fails to connect to the ACP within its certifica <t indent="0" pn="section-a.2-4">The use of BRSKI in conjunction with th
te lifetime, it cannot connect to the ACP to renew its certificate across it (us e ACP can also help to further simplify maintenance and renewal of domain certif
ing just EST), but it can still renew its certificate as an "enrolled/expired pl icates. Instead of relying on CRL, the lifetime of certificates can be made ext
edge" via the BRSKI bootstrap proxy. This requires only that the BRSKI registra remely small, for example, on the order of hours. When a node fails to connect
r honors expired domain certificates and that the pledge attempts to perform TLS to the ACP within its certificate lifetime, it cannot connect to the ACP to rene
authentication for BRSKI bootstrap using its expired domain certificate before w its certificate across it (using just EST), but it can still renew its certifi
falling back to attempting to use its IDevID certificate for BRSKI. This mechan cate as an "enrolled/expired pledge" via the BRSKI bootstrap proxy. This requir
ism could also render CRLs unnecessary because the BRSKI registrar in conjunctio es only that the BRSKI registrar honors expired domain certificates and that the
n with the CA would not renew revoked certificates - only a "Do-not-renew" list pledge attempts to perform TLS authentication for BRSKI bootstrap using its exp
would be necessary on BRSKI registrars/CA.</t> ired domain certificate before falling back to attempting to use its IDevID cert
<t>In the absence of BRSKI or less secure variants thereof, provisioning ificate for BRSKI. This mechanism could also render CRLs unnecessary because th
of certificates may involve one or more touches or non-standardized automation. e BRSKI registrar in conjunction with the CA would not renew revoked certificate
Node vendors usually support provisioning of certificates into nodes via PKCS# s -- only a "Do-not-renew" list would be necessary on the BRSKI registrar/CA.</t
7 (see <xref target="RFC2315" format="default"/>) and may support this provision >
ing through vendor specific models via NETCONF (<xref target="RFC6241" format="d <t indent="0" pn="section-a.2-5">In the absence of BRSKI or less secure
efault"/>). If such nodes also support NETCONF Zero-Touch (<xref target="RFC857 variants thereof, the provisioning of certificates may involve one or more touch
2" format="default"/>) then this can be combined to zero-touch provisioning of d es or nonstandardized automation. Node vendors usually support the provisioning
omain certificates into nodes. Unless there are equivalent integration of NETCO of certificates into nodes via PKCS #7 (see "<xref target="RFC2315" format="tit
NF connections across the ACP as there is in BRSKI, this combination would not s le" sectionFormat="of" derivedContent="PKCS #7: Cryptographic Message Syntax Ver
upport zero-touch bootstrap across a not configured network though.</t> sion 1.5"/>" <xref target="RFC2315" format="default" sectionFormat="of" derivedC
ontent="RFC2315"/>) and may support this provisioning through vendor-specific mo
dels via NETCONF ("<xref target="RFC6241" format="title" sectionFormat="of" deri
vedContent="Network Configuration Protocol (NETCONF)"/>" <xref target="RFC6241"
format="default" sectionFormat="of" derivedContent="RFC6241"/>). If such nodes
also support NETCONF Zero Touch <xref target="RFC8572" format="default" sectionF
ormat="of" derivedContent="RFC8572"/>, then this can be combined with zero-touch
provisioning of domain certificates into nodes. Unless there is the equivalent
integration of NETCONF connections across the ACP as there is in BRSKI, this co
mbination would not support zero-touch bootstrap across an unconfigured network,
though.</t>
</section> </section>
<section anchor="discovery" numbered="true" toc="default"> <section anchor="discovery" numbered="true" toc="include" removeInRFC="fal
<name>ACP Neighbor discovery protocol selection</name> se" pn="section-a.3">
<t>This section discusses why GRASP DULL was chosen as the discovery pro <name slugifiedName="name-acp-neighbor-discovery-prot">ACP Neighbor Disc
tocol overy Protocol Selection</name>
for L2 adjacent candidate ACP neighbors. The contenders considered where GRASP, <t indent="0" pn="section-a.3-1">This section discusses why GRASP DULL w
mDNS or LLDP.</t> as chosen as the discovery protocol
<section anchor="discovery-lldp" numbered="true" toc="default"> for L2-adjacent candidate ACP neighbors. The contenders that were considered we
<name>LLDP</name> re GRASP, mDNS, and LLDP.</t>
<t>LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example <section anchor="discovery-lldp" numbered="true" toc="include" removeInR
of L2 discovery protocols that terminate FC="false" pn="section-a.3.1">
their messages on L2 ports. If those protocols would be chosen for ACP neighbor <name slugifiedName="name-lldp">LLDP</name>
discovery, <t indent="0" pn="section-a.3.1-1">LLDP and Cisco's earlier Cisco Disc
ACP neighbor discovery would therefore also terminate on L2 ports. This would p overy Protocol (CDP) are examples of L2 discovery protocols that terminate
revent ACP construction their messages on L2 ports. If those protocols had been chosen for ACP neighbor
over non-ACP capable but LLDP or CDP enabled L2 switches. LLDP has extensions u discovery,
sing different MAC ACP neighbor discovery would also have terminated on L2 ports. This would have
addresses and this could have been an option for ACP discovery as well, but the prevented ACP construction
additional required over non-ACP-capable, but LLDP- or CDP-enabled L2 switches. LLDP has extensions
using different MAC
addresses, and this could have been an option for ACP discovery as well, but the
additional required
IEEE standardization and definition of a profile for such a modified instance of LLDP seemed to be IEEE standardization and definition of a profile for such a modified instance of LLDP seemed to be
more work than the benefit of "reusing the existing protocol" LLDP for this very simple purpose.</t> more work than the benefit of "reusing the existing protocol" LLDP for this very simple purpose.</t>
</section> </section>
<!-- discovery-lldp --> <section anchor="discovery-mdns" numbered="true" toc="include" removeInR
<section anchor="discovery-mdns" numbered="true" toc="default"> FC="false" pn="section-a.3.2">
<name>mDNS and L2 support</name> <name slugifiedName="name-mdns-and-l2-support">mDNS and L2 Support</na
<t>Multicast DNNS (mDNS) <xref target="RFC6762" format="default"/> wit me>
h DNS Service Discovery (DNS-SD) Resource Records (RRs) as defined in <xref targ <t indent="0" pn="section-a.3.2-1">Multicast DNS (mDNS) "<xref target=
et="RFC6763" format="default"/> "RFC6762" format="title" sectionFormat="of" derivedContent="Multicast DNS"/>" <x
is a key contender as an ACP discovery protocol. because it relies on link-local ref target="RFC6762" format="default" sectionFormat="of" derivedContent="RFC6762
IP multicast, "/> with DNS Service Discovery (DNS-SD) Resource Records (RRs) as defined in "<x
it does operates at the subnet level, and is also found in L2 switches. The aut ref target="RFC6763" format="title" sectionFormat="of" derivedContent="DNS-Based
hors Service Discovery"/>" <xref target="RFC6763" format="default" sectionFormat="of
of this document are not aware of mDNS implementation that terminate their mDNS " derivedContent="RFC6763"/>
messages was a key contender as an ACP discovery protocol. Because it relies on link-loca
on L2 ports instead of the subnet level. If mDNS was used as the ACP discovery l IP multicast,
mechanism on it operates at the subnet level and is also found in L2 switches. The authors
an ACP capable (L3)/L2 switch as outlined in <xref target="acp-l2-switches" form of this document are not aware of an mDNS implementation that terminates its mDN
at="default"/>, then this would S messages
on L2 ports instead of on the subnet level. If mDNS was used as the ACP discove
ry mechanism on
an ACP-capable (L3)/L2 switch as outlined in <xref target="acp-l2-switches" form
at="default" sectionFormat="of" derivedContent="Section 7"/>, then this would
be necessary to implement. It is likely that termination of mDNS messages could only be applied to be necessary to implement. It is likely that termination of mDNS messages could only be applied to
all mDNS messages from such a port, which would then make it necessary to softwa all mDNS messages from such a port, which would then make it necessary to softwa
re forward any non-ACP re forward any non-ACP-related
related mDNS messages to maintain prior non-ACP mDNS functionality. Adding sup mDNS messages to maintain prior non-ACP mDNS functionality. Adding support for
port for ACP into such ACP to such
L2 switches with mDNS could therefore create regression problems for prior mDNS functionality on those nodes. L2 switches with mDNS could therefore create regression problems for prior mDNS functionality on those nodes.
With low performance of software forwarding in many L2 switches, this could also make the ACP With low performance of software forwarding in many L2 switches, this could also make the ACP
risky to support on such L2 switches.</t> risky to support on such L2 switches.</t>
</section> </section>
<!-- discovery-mdns --> <section anchor="discovery-comparison" numbered="true" toc="include" rem
<section anchor="discovery-comparison" numbered="true" toc="default"> oveInRFC="false" pn="section-a.3.3">
<name>Why DULL GRASP</name> <name slugifiedName="name-why-dull-grasp">Why DULL GRASP?</name>
<t>LLDP was not considered because of the above mentioned issues. mDNS <t indent="0" pn="section-a.3.3-1">LLDP was not considered because of
was not selected the above mentioned issues. mDNS was not selected
because of the above L2 mDNS considerations and because of the following additio because of the above L2 mDNS considerations and because of the following additio
nal points:</t> nal points.</t>
<t>If mDNS was not already existing in a node, it would be more work t <t indent="0" pn="section-a.3.3-2">If mDNS was not already existing in
o implement than a node, it would be more work to implement than
DULL GRASP, and if an existing implementation of mDNS was used, it would likely be more code DULL GRASP, and if an existing implementation of mDNS was used, it would likely be more code
space than a separate implementation of DULL GRASP or a shared implementation of DULL space than a separate implementation of DULL GRASP or a shared implementation of DULL
GRASP and GRASP in the ACP.</t> GRASP and GRASP in the ACP.</t>
</section> </section>
<!-- discovery-comparison -->
</section> </section>
<!-- discovery--> <section anchor="why-rpl" numbered="true" toc="include" removeInRFC="false
<section anchor="why-rpl" numbered="true" toc="default"> " pn="section-a.4">
<name>Choice of routing protocol (RPL)</name> <name slugifiedName="name-choice-of-routing-protocol-">Choice of Routing
<t>This section motivates why RPL - "IPv6 Routing Protocol for Low-Power Protocol (RPL)</name>
and Lossy Networks (<xref target="RFC6550" format="default"/> was chosen as the <t indent="0" pn="section-a.4-1">This section motivates why RPL ("IPv6 R
default (and in this specification only) routing protocol for the ACP. The cho outing Protocol for Low-Power and Lossy Networks <xref target="RFC6550" format="
ice and above explained profile was derived from a pre-standard implementation o default" sectionFormat="of" derivedContent="RFC6550"/>) was chosen as the defaul
f ACP that was successfully deployed in operational networks.</t> t (and in this specification only) routing protocol for the ACP. The choice and
<t>Requirements for routing in the ACP are: above explained profile were derived from a pre-standard implementation of ACP
</t> that was successfully deployed in operational networks.</t>
<ul spacing="compact"> <t indent="0" pn="section-a.4-2">The requirements for routing in the ACP
<li>Self-management: The ACP must build automatically, without human i are the following:
ntervention. Therefore, routing protocol must also work completely automaticall </t>
y. RPL is a simple, self-managing protocol, which does not require zones or are <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-a
as; it is also self-configuring, since configuration is carried as part of the p .4-3">
rotocol (see Section 6.7.6 of <xref target="RFC6550" format="default"/>).</li> <li pn="section-a.4-3.1">Self-management: the ACP must build automatic
<li>Scale: The ACP builds over an entire domain, which could be a larg ally, without human
e enterprise or service provider network. The routing protocol must therefore s intervention. Therefore, the routing protocol must also work completel
upport domains of 100,000 nodes or more, ideally without the need for zoning or y
separation into areas. RPL has this scale property. This is based on extensive automatically. RPL is a simple, self-managing protocol, which does
use of default routing.</li> not require zones or areas; it is also self-configuring, since
<li>Low resource consumption: The ACP supports traditional network inf configuration is carried as part of the protocol (see <xref target="RFC
rastructure, thus runs in addition to traditional protocols. The ACP, and speci 6550" sectionFormat="of" section="6.7.6" format="default" derivedLink="https://r
fically the routing protocol must have low resource consumption both in terms of fc-editor.org/rfc/rfc6550#section-6.7.6" derivedContent="RFC6550"/>).</li>
memory and CPU requirements. Specifically, at edge nodes, where memory and CPU <li pn="section-a.4-3.2">Scale: the ACP builds over an entire domain,
are scarce, consumption should be minimal. RPL builds a DODAG, where the main which could be a large enterprise or service provider network. The routing prot
resource consumption is at the root of the DODAG. The closer to the edge of the ocol must therefore support domains of 100,000 nodes or more, ideally without th
network, the less state needs to be maintained. This adapts nicely to the typi e need for zoning or separation into areas. RPL has this scale property. This
cal network design. Also, all changes below a common parent node are kept below is based on extensive use of default routing.</li>
that parent node.</li> <li pn="section-a.4-3.3">Low resource consumption: the ACP supports tr
<li>Support for unstructured address space: In the Autonomic Networkin aditional network infrastructure, thus runs in addition to traditional protocols
g Infrastructure, node addresses are identifiers, and may not be assigned in a t . The ACP, and specifically the routing protocol, must have low resource consum
opological way. Also, nodes may move topologically, without changing their addr ption requirements, both in terms of memory and CPU. Specifically, at edge node
ess. Therefore, the routing protocol must support completely unstructured addre s, where memory and CPU are scarce, consumption should be minimal. RPL builds a
ss space. RPL is specifically made for mobile ad-hoc networks, with no assumpti DODAG, where the main resource consumption is at the root of the DODAG. The cl
ons on topologically aligned addressing.</li> oser to the edge of the network, the less state needs to be maintained. This ad
<li>Modularity: To keep the initial implementation small, yet allow la apts nicely to the typical network design. Also, all changes below a common par
ter for more complex methods, it is highly desirable that the routing protocol h ent node are kept below that parent node.</li>
as a simple base functionality, but can import new functional modules if needed. <li pn="section-a.4-3.4">Support for unstructured address space: in th
RPL has this property with the concept of "objective function", which is a plu e ANI, node addresses are identifiers, they and may not be assigned in a topolog
gin to modify routing behavior.</li> ical way. Also, nodes may move topologically, without changing their address.
<li>Extensibility: Since the Autonomic Networking Infrastructure is a Therefore, the routing protocol must support completely unstructured address spa
new concept, it is likely that changes in the way of operation will happen over ce. RPL is specifically made for mobile, ad hoc networks, with no assumptions o
time. RPL allows for new objective functions to be introduced later, which allo n topologically aligned addressing.</li>
w changes to the way the routing protocol creates the DAGs.</li> <li pn="section-a.4-3.5">Modularity: to keep the initial implementatio
<li>Multi-topology support: It may become necessary in the future to s n small, yet allow for more complex methods later, it is highly desirable that t
upport more than one DODAG for different purposes, using different objective fun he routing protocol has a simple base functionality, but can import new function
ctions. RPL allow for the creation of several parallel DODAGs, should this be r al modules if needed. RPL has this property with the concept of "Objective Func
equired. This could be used to create different topologies to reach different r tion", which is a plugin to modify routing behavior.</li>
oots.</li> <li anchor="extens" pn="section-a.4-3.6">Extensibility: since the ANI
<li>No need for path optimization: RPL does not necessarily compute th is a new concept, it is likely that changes to the way of operation will happen
e optimal path between any two nodes. However, the ACP does not require this to over time. RPL allows for new Objective Functions to be introduced later, which
day, since it carries mainly non-delay-sensitive feedback loops. It is possible allow changes to the way the routing protocol creates the DAGs.</li>
that different optimization schemes become necessary in the future, but RPL can <li pn="section-a.4-3.7">Multi-topology support: it may become necessa
be expanded (see point "Extensibility" above).</li> ry in the future to support more than one DODAG for different purposes, using di
fferent Objective Functions. RPL allow for the creation of several parallel DOD
AGs should this be required. This could be used to create different topologies
to reach different roots.</li>
<li pn="section-a.4-3.8">No need for path optimization: RPL does not n
ecessarily compute the optimal path between any two nodes. However, the ACP doe
s not require this today, since it carries mainly delay-insensitive feedback loo
ps. It is possible that different optimization schemes will become necessary in
the future, but RPL can be expanded (see <xref target="extens" format="none" se
ctionFormat="of" derivedContent="">"Extensibility"</xref> above).</li>
</ul> </ul>
</section> </section>
<section anchor="acp-grasp" numbered="true" toc="default"> <section anchor="acp-grasp" numbered="true" toc="include" removeInRFC="fal
<name>ACP Information Distribution and multicast</name> se" pn="section-a.5">
<t>IP multicast is not used by the ACP because the ANI (Autonomic Networ <name slugifiedName="name-acp-information-distributio">ACP Information D
king Infrastructure) itself does not require IP multicast istribution and Multicast</name>
<t indent="0" pn="section-a.5-1">IP multicast is not used by the ACP bec
ause the ANI itself does not require IP multicast
but only service announcement/discovery. Using IP multicast for that wo uld have made it but only service announcement/discovery. Using IP multicast for that wo uld have made it
necessary to develop a zero-touch auto configuring solution for ASM (Any Source Multicast - the original form of IP multicast defined in <xref target="R FC1112" format="default"/>), which necessary to develop a zero-touch autoconfiguring solution for ASM (Any Source Multicast - the original form of IP multicast defined in "<xref target="R FC1112" format="title" sectionFormat="of" derivedContent="Host extensions for IP multicasting"/>" <xref target="RFC1112" format="default" sectionFormat="of" der ivedContent="RFC1112"/>), which
would be quite complex and difficult to justify. One aspect of complexi ty would be quite complex and difficult to justify. One aspect of complexi ty
where no attempt at a solution has been described where no attempt at a solution has been described
in IETF documents is the automatic-selection of in IETF documents is the automatic selection of
routers that should be PIM Sparse Mode (PIM-SM) Rendezvous Points (RPs) routers that should be PIM Sparse Mode (PIM-SM) Rendezvous Points (RPs)
(see <xref target="RFC7761" format="default"/>). The other aspects of complexit (see "<xref target="RFC7761" format="title" sectionFormat="of" derivedContent="P
y rotocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Re
are the implementation of MLD (<xref target="RFC4604" format="default"/> vised)"/>" <xref target="RFC7761" format="default" sectionFormat="of" derivedCon
), PIM-SM and Anycast-RP (see <xref target="RFC4610" format="default"/>). If th tent="RFC7761"/>). The other aspects of complexity
ose implementations already are the implementation of MLD ("<xref target="RFC4604" format="title" se
exist in a product, then they would be very likely tied to accelerated f ctionFormat="of" derivedContent="Using Internet Group Management Protocol Versio
orwarding n 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Sou
which consumes hardware resources, and that in return is difficult to ju rce-Specific Multicast"/>" <xref target="RFC4604" format="default" sectionFormat
stify as a cost ="of" derivedContent="RFC4604"/>), PIM-SM, and Anycast-RP (see "<xref target="RF
C4610" format="title" sectionFormat="of" derivedContent="Anycast-RP Using Protoc
ol Independent Multicast (PIM)"/>" <xref target="RFC4610" format="default" secti
onFormat="of" derivedContent="RFC4610"/>). If those implementations already
exist in a product, then they would be very likely tied to accelerated f
orwarding,
which consumes hardware resources, and that in turn is difficult to just
ify as a cost
of performing only service discovery.</t> of performing only service discovery.</t>
<t>Some future ASA may need high performance in-network data replication . That is the case <t indent="0" pn="section-a.5-2">Some future ASA may need high-performan ce, in-network data replication. That is the case
when the use of IP multicast is justified. Such an ASA can then use ser vice discovery when the use of IP multicast is justified. Such an ASA can then use ser vice discovery
from ACP GRASP, and then they do not need ASM but only SSM (Source Speci from ACP GRASP, and then they do not need ASM but only SSM (see "<xref t
fic Multicast, see <xref target="RFC4607" format="default"/>) arget="RFC4607" format="title" sectionFormat="of" derivedContent="Source-Specifi
for the IP multicast replication. SSM itself can simply be enabled in t c Multicast for IP"/>" <xref target="RFC4607" format="default" sectionFormat="of
he Data-Plane " derivedContent="RFC4607"/>)
(or even in an update to the ACP) without any other configuration than j for the IP multicast replication. SSM itself can simply be enabled in t
ust enabling it he data plane
on all nodes and only requires a simpler version of MLD (see <xref targe (or even in an update to the ACP) without any configuration other than j
t="RFC5790" format="default"/>).</t> ust enabling it
<t>LSP (Link State Protocol) based IGP routing protocols typically have on all nodes, and it only requires a simpler version of MLD (see "<xref
a mechanism to target="RFC5790" format="title" sectionFormat="of" derivedContent="Lightweight I
nternet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Disc
overy Version 2 (MLDv2) Protocols"/>" <xref target="RFC5790" format="default" se
ctionFormat="of" derivedContent="RFC5790"/>).</t>
<t indent="0" pn="section-a.5-3">IGP routing protocols based on LSP (Lin
k State Protocol) typically have a mechanism to
flood information, and such a mechanism could be used to flood GRASP obj ectives by flood information, and such a mechanism could be used to flood GRASP obj ectives by
defining them to be information of that IGP. This would be a possible o ptimization defining them to be information of that IGP. This would be a possible o ptimization
in future variations of the ACP that do use an LSP routing protocol. No in future variations of the ACP that do use an LSP-based routing protoco
te though that l. Note though that
such a mechanism would not work easily for GRASP M_DISCOVERY messages wh such a mechanism would not work easily for GRASP M_DISCOVERY messages, w
ich are intelligently hich are intelligently
(constrained) flooded not across the whole ACP, but only up to a node wh ere a responder is found. (constrained) flooded not across the whole ACP, but only up to a node wh ere a responder is found.
We do expect that many future services in ASA will have only few consumi We expect that many future services in the ASA will have only a few cons
ng ASA, and for those cases, uming ASAs, and for those cases,
M_DISCOVERY is the more efficient method than flooding across the whole the M_DISCOVERY method is more efficient than flooding across the whole
domain.</t> domain.</t>
<t>Because the ACP uses RPL, one desirable future extension is to use RP <t indent="0" pn="section-a.5-4">Because the ACP uses RPL, one desirable
Ls existing future extension is to use RPL's existing
notion of DODAG, which are loop-free distribution trees, to make GRASP f looding more efficient notion of DODAG, which are loop-free distribution trees, to make GRASP f looding more efficient
both for M_FLOOD and M_DISCOVERY. See <xref target="ACP_interfaces" form at="default"/> how this will be both for M_FLOOD and M_DISCOVERY. See <xref target="ACP_interfaces" form at="default" sectionFormat="of" derivedContent="Section 6.13.5"/> for how this w ill be
specifically beneficial when using NBMA interfaces. This specifically beneficial when using NBMA interfaces. This
is not currently specified in this document because it is not quite clea r yet what is not currently specified in this document because it is not quite clea r yet what
exactly the implications are to make GRASP flooding depend on RPL DODAG convergence exactly the implications are to make GRASP flooding depend on RPL DODAG convergence
and how difficult it would be to let GRASP flooding access the DODAG inf ormation.</t> and how difficult it would be to let GRASP flooding access the DODAG inf ormation.</t>
</section> </section>
<section anchor="domain-usage" numbered="true" toc="include" removeInRFC="
<section anchor="domain-usage" numbered="true" toc="default"> false" pn="section-a.6">
<name>CAs, domains and routing subdomains</name> <name slugifiedName="name-cas-domains-and-routing-sub">CAs, Domains, and
<t>There is a wide range of setting up different ACP solution by appropr Routing Subdomains</name>
iately using CAs and the domain and rsub elements in the acp-node-name in the do <t indent="0" pn="section-a.6-1">There is a wide range of setting up dif
main certificate. We summarize these options here as they have been explained i ferent ACP solutions by appropriately using CAs and the domain and rsub elements
n different parts of the document in before and discuss possible and desirable e in the acp-node-name in the domain certificate. We summarize these options her
xtensions:</t> e as they have been explained in different parts of the document and discuss pos
<t>An ACP domain is the set of all ACP nodes that can authenticate each sible and desirable extensions.</t>
other as belonging to the same ACP network using the ACP domain membership check <t indent="0" pn="section-a.6-2">An ACP domain is the set of all ACP nod
(<xref target="certcheck" format="default"/>). GRASP inside the ACP is run acr es that can authenticate each other as belonging to the same ACP network using t
oss all transitively connected ACP nodes in a domain.</t> he ACP domain membership check (<xref target="certcheck" format="default" sectio
<t>The rsub element in the acp-node-name permits the use of addresses fr nFormat="of" derivedContent="Section 6.2.3"/>). GRASP inside the ACP is run acr
om different ULA prefixes. One use case is to create multiple physical networks oss all transitively connected ACP nodes in a domain.</t>
that initially may be separated with one ACP domain but different routing subdo <t indent="0" pn="section-a.6-3">The rsub element in the acp-node-name p
mains, so that all nodes can mutual trust their ACP certificates (not depending ermits the use of addresses from different ULA prefixes. One use case is the cr
on rsub) and so that they could connect later together into a contiguous ACP net eation of multiple physical networks that initially may be separated with one AC
work.</t> P domain but different routing subdomains, so that all nodes can mutually trust
<t>One instance of such a use case is an ACP for regions interconnected their ACP certificates (not depending on rsub) and so that they could connect la
via a non-ACP enabled core, for example due to the absence of product support fo ter together into a contiguous ACP network.</t>
r ACP on the core nodes. ACP connect configurations as defined in this document <t indent="0" pn="section-a.6-4">One instance of such a use case is an A
can be used to extend and interconnect those ACP islands to the NOC and merge th CP for regions interconnected via a non-ACP enabled core, for example, due to th
em into a single ACP when later that product support gap is closed.</t> e absence of product support for ACP on the core nodes. ACP connect configuratio
<t>Note that RPL scales very well. It is not necessary to use multiple ns as defined in this document can be used to extend and interconnect those ACP
routing subdomains to scale ACP domains in a way that would be required if other islands to the NOC and merge them into a single ACP when later that product supp
routing protocols where used. They exist only as options for the above mention ort gap is closed.</t>
ed reasons.</t> <t indent="0" pn="section-a.6-5">Note that RPL scales very well. It is
<t>If different ACP domains are to be created that should not allow to c not necessary to use multiple routing subdomains to scale ACP domains in a way t
onnect to each other by default, these ACP domains simply need to have different hat would be required if other routing protocols where used. They exist only as
domain elements in the acp-node-name. These domain elements can be arbitrary, options for the above mentioned reasons.</t>
including subdomains of one another: Domains "example.com" and "research.example <t indent="0" pn="section-a.6-6"> If ACP domains need to be created that
.com" are separate domains if both are domain elements in the acp-node-name of c are not allowed to connect to each other by default, simply use different domai
ertificates.</t> n elements in the acp-node-name. These domain elements can be arbitrary, includ
<t>It is not necessary to have a separate CA for different ACP domains: ing subdomains of one another: domains "example.com" and "research.example.com"
an operator can use a single CA to sign certificates for multiple ACP domains th are separate domains if both are domain elements in the acp-node-name of certifi
at are not allowed to connect to each other because the checks for ACP adjacenci cates.</t>
es includes comparison of the domain part.</t> <t indent="0" pn="section-a.6-7">It is not necessary to have a separate
<t>If multiple independent networks choose the same domain name but had CA for different ACP domains: an operator can use a single CA to sign certificat
their own CA, these would not form a single ACP domain because of CA mismatch. es for multiple ACP domains that are not allowed to connect to each other becaus
Therefore, there is no problem in choosing domain names that are potentially als e the checks for ACP adjacencies include the comparison of the domain part.</t>
o used by others. Nevertheless it is highly recommended to use domain names tha <t indent="0" pn="section-a.6-8">If multiple, independent networks chose
t one can have high probability to be unique. It is recommended to use domain n the same domain name but had their own CAs, these would not form a single ACP d
ames that start with a DNS domain names owned by the assigning organization and omain because of CA mismatch. Therefore, there is no problem in choosing domain
unique within it. For example, "acp.example.com" if you own "example.com".</t> names that are potentially also used by others. Nevertheless, it is highly rec
ommended to use domain names that have a high probability of being unique. It i
s recommended to use domain names that start with a DNS domain name owned by the
assigning organization and unique within it, for example, "acp.example.com" if
you own "example.com".</t>
</section> </section>
<section anchor="intent" numbered="true" toc="default"> <section anchor="intent" numbered="true" toc="include" removeInRFC="false"
<name>Intent for the ACP</name> pn="section-a.7">
<t>Intent is the architecture component of autonomic networks according <name slugifiedName="name-intent-for-the-acp">Intent for the ACP</name>
to <t indent="0" pn="section-a.7-1">Intent is the architecture component of
<xref target="I-D.ietf-anima-reference-model" format="default"/> that allows op Autonomic Networks according to
erators to issue policies to <xref target="RFC8993" format="default" sectionFormat="of" derivedContent="RFC8
993"/> that allows operators to issue policies to
the network. Its applicability for use is quite flexible and freeform, with po tential applications including the network. Its applicability for use is quite flexible and freeform, with po tential applications including
policies flooded across ACP GRASP and interpreted on every ACP node.</t> policies flooded across ACP GRASP and interpreted on every ACP node.</t>
<t>One concern for future definitions of Intent solutions is the problem of circular dependencies <t indent="0" pn="section-a.7-2">One concern for future definitions of I ntent solutions is the problem of circular dependencies
when expressing Intent policies about the ACP itself.</t> when expressing Intent policies about the ACP itself.</t>
<t>For example, Intent could indicate the desire to build an ACP across all domains <t indent="0" pn="section-a.7-3">For example, Intent could indicate the desire to build an ACP across all domains
that have a common parent domain (without relying on the rsub/routing-subdomain that have a common parent domain (without relying on the rsub/routing-subdomain
solution defined in this document). For example, ACP nodes with domain "example solution defined in this document): ACP nodes with the domains "example.com",
.com", "access.example.com", "core.example.com", and "city.core.example.com"
"access.example.com", "core.example.com" and "city.core.example.com"
should all establish one single ACP.</t> should all establish one single ACP.</t>
<t>If each domain has its own source of Intent, then the Intent would si <t indent="0" pn="section-a.7-4">If each domain has its own source of In
mply have to tent, then the Intent would simply have to
allow adding the peer domains TA and domain names to the parameters for the ACP allow adding the peer domain's TA and domain names to the parameters for the ACP
domain membership check domain membership check
(<xref target="certcheck" format="default"/>) so that nodes from those other dom (<xref target="certcheck" format="default" sectionFormat="of" derivedContent="Se
ains are accepted as ACP peers.</t> ction 6.2.3"/>) so that nodes from those other domains are accepted as ACP peers
<t>If this Intent was to be originated only from one domain, it could li .</t>
kely not be made <t indent="0" pn="section-a.7-5">If this Intent was to be originated onl
to work because the other domains will not build any ACP connection amongst each y from one domain, it could likely not be made
other, to work because the other domains will not build any ACP connections amongst eac
h other,
whether they use the same or different CA due to the ACP domain membership check .</t> whether they use the same or different CA due to the ACP domain membership check .</t>
<t>If the domains use the same CA one could change the ACP setup to per mit for the <t indent="0" pn="section-a.7-6">If the domains use the same CA, one co uld change the ACP setup to permit the
ACP to be established between two ACP nodes with different acp-domain-names, but only ACP to be established between two ACP nodes with different acp-domain-names, but only
for the purpose of disseminating limited information, for the purpose of disseminating limited information,
such as Intent, but not to set up full ACP connectivity, specifically not RPL ro uting such as Intent, but not to set up full ACP connectivity, specifically not RPL ro uting
and passing of arbitrary GRASP information. Unless the Intent policies permit t his and passing of arbitrary GRASP information, unless the Intent policies permit th is
to happen across domain boundaries.</t> to happen across domain boundaries.</t>
<t>This type of approach where the ACP first allows Intent to operate an <t indent="0" pn="section-a.7-7">This type of approach, where the ACP fi
d only then rst allows Intent to operate and only then
sets up the rest of ACP connectivity based on Intent policy could also be used sets up the rest of ACP connectivity based on Intent policy, could also be used
to to
enable Intent policies that would limit functionality across the ACP inside a do main, enable Intent policies that would limit functionality across the ACP inside a do main,
as long as no policy would disturb the distribution of Intent. For example, to l as long as no policy would disturb the distribution of Intent, for example, to l
imit imit
reachability across the ACP to certain type of nodes or locations of nodes.</t> reachability across the ACP to certain types of nodes or locations of nodes.</t>
</section> </section>
<section anchor="reuse-acp" numbered="true" toc="default"> <section anchor="reuse-acp" numbered="true" toc="include" removeInRFC="fal
<name>Adopting ACP concepts for other environments</name> se" pn="section-a.8">
<t>The ACP as specified in this document is very explicit about the choi <name slugifiedName="name-adopting-acp-concepts-for-o">Adopting ACP Conc
ce of options to epts for Other Environments</name>
<t indent="0" pn="section-a.8-1">The ACP as specified in this document i
s very explicit about the choice of options to
allow interoperable implementations. The choices made may not be the best for a ll environments, allow interoperable implementations. The choices made may not be the best for a ll environments,
but the concepts used by the ACP can be used to build derived solutions:</t> but the concepts used by the ACP can be used to build derived solutions.</t>
<t>The ACP specifies the use of ULA and deriving its prefix from the dom <t indent="0" pn="section-a.8-2">The ACP specifies the use of ULA and th
ain name e derivation of its prefix from the domain name
so that no address allocation is required to deploy the ACP. The ACP will equall y so that no address allocation is required to deploy the ACP. The ACP will equall y
work not using ULA but any other /48 IPv6 prefix. This prefix could simply be a work using any other /48 IPv6 prefix and not ULA. This prefix could simply be a
configuration configuration
of the ACP registrars (for example when using BRSKI) to enroll the domain certif of the ACP registrars (for example, when using BRSKI) to enroll the domain certi
icates - instead ficates, instead
of the ACP registrar deriving the /48 ULA prefix from the AN domain name.</t> of the ACP registrar deriving the /48 ULA prefix from the AN domain name.</t>
<t indent="0" pn="section-a.8-3">Some solutions may already have an auto
<t>Some solutions may already have an auto-addressing scheme, for exampl -addressing scheme, for example, derived from
e derived from existing, unique device identifiers (e.g., MAC addresses). In those cases, it m
existing unique device identifiers (e.g., MAC addresses). In those cases it may ay not be desirable
not be desirable
to assign addresses to devices via the ACP address information field in the way described to assign addresses to devices via the ACP address information field in the way described
in this document. The certificate may simply serve to identify the ACP domain, in this document. The certificate may simply serve to identify the ACP domain,
and the address field could be omitted. The only fix required in the remaining and the address field could be omitted. The only fix required in the remaining
way the ACP operate is to define another element in the domain certificate for way the ACP operates is to define another element in the domain certificate for
the two peers to decide who is the Decider and who is the Follower during secure channel building. the two peers to decide who is the Decider and who is the Follower during secure channel building.
Note though that future work may leverage the acp address to authenticate "owner Note though that future work may leverage the ACP address to authenticate "owner
ship" ship"
of the address by the device. If the address used by a device is derived from s of the address by the device. If the ACP address used by a device is derived fr
ome om some preexisting,
pre-existing permanent local ID (such as MAC address), then it would be useful t permanent local ID (such as MAC address), then it would be useful
o to store that local ID also in the certificate.</t>
store that address in the certificate using the format of the access address inf <t indent="0" pn="section-a.8-4">The ACP is defined as a separate VRF be
ormation cause it intends to support well-managed
field or in a similar way.</t>
<t>The ACP is defined as a separate VRF because it intends to support we
ll managed
networks with a wide variety of configurations. Therefore, reliable, networks with a wide variety of configurations. Therefore, reliable,
configuration-indestructible connectivity cannot be achieved from the Data-Plane configuration-indestructible connectivity cannot be achieved from the data plane
itself. itself.
In solutions where all transit connectivity impacting functions are fully automa In solutions where all functions that impact transit connectivity are fully auto
ted (including security), mated (including security),
indestructible and resilient, it would be possible to eliminate the need for the indestructible, and resilient, it would be possible to eliminate the need for th
ACP to be a separate VRF. e ACP to be a separate VRF.
Consider the most simple example system in which there is no separate Data-Plane Consider the most simple example system in which there is no separate data plane
, but the ACP is the Data-Plane. Add , but the ACP is the data plane. Add
BRSKI, and it becomes a fully autonomic network - except that it does not suppor BRSKI, and it becomes a fully Autonomic Network -- except that it does not suppo
t rt
automatic addressing for user equipment. This gap can then be closed for exampl automatic addressing for user equipment. This gap can then be closed, for examp
e by adding a le, by adding a
solution derived from <xref target="I-D.ietf-anima-prefix-management" format="de solution derived from "<xref target="RFC8992" format="title" sectionFormat="of"
fault"/>.</t> derivedContent="Autonomic IPv6 Edge Prefix Management in Large-Scale Networks"/>
<t>TCP/TLS as the protocols to provide reliability and security to GRASP " <xref target="RFC8992" format="default" sectionFormat="of" derivedContent="RFC
in the ACP 8992"/>.</t>
<t indent="0" pn="section-a.8-5">TCP/TLS as the protocols to provide rel
iability and security to GRASP in the ACP
may not be the preferred choice in constrained networks. For example, CoAP/DTLS may not be the preferred choice in constrained networks. For example, CoAP/DTLS
(Constrained Application Protocol) may be preferred where they are already used, (Constrained Application Protocol) may be preferred where they are already used,
allowing to reduce the additional code space footprint for the ACP on which would reduce the additional code space footprint for the ACP on
those devices. Hop-by-hop reliability for ACP GRASP messages could be made those devices. Hop-by-hop reliability for ACP GRASP messages could be made
to support protocols like DTLS by adding the same type of to support protocols like DTLS by adding the same type of
negotiation as defined in this document for ACP secure channel protocol negotiat ion. negotiation as defined in this document for ACP secure channel protocol negotiat ion.
End-to-end GRASP connections can be made to select their transport protocol In future ACP extensions meant to better support constrained devices,
in future extensions of the ACP meant to better support constrained devices by end-to-end GRASP connections can be made to select their transport protocol
indicating the supported transport protocols (e.g. TLS/DTLS) via GRASP parameter by indicating the supported transport protocols (e.g. TLS/DTLS) via GRASP parame
s ters
of the GRASP objective through which the transport endpoint is discovered.</t> of the GRASP objective through which the transport endpoint is discovered.</t>
<t>The routing protocol RPL used for the ACP does explicitly not optimiz e <t indent="0" pn="section-a.8-6">RPL, the routing protocol used for the ACP, explicitly does not optimize
for shortest paths and fastest convergence. Variations of the ACP may want to u se a for shortest paths and fastest convergence. Variations of the ACP may want to u se a
different routing protocol or introduce more advanced RPL profiles.</t> different routing protocol or introduce more advanced RPL profiles.</t>
<t>Variations such as what routing protocol to use, or whether to instan <t indent="0" pn="section-a.8-7">Variations such as which routing protoc
tiate an ACP ol to use, or whether to instantiate an ACP
in a VRF or (as suggested above) as the actual Data-Plane, can be automatically in a VRF or (as suggested above) as the actual data plane, can be automatically
chosen chosen
in implementations built to support multiple options by deriving them from futur e parameters in implementations built to support multiple options by deriving them from futur e parameters
in the certificate. Parameters in certificates should be limited to those that would in the certificate. Parameters in certificates should be limited to those that would
not need to be changed more often than certificates would need to be updated any not need to be changed more often than that certificates would need to be update
how; d,
Or by ensuring that these parameters can be provisioned before the or it should be ensured that these parameters can be provisioned before the
variation of an ACP is activated in a node. Using BRSKI, this could be done for variation of an ACP is activated in a node. Using BRSKI, this could be done, fo
example r example,
as additional follow-up signaling directly after the certificate enrollment, sti ll as additional follow-up signaling directly after the certificate enrollment, sti ll
leveraging the BRSKI TLS connection and therefore not introducing any additional leveraging the BRSKI TLS connection and therefore not introducing any additional
connectivity requirements.</t> connectivity requirements.</t>
<t>Last but not least, secure channel protocols including their encapsul <t indent="0" pn="section-a.8-8">Last but not least, secure channel prot
ations are ocols including their encapsulations are
easily added to ACP solutions. ACP hop-by-hop network layer secure channels cou easily added to ACP solutions. ACP hop-by-hop network-layer secure channels cou
ld ld
also be replaced by end-to-end security plus other means for infrastructure also be replaced by end-to-end security plus other means for infrastructure
protection. Any future network OAM should always use end-to-end security anyhow protection. Any future network OAM should always use end-to-end security. By
and can leveraging the domain certificates, it would not be dependent on security
leverage the domain certificates and is therefore not dependent on security to provided by ACP secure channels.</t>
be provided for by ACP secure channels.</t>
</section> </section>
<section anchor="futures" numbered="true" toc="default"> <section anchor="futures" numbered="true" toc="include" removeInRFC="false
<name>Further (future) options</name> " pn="section-a.9">
<section anchor="auto-aggregation" numbered="true" toc="default"> <name slugifiedName="name-further-future-options">Further (Future) Optio
<name>Auto-aggregation of routes</name> ns</name>
<t>Routing in the ACP according to this specification only leverages t <section anchor="auto-aggregation" numbered="true" toc="include" removeI
he nRFC="false" pn="section-a.9.1">
standard RPL mechanism of route optimization, e.g. keeping only routes that <name slugifiedName="name-auto-aggregation-of-routes">Auto-Aggregation
of Routes</name>
<t indent="0" pn="section-a.9.1-1">Routing in the ACP according to thi
s specification only leverages the
standard RPL mechanism of route optimization, e.g., keeping only the routes that
are not towards the RPL root. This is known to scale to networks with 20,000 or more nodes. are not towards the RPL root. This is known to scale to networks with 20,000 or more nodes.
There is no auto-aggregation of routes for /48 ULA prefixes (when using rsub There is no auto-aggregation of routes for /48 ULA prefixes (when using rsub
in the acp-node-name) and/or Zone-ID based prefixes.</t> in the acp-node-name) and/or Zone-ID based prefixes.</t>
<t>Automatic assignment of Zone-ID and auto-aggregation of routes coul <t indent="0" pn="section-a.9.1-2">Automatic assignment of Zone-ID and
d auto-aggregation of routes could
be achieved for example by configuring zone-boundaries, announcing via GRASP be achieved, for example, by configuring zone boundaries, announcing via GRASP
into the zones the zone parameters (zone-ID and /48 ULA prefix) and auto-aggrega into the zones the zone parameters (Zone-ID and /48 ULA prefix), and auto-aggreg
ting ating
routes on the zone-boundaries. Nodes would assign their Zone-ID and potentially routes on the zone boundaries. Nodes would assign their Zone-ID and potentially
even /48 prefix based on the GRASP announcements.</t> even the /48 prefix based on the GRASP announcements.</t>
</section> </section>
<section anchor="dp-dependency" numbered="true" toc="default"> <section anchor="dp-dependency" numbered="true" toc="include" removeInRF
<name>More options for avoiding IPv6 Data-Plane dependencies</name> C="false" pn="section-a.9.2">
<t>As described in <xref target="general_addressing" format="default"/ <name slugifiedName="name-more-options-for-avoiding-i">More Options fo
>, the ACP depends on the r Avoiding IPv6 Data Plane Dependencies</name>
Data-Plane to establish IPv6 link-local addressing on interfaces. Using a separa <t indent="0" pn="section-a.9.2-1">As described in <xref target="gener
te al_addressing" format="default" sectionFormat="of" derivedContent="Section 6.13.
MAC address for the ACP allows to fully isolate the ACP from the Data-Plane in 2"/>, the ACP depends on the
data plane to establish IPv6 link-local addressing on interfaces. Using a separa
te
MAC address for the ACP allows the full isolation of the ACP from the data plane
in
a way that is compatible with this specification. It is also an ideal option a way that is compatible with this specification. It is also an ideal option
when using Single-root input/output virtualization (SR-IOV - see when using single-root input/output virtualization (SR-IOV, see
<eref target="https://en.wikipedia.org/wiki/Single-root_input/output_virtualizat <xref target="SR" format="default" sectionFormat="of" derivedContent="SR"/>)
ion"/>)
in an implementation to isolate the ACP because in an implementation to isolate the ACP because
different SR-IOV interfaces use different MAC addresses.</t> different SR-IOV interfaces use different MAC addresses.</t>
<t>When additional MAC address(es) are not available, separation of th e <t indent="0" pn="section-a.9.2-2">When additional MAC address(es) are not available, separation of the
ACP could be done at different demux points. The same subnet interface could hav e ACP could be done at different demux points. The same subnet interface could hav e
a separate IPv6 interface for the ACP and Data-Plane and therefore separate a separate IPv6 interface for the ACP and data plane and therefore separate
link-local addresses for both, where the ACP interface is non-configurable on link-local addresses for both, where the ACP interface is not configurable on
the Data-Plane. This too would be compatible with this specification and not the data plane. This too would be compatible with this specification and not
impact interoperability.</t> impact interoperability.</t>
<t>An option that would require additional specification is to use a d ifferent <t indent="0" pn="section-a.9.2-3">An option that would require additi onal specification is to use a different
Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets for the ACP. This would Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets for the ACP. This would
be a similar approach as used for IP authentication packets in <xref target="IEE be a similar approach as used for IP authentication packets in <xref target="IEE
E-802.1X" format="default"/> E-802.1X" format="default" sectionFormat="of" derivedContent="IEEE-802.1X"/>,
which use the Extensible Authentication Protocol over Local Area Network (EAPoL) which uses the Extensible Authentication Protocol over Local Area Network (EAPoL
ethertype (0x88A2).</t> )
<t>Note that in the case of ANI nodes, all the above considerations eq Ethertype (0x88A2).</t>
ually <t indent="0" pn="section-a.9.2-4">Note that in the case of ANI nodes,
all of the above considerations equally
apply to the encapsulation of BRSKI packets including GRASP used for BRSKI.</t> apply to the encapsulation of BRSKI packets including GRASP used for BRSKI.</t>
</section> </section>
<section anchor="acp-api" numbered="true" toc="default"> <section anchor="acp-api" numbered="true" toc="include" removeInRFC="fal
<name>ACP APIs and operational models (YANG)</name> se" pn="section-a.9.3">
<t>Future work should define YANG (<xref target="RFC7950" format="defa <name slugifiedName="name-acp-apis-and-operational-mo">ACP APIs and Op
ult"/>) data model erational Models (YANG)</name>
and/or node internal APIs to monitor and manage the ACP.</t> <t indent="0" pn="section-a.9.3-1">Future work should define a YANG da
<t>Support for the ACP Adjacency Table (<xref target="adj-table" forma ta model <xref target="RFC7950" format="default" sectionFormat="of" derivedConte
t="default"/>) and ACP GRASP need to nt="RFC7950"/>
be included into such model/API.</t> and/or node-internal APIs to monitor and manage the ACP.</t>
<t indent="0" pn="section-a.9.3-2">Support for the ACP adjacency table
(<xref target="adj-table" format="default" sectionFormat="of" derivedContent="S
ection 6.3"/>) and ACP GRASP needs to
be included in such model and/or API.</t>
</section> </section>
<section anchor="future-rpl" numbered="true" toc="default"> <section anchor="future-rpl" numbered="true" toc="include" removeInRFC="
<name>RPL enhancements</name> false" pn="section-a.9.4">
<figure anchor="dual-noc"> <name slugifiedName="name-rpl-enhancements">RPL Enhancements</name>
<name>Dual NOC</name> <figure anchor="dual-noc" align="left" suppress-title="false" pn="figu
<artwork name="" type="" align="left" alt=""><![CDATA[ re-17">
<name slugifiedName="name-dual-noc">Dual NOC</name>
<artwork name="" type="" align="left" alt="" pn="section-a.9.4-1.1">
..... USA ...... ..... Europe ...... ..... USA ...... ..... Europe ......
NOC1 NOC2 NOC1 NOC2
| | | |
| metric 100 | | metric 100 |
ACP1 --------------------------- ACP2 . ACP1 --------------------------- ACP2 .
| | . WAN | | . WAN
| metric 10 metric 20 | . Core | metric 10 metric 20 | . Core
| | . | | .
ACP3 --------------------------- ACP4 . ACP3 --------------------------- ACP4 .
| metric 100 | | metric 100 |
| | . | | .
| | . Sites | | . Sites
ACP10 ACP11 . ACP10 ACP11 .
]]></artwork> </artwork>
</figure> </figure>
<t>The profile for RPL specified in this document builds only one span <t indent="0" pn="section-a.9.4-2">The profile for RPL specified in th
ning-tree path set to a root, typically a registrar in one NOC. In the presence is document builds only one spanning-tree path set to a root, typically a regist
of multiple NOCs, routing toward the non-root NOCs may be suboptimal. <xref targ rar in one NOC. In the presence of multiple NOCs, routing toward the non-root NO
et="dual-noc" format="default"/> shows an extreme example. Assuming that node AC Cs may be suboptimal. <xref target="dual-noc" format="default" sectionFormat="of
P1 becomes the RPL root, traffic between ACP11 and NOC2 will pass through ACP4-A " derivedContent="Figure 17"/> shows an extreme example. Assuming that node ACP1
CP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated DODAG/routes are s becomes the RPL root, traffic between ACP11 and NOC2 will pass through ACP4-ACP
hortest paths towards the RPL root.</t> 3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL-calculated DODAG and routes are
<t>To overcome these limitations, extensions/modifications to the RPL shortest paths towards the RPL root.</t>
profile can provide optimality for multiple NOCs. This requires utilizing Data- <t indent="0" pn="section-a.9.4-3">To overcome these limitations, exte
Plane artifact including IPinIP encap/decap on ACP routers and processing of IPv nsions and/or modifications to the RPL profile can optimize for multiple NOCs.
6 RPI headers. Alternatively, (Src,Dst) routing table entries could be used.</t This requires utilizing data plane artifacts, including IP-in-IP encapsulation/d
> ecapsulation on ACP routers and processing of IPv6 RPI headers. Alternatively,
<t>Flooding of ACP GRASP messages can be further constrained and there (Src,Dst) routing table entries could be used.</t>
fore optimized by flooding only via links that are part of the RPL DODAG.</t> <t indent="0" pn="section-a.9.4-4">Flooding of ACP GRASP messages can
be further constrained and therefore optimized by flooding only via links that a
re part of the RPL DODAG.</t>
</section> </section>
<section anchor="role-assignments" numbered="true" toc="default"> <section anchor="role-assignments" numbered="true" toc="include" removeI
<name>Role assignments</name> nRFC="false" pn="section-a.9.5">
<t>ACP connect is an explicit mechanism to "leak" ACP traffic explicit <name slugifiedName="name-role-assignments">Role Assignments</name>
ly (for example <t indent="0" pn="section-a.9.5-1">ACP connect is an explicit mechanis
m to "leak" ACP traffic explicitly (for example,
in a NOC). It is therefore also a possible security gap when it is easy to enabl e ACP in a NOC). It is therefore also a possible security gap when it is easy to enabl e ACP
connect on arbitrary compromised ACP nodes.</t> connect on arbitrary compromised ACP nodes.</t>
<t>One simple solution is to define an extension in the ACP certificat es ACP information <t indent="0" pn="section-a.9.5-2">One simple solution is to define an extension in the ACP certificate's ACP information
field indicating the permission for ACP connect to be configured on that ACP nod e. This field indicating the permission for ACP connect to be configured on that ACP nod e. This
could similarly be done to decide whether a node is permitted to be a registrar or not.</t> could similarly be done to decide whether a node is permitted to be a registrar or not.</t>
<t>Tying the permitted "roles" of an ACP node to the ACP certificate p <t indent="0" pn="section-a.9.5-3">Tying the permitted "roles" of an A
rovides CP node to the ACP certificate provides
fairly strong protection against misconfiguration, but is still subject to code fairly strong protection against misconfiguration, but it is still subject to co
de
modifications.</t> modifications.</t>
<t>Another interesting role to assign to certificates is that of a NOC <t indent="0" pn="section-a.9.5-4">Another interesting role to assign
node. This would allow to to certificates is that of a NOC node. This would allow the
limit certain type of connections such as OAM TLS connections to only NOC initia limiting of certain types of connections, such as OAM TLS connections to only th
tor e NOC initiators
or responders.</t> or responders.</t>
</section> </section>
<section anchor="l3-transit" numbered="true" toc="default"> <section anchor="l3-transit" numbered="true" toc="include" removeInRFC="
<name>Autonomic L3 transit</name> false" pn="section-a.9.6">
<t>In this specification, the ACP can only establish autonomic connect <name slugifiedName="name-autonomic-l3-transit">Autonomic L3 Transit</
ivity across L2 name>
hops and only explicitly configured options to tunnel across L3. Future work sho <t indent="0" pn="section-a.9.6-1">In this specification, the ACP can
uld only establish autonomic connectivity across L2
specify mechanisms to automatically tunnel ACP across L3 networks. A hub&amp;spo hops but requires non-autonomic configuration to tunnel across L3 paths. Future
ke work should
option would allow to tunnel across the Internet to a cloud or central instance specify mechanisms to automatically tunnel ACP across L3 networks. A hub-and-spo
of the ACP, ke
option would allow tunneling across the Internet to a cloud or central instance
of the ACP;
a peer-to-peer tunneling mechanism could tunnel ACP islands across an L3VPN infr astructure.</t> a peer-to-peer tunneling mechanism could tunnel ACP islands across an L3VPN infr astructure.</t>
</section> </section>
<section anchor="future-diag" numbered="true" toc="default"> <section anchor="future-diag" numbered="true" toc="include" removeInRFC=
<name>Diagnostics</name> "false" pn="section-a.9.7">
<t><xref target="diagnostics" format="default"/> describes diagnostics <name slugifiedName="name-diagnostics">Diagnostics</name>
options that can be done <t indent="0" pn="section-a.9.7-1"><xref target="diagnostics" format="
without changing the external, interoperability affecting characteristics of ACP default" sectionFormat="of" derivedContent="Section 9.1"/> describes diagnostics
implementations.</t> options that can be applied
<t>Even better diagnostics of ACP operations is possible with addition without changing the external, interoperability-affecting characteristics of ACP
al implementations.</t>
signaling extensions, such as:</t> <t indent="0" pn="section-a.9.7-2">Even better diagnostics of ACP oper
<ol type="1" spacing="compact"> ations are possible with additional
<li>Consider if LLDP should be a recommended functionality for ANI d signaling extensions, such as the following:</t>
evices <ol type="1" spacing="normal" indent="adaptive" start="1" pn="section-
a.9.7-3">
<li pn="section-a.9.7-3.1" derivedCounter="1.">Consider if LLDP shou
ld be a recommended functionality for ANI devices
to improve diagnostics, and if so, which information elements it should to improve diagnostics, and if so, which information elements it should
signal (noting that such information is conveyed in an insecure manner). Inc signal (noting that such information is conveyed in an insecure manner). Thi
ludes potentially new information elements.</li> s includes potentially new information elements.</li>
<li>In alternative to LLDP, A DULL GRASP diagnostics objective could <li pn="section-a.9.7-3.2" derivedCounter="2.">As an alternative to
LLDP, a DULL GRASP diagnostics objective could
be defined to carry these information elements.</li> be defined to carry these information elements.</li>
<li>The IDevID certificate of BRSKI pledges should be included in th <li pn="section-a.9.7-3.3" derivedCounter="3.">The IDevID certificat
e selected e of BRSKI pledges should be included in the selected
insecure diagnostics option. This may be undesirable when exposure of device insecure diagnostics option. This may be undesirable when exposure of device
information is seen as too much of a security issue (ability to deduce possible information is seen as too much of a security issue (the ability to deduce poss
attack vectors from device model for example).</li> ible attack vectors from device model, for example).</li>
<li>A richer set of diagnostics information should be made available <li pn="section-a.9.7-3.4" derivedCounter="4.">A richer set of diagn
ostics information should be made available
via the secured ACP channels, using either single-hop GRASP or via the secured ACP channels, using either single-hop GRASP or
network wide "topology discovery" mechanisms.</li> network-wide "topology discovery" mechanisms.</li>
</ol> </ol>
</section> </section>
<section anchor="compromised" numbered="true" toc="include" removeInRFC=
<section anchor="compromised" numbered="true" toc="default"> "false" pn="section-a.9.8">
<name>Avoiding and dealing with compromised ACP nodes</name> <name slugifiedName="name-avoiding-and-dealing-with-c">Avoiding and De
<t>Compromised ACP nodes pose the biggest risk to the operations of th aling with Compromised ACP Nodes</name>
e network. <t indent="0" pn="section-a.9.8-1">Compromised ACP nodes pose the bigg
The most common type of compromise is leakage of credentials to manage/configure est risk to the operations of the network.
the device and the application of malicious configuration including the change The most common types of compromise are the leakage of credentials to manage and
/or configure
the device and the application of malicious configuration, including the change
of access credentials, but not the change of software. Most of today's networkin g of access credentials, but not the change of software. Most of today's networkin g
equipment should have secure boot/software infrastructure anyhow, so attacks equipment should have secure boot/software infrastructure anyhow, so attacks
that introduce malicious software should be a lot harder.</t> that introduce malicious software should be a lot harder.</t>
<t>The most important aspect of security design against these type of <t indent="0" pn="section-a.9.8-2">The most important aspect of securi
attacks is ty design against these types of attacks is
to eliminate password based configuration access methods and instead rely on to eliminate password-based configuration access methods and instead rely on
certificate based credentials handed out only to nodes where it is clear that certificate-based credentials handed out only to nodes where it is clear that
the private keys cannot leak. This limits unexpected propagation of credentials. </t> the private keys cannot leak. This limits unexpected propagation of credentials. </t>
<t>If password based credentials to configure devices still need to be supported, they must not be <t indent="0" pn="section-a.9.8-3">If password-based credentials to co nfigure devices still need to be supported, they must not be
locally configurable, but only be remotely provisioned or verified (through locally configurable, but only be remotely provisioned or verified (through
protocols like RADIUS or Diameter), and there must be no local configuration protocols like RADIUS or Diameter), and there must be no local configuration
permitting to change these authentication mechanisms, but ideally they should permitting the change of these authentication mechanisms, but ideally they shoul
be autoconfiguring across the ACP. See <xref target="I-D.eckert-anima-noc-autoco d
nfig" format="default"/>.</t> be autoconfiguring across the ACP. See <xref target="I-D.eckert-anima-noc-autoco
<t>Without physical access to the compromised device, attackers with a nfig" format="default" sectionFormat="of" derivedContent="NOC-AUTOCONFIG"/>.</t>
ccess to <t indent="0" pn="section-a.9.8-4">Without physical access to the comp
romised device, attackers with access to
configuration should not be able to break the ACP connectivity, even when they configuration should not be able to break the ACP connectivity, even when they
can break or otherwise manipulate (spoof) the Data-Plane connectivity through co nfiguration. can break or otherwise manipulate (spoof) the data plane connectivity through co nfiguration.
To achieve this, it is necessary to avoid providing configuration options for th e To achieve this, it is necessary to avoid providing configuration options for th e
ACP, such as enabling/disabling it on interfaces. For example, there could be an ACP, such as enabling/disabling it on interfaces. For example, there could be an
ACP configuration that locks down the current ACP config unless factory reset is ACP configuration that locks down the current ACP configuration unless factory r
done.</t> eset is done.</t>
<t>With such means, the valid administration has the best chances to m <t indent="0" pn="section-a.9.8-5">With such means, the valid administ
aintain ration has the best chances to maintain
access to ACP nodes, discover malicious configuration though ongoing configurati access to ACP nodes, to discover malicious configuration though ongoing configur
on ation
tracking from central locations for example, and to react accordingly.</t> tracking from central locations, for example, and to react accordingly.</t>
<t>The primary reaction is withdrawal/change of credentials, terminate <t indent="0" pn="section-a.9.8-6">The primary reaction is to withdraw
malicious or change credentials, terminate malicious
existing management sessions and fixing the configuration. Ensuring that managem existing management sessions, and fix the configuration. Ensuring that managemen
ent t
sessions using invalidated credentials are terminated automatically without reco urse will sessions using invalidated credentials are terminated automatically without reco urse will
likely require new work.</t> likely require new work.</t>
<t>Only when these steps are not feasible would it be necessary <t indent="0" pn="section-a.9.8-7">Only when these steps are infeasibl
to revoke or expire the ACP certificate credentials and consider the node kicked e, would it be necessary
off the network - to revoke or expire the ACP certificate credentials and consider the node kicked
off the network
until the situation can be further rectified, likely requiring direct physical a ccess to the node.</t> until the situation can be further rectified, likely requiring direct physical a ccess to the node.</t>
<t>Without extensions, compromised ACP nodes can only be removed from the ACP <t indent="0" pn="section-a.9.8-8">Without extensions, compromised ACP nodes can only be removed from the ACP
at the speed of CRL/OCSP information refresh or expiry (and non-removal) at the speed of CRL/OCSP information refresh or expiry (and non-removal)
of short lived certificates. Future extensions to the ACP could for of short-lived certificates. Future extensions to the ACP could, for
example use GRASP flooding distribution of triggered updates of CRL/OCSP or example, use the GRASP flooding distribution of triggered updates of CRL/OCSP or
explicit removal indication of the compromised nodes domain certificate.</t> the explicit removal indication of the compromised node's domain certificate.</t
>
</section> </section>
<section anchor="downgrade" numbered="true" toc="include" removeInRFC="f
<section anchor="downgrade" numbered="true" toc="default"> alse" pn="section-a.9.9">
<name>Detecting ACP secure channel downgrade attacks</name> <name slugifiedName="name-detecting-acp-secure-channe">Detecting ACP S
ecure Channel Downgrade Attacks</name>
<t>The following text proposes a mechanism to protect against downgrad <t indent="0" pn="section-a.9.9-1">The following text proposes a mecha
e attacks without introducing a new specialized UPFRONT GRASP secure channel mec nism to protect against downgrade attacks without introducing a new specialized
hanism. Instead, it relies on running GRASP after establishing a secure channel GRASP secure channel mechanism. Instead, it relies on running GRASP after establ
protocol to verify if the established secure channel option could have been the ishing a secure channel protocol to verify if the established secure channel opt
result of a MITM downgrade attack:</t> ion could have been the result of a MITM downgrade attack.</t>
<t indent="0" pn="section-a.9.9-2">MITM attackers can force downgrade
<t>MITM attackers can force downgrade attacks for ACP secure channel s attacks for ACP secure channel selection by filtering and/or modifying DULL GRAS
election by filtering/modifying DULL GRASP messages and/or actual secure channel P messages and/or actual secure channel data packets. For example, if at some po
data packets. For example, if at some point in time DTLS traffic could be easie int in time, DTLS traffic could be more easily decrypted than traffic of IKEv2,
r decrypted than traffic of IKEv2, the MITM could filter all IKEv2 packets to fo the MITM could filter all IKEv2 packets to force ACP nodes to use DTLS (assuming
rce ACP nodes to use DTLS (assuming the ACP nodes in question supported both DTL that the ACP nodes in question supported both DTLS and IKEv2).</t>
S and IKEv2).</t> <t indent="0" pn="section-a.9.9-3">For cases where such MITM attacks a
<t>For cases where such MITM attacks are not capable to inject malicio re not capable of injecting malicious traffic (but only of decrypting the traffi
us traffic (but only to decrypt the traffic), a downgrade attack could be discov c), a downgrade attack could be discovered after a secure channel connection is
ered after a secure channel connection is established, for example by use of the established, for example, by using the following type of mechanism.</t>
following type of mechanism:</t> <t indent="0" pn="section-a.9.9-4">After the secure channel connection
<t>After the secure channel connection is established, the two ACP pee is established, the two ACP peers negotiate, via an appropriate (to be defined)
rs negotiate via an appropriate (To Be Defined) GRASP negotiation which ACP secu GRASP negotiation, which ACP secure channel protocol should have been selected
re channel protocol should have been selected between them (in the absence of a between them (in the absence of a MITM attacker). This negotiation would signal
MITM attacker). This negotiation would have to signal the DULL GRASP announced A the ACP secure channel options announced by DULL GRASP by each peer followed by
CP secure channel options by each peer followed by an announcement of the prefer an announcement of the preferred secure channel protocol by the ACP peer that is
red secure channel protocol by the ACP peer that is the Decider in the secure ch the Decider in the secure channel setup, i.e., the ACP peer that decides which
annel setup, e.g. the ACP peer that is deciding which secure channel protocol to secure channel protocol to use. If that chosen secure channel protocol is diffe
pick. If that chosen secure channel protocol is different from the one that act rent from the one that actually was chosen, then this mismatch is an indication
ually was chosen, then this mismatch is an indication that there is a MITM attac that there is a MITM attacker or other similar issue (e.g., a firewall prohibiti
ker or other similar issue (firewall prohibiting the use of specific protocols) ng the use of specific protocols) that caused a non-preferred secure channel pro
that caused a non-preferred secure channel protocol to be chosen. This discovery tocol to be chosen. This discovery could then result in mitigation options such
could then result in mitigation options such as logging and ensuing investigati as logging and ensuing investigations.</t>
ons.</t>
</section> </section>
</section> </section>
</section> </section>
<!-- further considerations --> <section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn=
"section-appendix.b">
<section anchor="unfinished" numbered="true" toc="default"> <name slugifiedName="name-acknowledgements">Acknowledgements</name>
<name>Unfinished considerations (To Be Removed From RFC)</name> <t indent="0" pn="section-appendix.b-1">This work originated from an Auton
omic Networking project at Cisco
<t>[RFC-Editor: This whole appendix B. and its subsections to be removed Systems, which started in early 2010. Many people contributed to this proj
for the RFC.</t> ect and the idea of the Autonomic Control Plane, amongst whom (in alphabetical o
rder): <contact fullname="Ignas Bagdonas"/>, <contact fullname="Parag Bhide"/>,
<t>This appendix contains unfinished considerations that are removed from <contact fullname="Balaji BL"/>, <contact fullname="Alex Clemm"/>, <contact full
the RFC, name="Yves Hertoghs"/>, <contact fullname="Bruno Klauser"/>, <contact fullname="
they are maintained in this draft as a log of the state of discussion a Max Pritikin"/>, <contact fullname="Michael Richardson"/>, and <contact fullname
nd ="Ravi Kumar Vadapalli"/>.</t>
point of reference. Together with this appendix, also the references po <t indent="0" pn="section-appendix.b-2">Special thanks to <contact fullnam
inting to e="Brian Carpenter"/>, <contact fullname="Elwyn Davies"/>, <contact fullname="Jo
it are marked to be removed from the RFC because no consensus could be el Halpern"/>, and <contact fullname="Sheng Jiang"/> for their thorough reviews.
reached that </t>
a self-reference to a draft version of the RFC is an appropriate breadc <t indent="0" pn="section-appendix.b-3">Many thanks to <contact fullname="
rumb Ben Kaduk"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Eric R
to point to unfinished considerations.</t> escorla"/> for their thorough SEC AD reviews, <contact fullname="Russ Housley"/>
and <contact fullname="Erik Kline"/> for their reviews, and to <contact fullnam
<t>The authors plan to move these considerations into a new target inform e="Valery Smyslov"/>, <contact fullname="Tero Kivinen"/>, <contact fullname="Pau
ational l Wouters"/>, and <contact fullname="Yoav Nir"/> for review of IPsec and IKEv2 p
draft, please look for draft-eckert-anima-acp-considerations.</t> arameters and helping to understand those and other security protocol details be
tter. Thanks to <contact fullname="Carsten Bormann"/> for CBOR/CDDL help.</t>
<section anchor="ben-kaduk" numbered="true" toc="default"> <t indent="0" pn="section-appendix.b-4">Further input, review, or suggesti
<name>Considerations for improving secure channel negotiation</name> ons were received from <contact fullname="Rene Struik"/>, <contact fullname="Ben
oit Claise"/>, <contact fullname="William Atwood"/>, and <contact fullname="Yong
<t>Proposed text from Benjamin Kaduk. It is suggested to replace kang Zhang"/>.</t>
the text of appendix A.6 in previous versions of this draft (up to ver </section>
sion 29).</t> <section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse" pn="section-appendix.c">
<t>The discovery procedure in this specification for low-level ACP cha <name slugifiedName="name-contributors">Contributors</name>
nnel <t indent="0" pn="section-appendix.c-1">For all things GRASP including val
support by layer-2 peers involves DULL GRASP and attempting (usually i idation code, ongoing document text support, and technical input:</t>
n <contact fullname="Brian Carpenter" initials="B. E." surname="Carpenter">
parallel) to establish all supported channel types, learning the peer <organization abbrev="Univ. of Auckland" showOnFrontPage="true"/>
ACP <address>
address and correspondingly the assignment of Decider and Follower rol <postal>
es, <street>School of Computer Science</street>
and tearing down all channels other than the one preferred by the Deci <street>University of Auckland</street>
der. <street>PB 92019</street>
This procedure, in general, becomes resource intensive as the number o <city>Auckland</city>
f <code>1142</code>
possible secure channels grows; even worse, under some threat models, <country>New Zealand</country>
the </postal>
security of the discovery result is only as strong as the weakest supp <email>brian.e.carpenter@gmail.com</email>
orted </address>
secure channel protocol. Furthermore, the unilateral determination of </contact>
"best" channel type by the Decider does not result in the optimal outc <t indent="0" pn="section-appendix.c-2">For RPL contributions and all thin
ome gs BRSKI/bootstrap including validation code, ongoing document text support, and
in all possible scenarios.</t> technical input:</t>
<contact fullname="Michael C. Richardson" initials="M." surname="Richardso
<t>This situation is tolerable at present, with only two secure channe n">
ls (DTLS <organization abbrev="Sandelman" showOnFrontPage="true">Sandelman Softwa
and IPsec) defined, but long-term agility in the vein of [BCP201] will re Works</organization>
require the introduction of an alternate discovery/negotiation procedu <address>
re. <email>mcr+ietf@sandelman.ca</email>
While IKEv2 is the IETF standard protocol for negotiating security <uri>http://www.sandelman.ca/mcr/</uri>
associations, it currently does not have a defined mechanism flexible </address>
enough to negotiate the parameters needed for, e.g., an ACP DTLS chann </contact>
el, <t indent="0" pn="section-appendix.c-3">For the RPL technology choices and
let alone for allowing ACP peers to indicate their preference metrics text:</t>
for <contact initials="P" surname="Thubert" fullname="Pascal Thubert">
channel selection. Such a mechanism or mechanisms could be defined, b <organization abbrev="Cisco Systems" showOnFrontPage="true">Cisco System
ut if s, Inc</organization>
ACP agility requires introducing a new channel type, for example MacSe <address>
c, <postal>
IKEv2 would again need to be extended in order to negotiate an ACP Mac <street>Building D</street>
Sec <street>45 Allee des Ormes - BP1200</street>
association. Making ACP channel agility dependent on updates to IKEv2 <city>Mougins - Sophia Antipolis</city>
is <code>06254</code>
likely to result in obstacles due to different timescales of evolution <country>France</country>
, </postal>
since IKEv2 implementations help form the core of Internet-scale secur <phone>+33 497 23 26 34</phone>
ity <email>pthubert@cisco.com</email>
infrastructure and must accordingly be robust and thoroughly tested.</ </address>
t> </contact>
</section>
<t>Accordingly, a dedicated ACP channel negotiation mechanism is appro <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
priate ="include" pn="section-appendix.d">
as a way to provide long-term algorithm and secure-channel protocol <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
agility. Such a mechanism is not currently defined, but one possible <author role="editor" fullname="Toerless Eckert" surname="Eckert">
design is as follows. A new DULL GRASP objective is defined to indica <organization abbrev="Futurewei USA" showOnFrontPage="true">Futurewei Te
te chnologies Inc. USA</organization>
the GRASP-over-TLS channel, which is by definition preferred to other <address>
channel types (including DTLS and IPsec). When both peers advertise <postal>
support for GRASP-over-TLS, GRASP-over-TLS must run to completion befo <street>2330 Central Expy</street>
re <city>Santa Clara</city>
other channel types are attempted. The GRASP-over-TLS channel perform <region>CA</region>
s the <code>95050</code>
necessary negotiation by establishing a TLS connection between the pee <country>United States of America</country>
rs </postal>
and using that connection to secure a dedicated GRASP instance for <email>tte+ietf@cs.fau.de</email>
negotiating supported channel types and preference metrics. This prov </address>
ides </author>
a rich language for determining what secure channel protocol to use fo <author role="editor" fullname="Michael H. Behringer" initials="M." surnam
r the e="Behringer">
ACP link while taking into account the capabilities and preferences of <address>
the <email>michael.h.behringer@gmail.com</email>
ACP peers, all protected by the security of the TLS channel.</t> </address>
</section> </author>
<author fullname="Steinthor Bjarnason" initials="S." surname="Bjarnason">
<section anchor="verify-address" numbered="true" toc="default"> <organization showOnFrontPage="true">Arbor Networks</organization>
<name>ACP address verification</name> <address>
<postal>
<t>The AcpNodeName of most ACP nodes contains in the acp-address field the <street>2727 South State Street, Suite 200</street>
primary ACP address to be used by the node for end-to-end connections <city>Ann Arbor</city>
across ACP secure channels. Nevertheless, there is no verification of an <region>MI</region>
ACP peers address specified in this document. This section explains the <code>48104</code>
current understanding as to why this is not done.</t> <country>United States of America</country>
</postal>
<t>Not all ACP nodes will have an actual IPv6 address in the acp-address field <email>sbjarnason@arbor.net</email>
of their AcpNodeName. Those who do not include nodes that do not support </address>
ACP secure channels, such as pre-existing NOC equipment that only connects </author>
to the ACP via ACP connect interfaces. Likewise, future ACP node type that
may want to have their Node-ID not be defined by an ACP registrar, but
differently cannot have the ACP address be provided in their ACP certificate
where it would be defined by the registrar. In result, any scheme that
would rely on verification of the acp-address in the ACP certificate would
only apply to a subset of ACP nodes.</t>
<t>The transport stack network layer address used for ACP secure channels
is not the acp-address. For automatically established ACP secure channels,
it is a link-local IPv6 address. For explicitly configured ACP secure
channels (to reach across non ACP L3 network segments), the address is
any IPv4 or IPv6 address routable to that remote destination.</t>
<t>When the acp-address is actually used across the ACP, it can only
be verified by a peer when the peer has the certificate of the peer.
Unless further higher layer mechanisms are developed on top of the
ACP (for example via ASA), the only mechanism to access a peers ACP
certificate is for secure connections in which the peers certificates
are exchanged and cryptographically verified, e.g. TLS and DTLS.
Initially, it is expected that the ACP will carry many legacy network
management control connections that unfortunately not end-to-end
authenticated but that are solely protected by being carried across
the ACP secure channels. ACP address verification therefore cannot
be used for such connections without additional higher layer components.</t>
<t>For the remaining (TLS/DTLS) connections for which address verification
can be used, the main question is: what additional benefit would address
verification provide?</t>
<t>The main value that transport stack network layer address verification
could provide for these type of connections would be the discovery
of on-path transport proxies. For example, in case of BRSKI,
pledges connect to an ACP registrar via an ASA implementing a TCP
proxy because the pledge itself has at that point in time no
ACP certificate valid to build ACP secure channels and hence needs to
rely on such a proxy. This is one example where such a TCP proxy is
required and not a form of attack.</t>
<t>In general, on path TCP proxies could be a form of attack, but it stands
to reason, that an attacker that manages to enable a malicious
TCP proxy could likely equally build a transparent proxy not changing
the network layer addresses. Only when the attacker operates off-path
would this option not be possible. Such attacks could indeed be possible:
An impaired ACP node could announce itself as another service instance
for a service whose utilization it wants to attack. It could then attempt
to look like a valid server by simply TCP proxying the clients
connections to a valid server and then attack the connections
passing through it (passive decrypting or passive fingerprint analysis).
But like the BRSKI proxy, this behavior could be
perfectly legitimate and not an attack. For example, TCP has in the
past often suffered from performance issues across difficult (high
capacity, high loss) paths, and TCP proxies where and are being used
simply as a tool for isolating such path segments (such as a WAN),
and providing caching and local-retransmit of in-transit packets,
reducing the effective path segment capacity.</t>
<t>As explained elsewhere in this document already, considerations for
these type of attack are therefore outside the scope of the ACP but
fundametal to further design of the ASA infrastructure. Beyond
distinguishing whether a TCP proxy would be beneficial or malicious,
the even more fundamental question is how to determine from a multitude
of service announcements which instance is the most trustworthy and
functionally best. In the Internet/web, this question is NOT solved
inside the network but through off-net human interaction ("trust me,
the best search engine is www.&lt;insert-your-personal-recommendation>.com").<
/t>
</section>
<section anchor="public-ca" numbered="true" toc="default">
<name>Public CA considerations</name>
<t>Public CAs are outside the scope of this document for the following reasons
. This appendix describes the current state of understanding for those intereste
d to consider utilizing public CA for the ACP in the future.</t>
<t>If public CA where to be used to enroll ACP nodes and act as TA, this would
require a model in which
the public CA would be able to assert the ownership of the information request
ed in the certificate,
especially the AcpNodeName, for example mitigated by the domain registrar(s).
Due to the use of a new, ACP unique encoding of the AcpNodeName,
there is no mechanism for public CA to do so. More importantly though, isolati
on between
ACPs of disjoint operated ACPs is achieved in the current ACP design through d
isjoint TA.
A public CA is in general based on a single (set of) TA shared across all cert
ificates signed by the CA.</t>
<t>Due to the fact that the ACP domain membership check also validates that a
peers domain name
in the AcpNodeName matches that of the ACP node itself, it would be possible t
o use the same
TA across disjoint ACP domains, but the security and attack implications of su
ch an approach
are beyond the scope of this document.</t>
<t>The use of ULA addresses in the AcpNodeName is another novel aspect for cer
tificates
from a possible public CA. Typically, ULA addresses are not meant to be signe
d by a public CA when
carried in an address field, because there is no ownership of a particular
ULA address in the scope of the Internet, which is what public CA operate on.
Nevertheless, the ULA addresses used by the ACP are scoped to be valid only wi
thin
the confines of a specific ACP as defined by the domain name in the AcpNodeNam
e.
However, this understanding has not been reviewed or accepted by any bodies
responsible for policies of public CA.</t>
<t>Because in this specification, ACPs are isolated from each other primarily
by their TA,
when a public CA would intend to sign ACP certificates and using a single TA t
o sign
TA of ACP certificates from different operators/domain, it could do so by ensu
ring that
the domain name in the AcpNodeName was a globally owned DNS ACP domain name
of the organization, and beyond that, it would need to validate that the ACP r
egistrar
of that domain who is mitigating the enrollment is authorized to vouch for the
ownership
of the acp-address within the scope of the ACP domain name.</t>
</section>
<section anchor="hardening" numbered="true" toc="default">
<name>Hardening DULL GRASP considerations</name>
<t>DULL GRASP suffers from similar type of DoS attacks as many
link-local multicast discovery protocols, for example mDNS.
Attackers on a subnet may be able to inject malicious DULL GRASP
messages that are indistinguishable from non-malicious DULL GRASP
messages to create Denial-of-Service (DoS) attacks that force ACP
nodes to attempt many unsuccessful ACP secure channel connections.</t>
<t>When an ACP node sees multiple AN_ACP objectives for the same secure
channel protocol on different transport addresses, it could prefer
connecting via the well-known transport address if the secure channel
method has one, such as UDP port 500 for IKEv2. For protocols such as
(ACP secure channel over) DTLS for which there are no well defined port
number, this heuristic does not provide benefits though.</t>
<t>DoS attack with port numbers can also be eliminated by relying
on well known-port numbers implied by the GRASP method-name. For
example, a future service name of "DTLSacp" could be defined to
be associated only to a newly to be assigned well known UDP port for ACP
over DTLS, and the port number in the GRASP transport address
information would be ignored. Note that there is already
a variety of ports assigned to specific protocols over DTLS by IANA,
so especially for DTLS this would not be uncommon.</t>
</section>
</section> </section>
<!-- unfinished considerations -->
</back> </back>
</rfc> </rfc>
<!-- REMOVED this section in version 12 due to feedback by working group
(Michael Richardson). Let IETF feedback decide if this additional text
is necessary
<section anchor="up4291" title="RFC4291/RFC4193 Updates Considerations">
<t>This document may be considered to be updating the IPv6 addressing architectu
re
(<xref target="RFC4291"/>) and/or the Unique Local IPv6 Unicast addresses (<xref
target="RFC4193"/>)
depending on how strict specific statements in those specs are to be interpreted
.
This section summarized and explains the necessity and benefits of these changes
. The normative
parts of this document cover the actual updates.</t>
<t>ACP addresses (<xref target="addressing"/>) are used by network nodes support
ing the ACP. They are
assigned during bootstrap of the nodes or initial provisioning of the ACP. They
are encoded in the Domain Certificate of the node and are primarily used intern
ally
within the node. In that role they can be thought of as Loopback addresses.</t>
<t>Each ACP domain assigns ACP addresses from one or more ULA prefixes.
Within an ACP network, addresses are assigned by nodes called registrars.
A unique Registrar-ID(entifier) is used in ACP addresses to allow multiple regis
trars
to assign addresses autonomically and uncoordinated from each other. Typically
these
Registrar-IDs are derived from the IEEE 802 48-bit MAC addresses of registrars.<
/t>
<t>In the ACP Zone Addressing Sub-Scheme (<xref target="zone-scheme"/>), the reg
istrar assigns
a unique 15-bit value to an ACP node. The ACP address has a 64-bit Node-ID(enti
fier)
composed of the 48-bit Registrar-ID, the registrar assigned 15-bit Node-Number a
nd 1 V(irtualization)
bit that allows for an ACP node to have two addresses.</t>
<t>The 64-bit Node-Identifier in the ACP Zone Addressing Sub-Scheme matches the
64-bit
Interface Identifier (IID) address part as specified in RFC4291 section 2.5.1.
IIDs are unique across ACP nodes, but all ACP nodes with the same ULA prefix
that use the ACP Zone Addressing Sub-Scheme will share the same subnet prefix
(according to the definition of that term in RFC4291). Each ACP node injects a
/127
route into the ACP routing table to cover its two assigned addresses (V(irtual)
bit being 0 or 1).
This approach is used because these ACP addresses are identifiers and not locato
rs. The ACP node
can connect anywhere in the ACP domain without having to change its addresses.
The lightweight,
highly scaleable routing protocol RPL is used to allow for large scale ACP netwo
rks.</t>
<t>It is possible, that this scheme constitutes an update to RFC4191 because the
same 64-bit subnet prefix is used across many ACP nodes. The ACP Zone Addressin
g
Sub-Scheme is very similar to the common operational practices of assigning /128
Loopback addresses to network nodes from the same /48 or /64 subnet prefix.</t>
<t>In the ACP Vlong Addressing Sub-Scheme (<xref target="Vlong"/>), the address
elements
are the same as described for the Zone Addressing Sub-Scheme, but the V field is
expanded from 1-bit to 8 or 16-bits. The ACP node with ACP Vlong addressing the
refore injects
/120 or /112 prefixes into the ACP routing table to cover its internal addresses
.</t>
<t>The goal for the 8 or 16-bit addresses available to an ACP node in this schem
e
is to assign them as required to software components, which in autonomic network
ing
are called ASA (Autonomic Service Agents). It could equally be used for existin
g
software components such as VNFs (Virtual Networking Functions). The ACP interf
ace would
then be the out-of-band management interface of such a VNF software component.
It should especially be possible to use these software components in a variety o
f contexts
to allow standardized modular system composition: Native applications (in some V
RF context if available),
containers, virtual machines or other future ones. To modularily compose a syst
em with containers
and virtual machines and avoid problems such as port space collision or NAT, it
is necessary not
only to assign separate addresses to those contexts, but also to use the notion
of virtual
interfaces between these contexts to compose the system.</t>
<t>In practical terms, the ACP should be enabled to create from its /8 or /16
prefix one or more node internal virtual subnets and to start software component
s
connected to those virtual subnets. Ideally, these software components should b
e
able to auto configure their addresses on these virtual interfaces. Future work
has to determine whether this address auto configuration for the virtual interfa
ce
is best done with DHCPv6, if SLAAC should be recommended for these /8 or /16 vir
tual
interfaces, or if some additional standardized method would be required.</t>
<t>In the ACP Vlong Addressing scheme, the Node-ID does not match the RFC4291/RF
C4193
64-bith length for the Interface Identifier, so this addressing Sub-Scheme
in the ACP is an update to both standards.</t>
<t>This document also specifies the workaround solution of exposing the ACP
on native interfaces in support of adoption by existing hardware and software
solutions. A NOC based NMS host could for example be configured with a second
native interface connecting to an ACP node that exposes the ACP to that NMS
host (called ACP edge node). The desired evolution of this workaround is that
those two functions would merge into a single node, for example by making the AC
P
router a container/virtual machine inside the NMS host or vice versa. The addre
ssing
for those native interfaces allows for manually configured address prefixes but
it could be fully autonomous if it could leverage the Vlong addressing format.
That would
result in a non /64 IID boundary on those external interfaces (but instead in /
112 or
/120 subnet prefixes).</t>
<t>Note that both in the internal as well as the workaround external use of ACP
addresses, all ACP addresses are meant to be used exclusively by components that
are part of network control and OAM, but not for network users such as normal ho
sts.
This implies that for example no requirements for privacy addressing have
been identified for ACP addresses.</t>
</section>
 End of changes. 764 change blocks. 
9083 lines changed or deleted 10555 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/