draft-ietf-anima-autonomic-control-plane-17.txt   draft-ietf-anima-autonomic-control-plane-18.txt 
ANIMA WG T. Eckert, Ed. ANIMA WG T. Eckert, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track M. Behringer, Ed. Intended status: Standards Track M. Behringer, Ed.
Expires: February 8, 2019 Expires: February 8, 2019
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
August 07, 2018 August 07, 2018
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-17 draft-ietf-anima-autonomic-control-plane-18
Abstract Abstract
Autonomic functions need a control plane to communicate, which Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Management depends on some addressing and routing. This Autonomic Management
and Control Plane should ideally be self-managing, and as independent and Control Plane should ideally be self-managing, and as independent
as possible of configuration. This document defines such a plane and as possible of configuration. This document defines such a plane and
calls it the "Autonomic Control Plane", with the primary use as a calls it the "Autonomic Control Plane", with the primary use as a
control plane for autonomic functions. It also serves as a "virtual control plane for autonomic functions. It also serves as a "virtual
out-of-band channel" for Operations Administration and Management out-of-band channel" for Operations Administration and Management
skipping to change at page 4, line 19 skipping to change at page 4, line 19
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 74 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 74
9.3. The Administrator View . . . . . . . . . . . . . . . . . 75 9.3. The Administrator View . . . . . . . . . . . . . . . . . 75
10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 75 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 75
10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 76 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 76
10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 80 10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 80
10.2.1. Registrar interactions . . . . . . . . . . . . . . . 81 10.2.1. Registrar interactions . . . . . . . . . . . . . . . 81
10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82
10.2.3. Certificate renewal and limitations . . . . . . . . 83 10.2.3. Certificate renewal and limitations . . . . . . . . 83
10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83
10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84
10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 85 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 84
10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85
10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85
10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86
10.3.2.2. Fast state propagation and Diagnostics . . . . . 87 10.3.2.2. Fast state propagation and Diagnostics . . . . . 87
10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87
10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 88 10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 88
10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88
10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88
10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90
10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90
10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91
10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91
10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92
11. Security Considerations . . . . . . . . . . . . . . . . . . . 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 92
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 95 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 94
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 95 14.1. Initial version . . . . . . . . . . . . . . . . . . . . 94
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 95 14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 95
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 95 14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 95
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 95 14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 95
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 95 14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 95
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 96 14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 96
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 96 14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 96
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 97 14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 96
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 97 14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 97
14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 97 14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 97
14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 98 14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 97
14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 98 14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 98
14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 99 14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 98
14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 100 14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 100
14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 102 14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 102
14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 104 14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 104
14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 106 14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 105
14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 106 14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 106
14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 107 14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 107
14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 109 14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 109
14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 113 14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 113
14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 114 14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 113
14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 114 14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 114
14.24. draft-ietf-anima-autonomic-control-plane-18 . . . . . . 116
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 116
15.1. Normative References . . . . . . . . . . . . . . . . . . 116 15.1. Normative References . . . . . . . . . . . . . . . . . . 116
15.2. Informative References . . . . . . . . . . . . . . . . . 119 15.2. Informative References . . . . . . . . . . . . . . . . . 118
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 123 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Appendix A. Background and Futures (Informative) . . . . . . . . 123 Appendix A. Background and Futures (Informative) . . . . . . . . 123
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 124 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 123
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 124 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 124
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 126 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 125
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 126 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 125
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 126 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 126
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 126 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 126
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 127 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 126
A.5. ACP Information Distribution and multicast . . . . . . . 128 A.5. ACP Information Distribution and multicast . . . . . . . 128
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 129 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 129
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 131 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 131
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 132 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 132
A.9. Adopting ACP concepts for other environments . . . . . . 133 A.9. Adopting ACP concepts for other environments . . . . . . 133
A.10. Further options / futures . . . . . . . . . . . . . . . . 135 A.10. Further options / futures . . . . . . . . . . . . . . . . 134
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 135 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 134
A.10.2. More options for avoiding IPv6 Data-Plane dependency 135 A.10.2. More options for avoiding IPv6 Data-Plane dependency 135
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 136 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 135
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 136 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 136
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 137 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 136
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 137 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 137
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 137 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 137
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138
1. Introduction (Informative) 1. Introduction (Informative)
Autonomic Networking is a concept of self-management: Autonomic Autonomic Networking is a concept of self-management: Autonomic
functions self-configure, and negotiate parameters and settings functions self-configure, and negotiate parameters and settings
across the network. [RFC7575] defines the fundamental ideas and across the network. [RFC7575] defines the fundamental ideas and
design goals of Autonomic Networking. A gap analysis of Autonomic design goals of Autonomic Networking. A gap analysis of Autonomic
skipping to change at page 6, line 12 skipping to change at page 6, line 13
and re-usable by all autonomic functions. Section 5 of [RFC7575] and re-usable by all autonomic functions. Section 5 of [RFC7575]
introduces that infrastructure and calls it the Autonomic Control introduces that infrastructure and calls it the Autonomic Control
Plane (ACP). More descriptively it would be the "Autonomic Plane (ACP). More descriptively it would be the "Autonomic
communications infrastructure for Management and Control". For communications infrastructure for Management and Control". For
naming consistency with that prior document, this document continues naming consistency with that prior document, this document continues
to use the name ACP though. to use the name ACP though.
Today, the management and control plane of networks typically uses a Today, the management and control plane of networks typically uses a
routing and forwarding table which is dependent on correct routing and forwarding table which is dependent on correct
configuration and routing. Misconfigurations or routing problems can configuration and routing. Misconfigurations or routing problems can
therefore disrupt management and control channels. Traditionally, an disrupt management and control channels. Traditionally, an out-of-
out-of-band network has been used to avoid or allow recovery from band network has been used to avoid or allow recovery from such
such problems, or personnel are sent on site to access devices problems, or personnel are sent on site to access devices through
through out-of-band management ports (also called craft ports, serial out-of-band management ports (also called craft ports, serial
console, management ethernet port). However, both options are console, management ethernet port). However, both options are
expensive. expensive.
In increasingly automated networks either centralized management In increasingly automated networks either centralized management
systems or distributed autonomic service agents in the network systems or distributed autonomic service agents in the network
require a control plane which is independent of the configuration of require a control plane which is independent of the configuration of
the network they manage, to avoid impacting their own operations the network they manage, to avoid impacting their own operations
through the configuration actions they take. through the configuration actions they take.
This document describes a modular design for a self-forming, self- This document describes a modular design for a self-forming, self-
managing and self-protecting Autonomic Control Plane (ACP), which is managing and self-protecting Autonomic Control Plane (ACP), which is
a virtual in-band network designed to be as independent as possible a virtual in-band network designed to be as independent as possible
of configuration, addressing and routing problems. The details how of configuration, addressing and routing problems. The details how
this are achieved as described in Section 6. The ACP is designed to this is achieved are described in Section 6. The ACP is designed to
remain operational even in the presence of configuration errors, remain operational even in the presence of configuration errors,
addressing or routing issues, or where policy could inadvertently addressing or routing issues, or where policy could inadvertently
affect connectivity of both data packets or control packets. affect connectivity of both data packets or control packets.
This document uses the term "Data-Plane" to refer to anything in the This document uses the term "Data-Plane" to refer to anything in the
network nodes that is not the ACP, and therefore considered to be network nodes that is not the ACP, and therefore considered to be
dependent on (mis-)configuration. This Data-Plane includes both the dependent on (mis-)configuration. This Data-Plane includes both the
traditional forwarding-plane, as well as any pre-existing control- traditional forwarding-plane, as well as any pre-existing control-
plane, such as routing protocols that establish routing tables for plane, such as routing protocols that establish routing tables for
the forwarding plane. the forwarding plane.
skipping to change at page 7, line 17 skipping to change at page 7, line 20
[I-D.ietf-anima-bootstrapping-keyinfra]. [I-D.ietf-anima-bootstrapping-keyinfra].
3. An operator can use it to log into remote devices, even if the 3. An operator can use it to log into remote devices, even if the
network is misconfigured or not configured. network is misconfigured or not configured.
This document describes these purposes as use cases for the ACP in This document describes these purposes as use cases for the ACP in
Section 3, it defines the requirements in Section 4. Section 5 gives Section 3, it defines the requirements in Section 4. Section 5 gives
an overview how the ACP is constructed. an overview how the ACP is constructed.
The normative part of this document starts with Section 6, where the The normative part of this document starts with Section 6, where the
the ACP is specified. Section 7 defines normative how to support ACP ACP is specified. Section 7 defines normative how to support ACP on
on L2 switches. Section 8 explains normative how non-ACP nodes and L2 switches. Section 8 explains normative how non-ACP nodes and
networks can be integrated. networks can be integrated.
The remaining sections are non-normative: Section 9 reviews benefits The remaining sections are non-normative: Section 9 reviews benefits
of the ACP (after all the details have been defined), Section 10 of the ACP (after all the details have been defined), Section 10
provides operational recommendations, Appendix A provides additional provides operational recommendations, Appendix A provides additional
explanations and describes additional details or future standard or explanations and describes additional details or future standard or
propriety extensions that were considered not to be appropriate for propriety extensions that were considered not to be appropriate for
standardization in this document but were considered important to standardization in this document but were considered important to
document. There are no dependencies against Appendix A to build a document. There are no dependencies against Appendix A to build a
complete working and interoperable ACP according to this document. complete working and interoperable ACP according to this document.
The ACP provides secure IPv6 connectivity, therefore it can not only The ACP provides secure IPv6 connectivity, therefore it cannot only
be used as the secure connectivity for self-management as required be used as the secure connectivity for self-management as required
for the ACP in [RFC7575], but it can also be used as the secure for the ACP in [RFC7575], but it can also be used as the secure
connectivity for traditional (centralized) management. The ACP can connectivity for traditional (centralized) management. The ACP can
be implemented and operated without any other components of autonomic be implemented and operated without any other components of autonomic
networks, except for the GRASP protocol which it leverages. networks, except for the GRASP protocol which it leverages.
The document "Using Autonomic Control Plane for Stable Connectivity The document "Using Autonomic Control Plane for Stable Connectivity
of Network OAM" [RFC8368] describes how the ACP alone can be used to of Network OAM" [RFC8368] describes how the ACP alone can be used to
provide secure and stable connectivity for autonomic and non- provide secure and stable connectivity for autonomic and non-
autonomic Operations Administration and Management (OAM) autonomic Operations Administration and Management (OAM)
skipping to change at page 9, line 10 skipping to change at page 9, line 12
support in networks and devices, well understood security properties support in networks and devices, well understood security properties
and required scalability. The ACP design is an attempt to produce and required scalability. The ACP design is an attempt to produce
the lowest risk combination of existing technologies and protocols to the lowest risk combination of existing technologies and protocols to
build a widely applicable operational network management solution: build a widely applicable operational network management solution:
RPL was chosen because it requires a smaller routing table footprint RPL was chosen because it requires a smaller routing table footprint
in large networks compared to other routing protocols with an in large networks compared to other routing protocols with an
autonomically configured single area. The deployment experience of autonomically configured single area. The deployment experience of
large scale Internet of Things (IoT) networks serves as the basis for large scale Internet of Things (IoT) networks serves as the basis for
wide deployment experience with RPL. The profile chosen for RPL in wide deployment experience with RPL. The profile chosen for RPL in
the ACP does not not leverage any RPL specific forwarding plane the ACP does not leverage any RPL specific forwarding plane features
features (IPv6 extension headers), making its implementation a pure (IPv6 extension headers), making its implementation a pure control
control plane software requirement. plane software requirement.
GRASP is the only completely novel protocol used in the ACP, and this GRASP is the only completely novel protocol used in the ACP, and this
choice was necessary because there is no existing suitable protocol choice was necessary because there is no existing suitable protocol
to provide the necessary functions to the ACP, so GRASP was developed to provide the necessary functions to the ACP, so GRASP was developed
to fill that gap. to fill that gap.
The ACP design can be applicable to (cpu, memory) constrained devices The ACP design can be applicable to (cpu, memory) constrained devices
and (bitrate, reliability) constrained networks, but this document and (bitrate, reliability) constrained networks, but this document
does not attempt to define the most constrained type of devices or does not attempt to define the most constrained type of devices or
networks to which the ACP is applicable. RPL and DTLS are two networks to which the ACP is applicable. RPL and DTLS are two
protocol choices already making ACP more applicable to constrained protocol choices already making ACP more applicable to constrained
environments. See Appendix A.9 for discussions about how future environments. See Appendix A.9 for discussions about how future
standards or proprietary extensions/variations variations of the ACP standards or proprietary extensions/variations of the ACP could
could better meet different expectations from those on which the better meet different expectations from those on which the current
current design is based. design is based.
2. Acronyms and Terminology (Informative) 2. Acronyms and Terminology (Informative)
[RFC Editor: WG/IETF/IESG review of the terms below asked for [RFC Editor: WG/IETF/IESG review of the terms below asked for
references betwen these terms when they refer to each other. The references between these terms when they refer to each other. The
only option in RFC/XML i found to point to a hanging text acronym only option I could fin RFC/XML to point to a hanging text acronym
definition that also displays the actual term is the format="title" definition that also displays the actual term is the format="title"
version, which leads to references such as '->"ACP domain version, which leads to references such as '->"ACP domain
certificate" ()'. I found no reasonable way to eliminate the certificate" ()'. I found no reasonable way to eliminate the
trailing '()' generated by this type of cross references. Can you trailing '()' generated by this type of cross references. Can you
please take care of removing these artefacts during editing (after please take care of removing these artefacts during editing (after
conversion to nroff ?). Also created ticket to ask for xml2rfc conversion to nroff ?). I also created a ticket to ask for an
enhancement to avoid this in the future: xml2rfc enhancement to avoid this in the future:
https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347. https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.
[RFC Editor: Question: Is it possible to change the first occurences [RFC Editor: Question: Is it possible to change the first occurrences
of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC
format does not seem to offer such a format, but i did not want to format does not seem to offer such a format, but I did not want to
duplicate 50 first references to be duplicate - one reference for duplicate 50 first references - one reference for title mentioning
title mentioning and one for RFC number.] and one for RFC number.]
In the rest of the document we will refer to systems using the ACP as In the rest of the document we will refer to systems using the ACP as
"nodes". Typically such a node is a physical (network equipment) "nodes". Typically such a node is a physical (network equipment)
device, but it can equally be some virtualized system. Therefore, we device, but it can equally be some virtualized system. Therefore, we
do not refer to them as devices unless the context specifically calls do not refer to them as devices unless the context specifically calls
for a physical system. for a physical system.
This document introduces or uses the following terms (sorted This document introduces or uses the following terms (sorted
alphabetically). Terms introduced are explained on first use, so alphabetically). Terms introduced are explained on first use, so
this list is for reference only. this list is for reference only.
skipping to change at page 12, line 46 skipping to change at page 12, line 46
signaling protocol required by the ACP for ACP neighbor discovery. signaling protocol required by the ACP for ACP neighbor discovery.
The ACP also provides the "security and transport substrate" for The ACP also provides the "security and transport substrate" for
the "ACP instance of GRASP". This instance of GRASP runs across the "ACP instance of GRASP". This instance of GRASP runs across
the ACP secure channels to support BRSKI and other NOC/OAM or the ACP secure channels to support BRSKI and other NOC/OAM or
Autonomic Functions. See [I-D.ietf-anima-grasp]. Autonomic Functions. See [I-D.ietf-anima-grasp].
IDevID: An "Initial Device IDentity" X.509 certificate installed by IDevID: An "Initial Device IDentity" X.509 certificate installed by
the vendor on new equipment. Contains information that the vendor on new equipment. Contains information that
establishes the identity of the node in the context of its vendor/ establishes the identity of the node in the context of its vendor/
manufacturer such as device model/type and serial number. See manufacturer such as device model/type and serial number. See
[AR8021]. IDevID can not be used for the ACP because they are not [AR8021]. IDevID cannot be used for the ACP because they are not
provisioned by the owner of the network, so they can not directly provisioned by the owner of the network, so they can not directly
indicate an ACP domain they belong to. indicate an ACP domain they belong to.
in-band (management): The type of management used predominantly in in-band (management): The type of management used predominantly in
IP based networks, not leveraging an ->"out-of-band network" (). IP based networks, not leveraging an ->"out-of-band network" ().
In in-band management, access to the managed equipment depends on In in-band management, access to the managed equipment depends on
the configuration of this equipment itself: interface, addressing, the configuration of this equipment itself: interface, addressing,
forwarding, routing, policy, security, management. This forwarding, routing, policy, security, management. This
dependency makes in-band management fragile because the dependency makes in-band management fragile because the
configuration actions performed may break in-band management configuration actions performed may break in-band management
skipping to change at page 13, line 37 skipping to change at page 13, line 37
native interface: Interfaces existing on a node without native interface: Interfaces existing on a node without
configuration of the already running node. On physical nodes configuration of the already running node. On physical nodes
these are usually physical interfaces. On virtual nodes their these are usually physical interfaces. On virtual nodes their
equivalent. equivalent.
node: A system, e.g., supporting the ACP according to this document. node: A system, e.g., supporting the ACP according to this document.
Can be virtual or physical. Physical nodes are called devices. Can be virtual or physical. Physical nodes are called devices.
Node-ID: The identifier of an ACP node inside that ACP. It is the Node-ID: The identifier of an ACP node inside that ACP. It is the
last 64 (see Section 6.10.3) or 78 bits (see Section 6.10.5) of last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of
the ACP address. the ACP address.
Operational Technology (OT): "https://en.wikipedia.org/wiki/ Operational Technology (OT): "https://en.wikipedia.org/wiki/
Operational_Technology" [1]: "The hardware and software dedicated Operational_Technology" [1]: "The hardware and software dedicated
to detecting or causing changes in physical processes through to detecting or causing changes in physical processes through
direct monitoring and/or control of physical devices such as direct monitoring and/or control of physical devices such as
valves, pumps, etc". OT networks are today in most cases well valves, pumps, etc.". OT networks are today in most cases well
separated from Information Technology (IT) networks. separated from Information Technology (IT) networks.
(virtual) out-of-band network: An out-of-band network is a secondary (virtual) out-of-band network: An out-of-band network is a secondary
network used to manage a primary network. The equipment of the network used to manage a primary network. The equipment of the
primary network is connected to the out-of-band network via primary network is connected to the out-of-band network via
dedicated management ports on the primary network equipment. dedicated management ports on the primary network equipment.
Serial (console) management ports were historically most common, Serial (console) management ports were historically most common,
higher end network equipment now also has ethernet ports dedicated higher end network equipment now also has ethernet ports dedicated
only for management. An out-of-band network provides management only for management. An out-of-band network provides management
access to the primary network independent of the configuration access to the primary network independent of the configuration
skipping to change at page 14, line 46 skipping to change at page 14, line 46
this document to refer to an IDevID. this document to refer to an IDevID.
UDI: "Unique Device Identifier". In the context of this document UDI: "Unique Device Identifier". In the context of this document
unsecured identity information of a node typically consisting of unsecured identity information of a node typically consisting of
at least device model/type and serial number, often in a vendor at least device model/type and serial number, often in a vendor
specific format. See sUDI and LDevID. specific format. See sUDI and LDevID.
ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6
address in the block fc00::/7, defined in [RFC4193]. It is the address in the block fc00::/7, defined in [RFC4193]. It is the
approximate IPv6 counterpart of the IPv4 private address approximate IPv6 counterpart of the IPv4 private address
([RFC1918]). The ULA Global ID prefix are the first 48 bits of a ([RFC1918]). The ULA Global ID prefix are the first 48-bits of a
ULA address. In this document it is abbreviated as "ULA prefix". ULA address. In this document it is abbreviated as "ULA prefix".
(ACP) VRF: The ACP is modeled in this document as a "Virtual Routing (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing
and Forwarding" instance (VRF). This means that it is based on a and Forwarding" instance (VRF). This means that it is based on a
"virtual router" consisting of a separate IPv6 forwarding table to "virtual router" consisting of a separate IPv6 forwarding table to
which the ACP virtual interfaces are attached and an associated which the ACP virtual interfaces are attached and an associated
IPv6 routing table separate from the Data-Plane. Unlike the VRFs IPv6 routing table separate from the Data-Plane. Unlike the VRFs
on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF
does not have any special "core facing" functionality or routing/ does not have any special "core facing" functionality or routing/
mapping protocols shared across multiple VRFs. In vendor products mapping protocols shared across multiple VRFs. In vendor products
a VRF such as the ACP-VRF may also be referred to as a so called a VRF such as the ACP-VRF may also be referred to as a so called
VRF-lite. VRF-lite.
(ACP) Zone: An ACP zone is a set of ACP nodes using the same zone (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone
field value in their ACP address according to Section 6.10.3. field value in their ACP address according to Section 6.10.3.
Zones are a mechanism to support structured addressing of ACP Zones are a mechanism to support structured addressing of ACP
addresses within the same /48 bit ULA prefix. addresses within the same /48-bit ULA prefix.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119],[RFC8174] when, and only when, they appear in all 14 [RFC2119],[RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Use Cases for an Autonomic Control Plane (Informative) 3. Use Cases for an Autonomic Control Plane (Informative)
3.1. An Infrastructure for Autonomic Functions 3.1. An Infrastructure for Autonomic Functions
skipping to change at page 17, line 16 skipping to change at page 17, line 16
autonomic service agents, which could affect Data-Plane autonomic service agents, which could affect Data-Plane
connectivity. connectivity.
The document "Using Autonomic Control Plane for Stable Connectivity The document "Using Autonomic Control Plane for Stable Connectivity
of Network OAM" [RFC8368] explains this use case for the ACP in of Network OAM" [RFC8368] explains this use case for the ACP in
significantly more detail and explains how the ACP can be used in significantly more detail and explains how the ACP can be used in
practical network operations. practical network operations.
4. Requirements (Informative) 4. Requirements (Informative)
The following requirements where identified as the basis for the The following requirements were identified as the basis for the
design of the ACP based on the above use-cases (Section 3). These design of the ACP based on the above use-cases (Section 3). These
requirements are informative for this specification because they requirements are informative for this specification because they
(merely) represent the use-case requirements. The keywords are (merely) represent the use-case requirements. The keywords are
therefore highlighted to be different from RFC2119. The ACP as highlighted ("_") to be different from RFC2119. The ACP as specified
specified in the normative parts of this document is meeting or in the normative parts of this document is meeting or exceeding these
exceeding these use-case requirements: use-case requirements:
ACP1: The ACP _SHOULD_ provide robust connectivity: As far as ACP1: The ACP _SHOULD_ provide robust connectivity: As far as
possible, it should be independent of configured addressing, possible, it should be independent of configured addressing,
configuration and routing. Requirements 2 and 3 build on this configuration and routing. Requirements 2 and 3 build on this
requirement, but also have value on their own. requirement, but also have value on their own.
ACP2: The ACP _MUST_ have a separate address space from the Data- ACP2: The ACP _MUST_ have a separate address space from the Data-
Plane. Reason: traceability, debug-ability, separation from Plane. Reason: traceability, debug-ability, separation from
Data-Plane, infrastructure security (filtering based on known Data-Plane, infrastructure security (filtering based on known
address space). address space).
skipping to change at page 18, line 6 skipping to change at page 18, line 6
ACP5: The ACP _MUST_ provide security: Messages coming through the ACP5: The ACP _MUST_ provide security: Messages coming through the
ACP MUST be authenticated to be from a trusted node, and ACP MUST be authenticated to be from a trusted node, and
SHOULD (very strong SHOULD) be encrypted. SHOULD (very strong SHOULD) be encrypted.
Explanation for ACP4: In a fully autonomic network (AN), newly Explanation for ACP4: In a fully autonomic network (AN), newly
written ASA could potentially all communicate exclusively via GRASP written ASA could potentially all communicate exclusively via GRASP
with each other, and if that was assumed to be the only requirement with each other, and if that was assumed to be the only requirement
against the ACP, it would not need to provide IPv6 layer connectivity against the ACP, it would not need to provide IPv6 layer connectivity
between nodes, but only GRASP connectivity. Nevertheless, because between nodes, but only GRASP connectivity. Nevertheless, because
ACP also intends to support non-AN networks, it it is crucial to ACP also intends to support non-AN networks, it is crucial to support
support IPv6 layer connectivity across the ACP to support any IPv6 layer connectivity across the ACP to support any transport and
transport and application layer protocols. application layer protocols.
The ACP operates hop-by-hop, because this interaction can be built on The ACP operates hop-by-hop, because this interaction can be built on
IPv6 link local addressing, which is autonomic, and has no dependency IPv6 link local addressing, which is autonomic, and has no dependency
on configuration (requirement 1). It may be necessary to have ACP on configuration (requirement 1). It may be necessary to have ACP
connectivity across non-ACP nodes, for example to link ACP nodes over connectivity across non-ACP nodes, for example to link ACP nodes over
the general Internet. This is possible, but introduces a dependency the general Internet. This is possible, but introduces a dependency
against stable/resilient routing over the non-ACP hops (see against stable/resilient routing over the non-ACP hops (see
Section 8.2). Section 8.2).
5. Overview (Informative) 5. Overview (Informative)
skipping to change at page 19, line 45 skipping to change at page 19, line 45
routing problems. routing problems.
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative)
This section describes the components and steps to set up an This section describes the components and steps to set up an
Autonomic Control Plane (ACP), and highlights the key properties Autonomic Control Plane (ACP), and highlights the key properties
which make it "indestructible" against many inadvertent changes to which make it "indestructible" against many inadvertent changes to
the Data-Plane, for example caused by misconfigurations. the Data-Plane, for example caused by misconfigurations.
An ACP node can be a router, switch, controller, NMS host, or any An ACP node can be a router, switch, controller, NMS host, or any
other IP capable node. Initially, it must have its ACP domain other IP capable node. Initially, it must have it's ACP domain
certificate, as well as an (empty) ACP Adjacency Table (described in certificate, as well as an (empty) ACP Adjacency Table (described in
Section 6.2). It then can start to discover ACP neighbors and build Section 6.2). It then can start to discover ACP neighbors and build
the ACP. This is described step by step in the following sections: the ACP. This is described step by step in the following sections:
6.1. ACP Domain, Certificate and Network 6.1. ACP Domain, Certificate and Network
The ACP relies on group security. An ACP domain is a group of nodes The ACP relies on group security. An ACP domain is a group of nodes
that trust each other to participate in ACP operations. To establish that trust each other to participate in ACP operations. To establish
trust, each ACP member requires keying material: An ACP node MUST trust, each ACP member requires keying material: An ACP node MUST
have a certificate (LDevID) and a Trust Anchor (TA) consisting of a have a certificate (LDevID) and a Trust Anchor (TA) consisting of a
skipping to change at page 20, line 50 skipping to change at page 20, line 50
Certificate" as the certificate used in an autonomic domain. The ACP Certificate" as the certificate used in an autonomic domain. The ACP
domain certificate is that domain certificate when ACP nodes are domain certificate is that domain certificate when ACP nodes are
(fully) autonomic nodes. Finally, this document uses the term ACP (fully) autonomic nodes. Finally, this document uses the term ACP
network to refer to the network created by active ACP nodes in an ACP network to refer to the network created by active ACP nodes in an ACP
domain. The ACP network itself can extend beyond ACP nodes through domain. The ACP network itself can extend beyond ACP nodes through
the mechanisms described in Section 8.1. the mechanisms described in Section 8.1.
The ACP domain certificate SHOULD be used for any authentication The ACP domain certificate SHOULD be used for any authentication
between nodes with ACP domain certificates (ACP nodes and NOC nodes) between nodes with ACP domain certificates (ACP nodes and NOC nodes)
where the required condition is ACP domain membership, such as ACP where the required condition is ACP domain membership, such as ACP
node to NOC/OAM end-to-en security and ASA to ASA end-to-end node to NOC/OAM end-to-end security and ASA to ASA end-to-end
security. Section 6.1.2 defines this "ACP domain membership check". security. Section 6.1.2 defines this "ACP domain membership check".
The uses of this check that are standardized in this document are for The uses of this check that are standardized in this document are for
the establishment of ACP secure channels (Section 6.6) and for ACP the establishment of ACP secure channels (Section 6.6) and for ACP
GRASP (Section 6.8.2). GRASP (Section 6.8.2).
6.1.1. Certificate Domain Information Field 6.1.1. Certificate Domain Information Field
Information about the domain MUST be encoded in the domain Information about the domain MUST be encoded in the domain
certificate in a subjectAltName / rfc822Name field according to the certificate in a subjectAltName / rfc822Name field according to the
following ABNF definition ([RFC5234]): following ABNF definition ([RFC5234]):
[RFC Editor: Please substitute SELF in all occurences of rfcSELF in [RFC Editor: Please substitute SELF in all occurrences of rfcSELF in
this document with the RFC number assigned to this document and this document with the RFC number assigned to this document and
remove this comment line] remove this comment line]
domain-information = local-part "@" acp-domain-name domain-information = local-part "@" acp-domain-name
local-part = key [ "." local-info ] local-part = key [ "." local-info ]
key = "rfcSELF" key = "rfcSELF"
local-info = [ acp-address ] [ "+" rsub extensions ] local-info = [ acp-address ] [ "+" rsub extensions ]
acp-address = 32hex-dig | 0 acp-address = 32hex-dig | 0
hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5 rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5
skipping to change at page 24, line 6 skipping to change at page 24, line 6
field. field.
6.1.2. ACP domain membership check 6.1.2. ACP domain membership check
The following points constitute the ACP domain membership check of a The following points constitute the ACP domain membership check of a
candidate peer certificate, independent of the protocol used: candidate peer certificate, independent of the protocol used:
1: The peer certificate is valid (lifetime). 1: The peer certificate is valid (lifetime).
2: The peer has proved ownership of the private key associated with 2: The peer has proved ownership of the private key associated with
the certifictes public key. the certificate's public key.
3: The peer's certificate is signed by one of the trust anchors 3: The peer's certificate is signed by one of the trust anchors
associated with the ACP domain certificate. associated with the ACP domain certificate.
4: If the node certificate indicates a Certificate Revocation List 4: If the node certificate indicates a Certificate Revocation List
(CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or
Online Certificate Status Protocol (OCSP) responder ([RFC5280], Online Certificate Status Protocol (OCSP) responder ([RFC5280],
section 4.2.2.1), then the peer's certificate must be valid section 4.2.2.1), then the peer's certificate must be valid
according to those criteria: An OCSP check for the peer's according to those criteria: An OCSP check for the peer's
certificate across the ACP must succeed or the peer certificate certificate across the ACP must succeed or the peer certificate
skipping to change at page 24, line 34 skipping to change at page 24, line 34
Only when checking a candidate peer's certificate for the purpose of Only when checking a candidate peer's certificate for the purpose of
establishing an ACP secure channel, one additional check is establishing an ACP secure channel, one additional check is
performed: performed:
6: The candidate peer certificate's ACP domain information field 6: The candidate peer certificate's ACP domain information field
has a non-empty acp-address field (either 32hex-dig or 0, has a non-empty acp-address field (either 32hex-dig or 0,
according to Figure 2). according to Figure 2).
Rule 6: for the establishment of ACP secure channels ensures that Rule 6: for the establishment of ACP secure channels ensures that
they will only be built between nodes which indicate through the acp- they will only be built between nodes which indicate through the acp-
address in their ACP domain certificate indicate ability and address in their ACP domain certificate the ability and permission by
permission by the Registrar to participate in ACP secure-channels. the Registrar to participate in ACP secure-channels.
Nodes without an empty acp-adress field can only use it for non-ACP-
secure channel authentication purposes. The special value 0 in an Nodes with an empty acp-address field can only use their ACP domain
ACP certificates acp-address field is used for nodes that can and certificate for non-ACP-secure channel authentication purposes.
should determine their ACP address through other mechanisms than
learning it through their ACP domain certificate, but which are still The special value 0 in an ACP certificates acp-address field is used
permitted to establish ACP secure channels. Mechanisms for those for nodes that can and should determine their ACP address through
nodes to determine their ACP address are outside the scope of this other mechanisms than learning it through their ACP domain
specification. certificate. These ACP nodes are permitted to establish ACP secure
channels. Mechanisms for those nodes to determine their ACP address
are outside the scope of this specification.
6.1.3. Certificate Maintenance 6.1.3. Certificate Maintenance
ACP nodes MUST support certificate renewal via EST ("Enrollment over ACP nodes MUST support certificate renewal via EST ("Enrollment over
Secure Transport", see [RFC7030]) and MAY support other mechanisms. Secure Transport", see [RFC7030]) and MAY support other mechanisms.
An ACP network MUST have at least one ACP node supporting EST server An ACP network MUST have at least one ACP node supporting EST server
functionality across the ACP so that EST renewal is useable. functionality across the ACP so that EST renewal is useable.
ACP nodes SHOULD be able to remember the EST server from which they ACP nodes SHOULD be able to remember the EST server from which they
last renewed their ACP domain certificate and SHOULD provide the last renewed their ACP domain certificate and SHOULD provide the
skipping to change at page 26, line 11 skipping to change at page 26, line 11
[RFC7030] compliant EST server because "est" is an [RFC6335] [RFC7030] compliant EST server because "est" is an [RFC6335]
registered service name for [RFC7030]. Objective-value MUST be registered service name for [RFC7030]. Objective-value MUST be
ignored if present. Backward compatible extensions to [RFC7030] MAY ignored if present. Backward compatible extensions to [RFC7030] MAY
be indicated through objective-value. Non [RFC7030] compatible be indicated through objective-value. Non [RFC7030] compatible
certificate renewal options MUST use a different objective-name. certificate renewal options MUST use a different objective-name.
The M_FLOOD message MUST be sent periodically. The default SHOULD be The M_FLOOD message MUST be sent periodically. The default SHOULD be
60 seconds, the value SHOULD be operator configurable but SHOULD be 60 seconds, the value SHOULD be operator configurable but SHOULD be
not smaller than 60 seconds. The frequency of sending MUST be such not smaller than 60 seconds. The frequency of sending MUST be such
that the aggregate amount of periodic M_FLOODs from all flooding that the aggregate amount of periodic M_FLOODs from all flooding
sources causes only negligible traffic across the ACP. The time-to- sources cause only negligible traffic across the ACP. The time-to-
live (ttl) parameter SHOULD be 3.5 times the period so that up to live (ttl) parameter SHOULD be 3.5 times the period so that up to
three consecutive messages can be dropped before considering an three consecutive messages can be dropped before considering an
announcement expired. In the example above, the ttl is 210000 msec, announcement expired. In the example above, the ttl is 210000 msec,
3.5 times 60 seconds. When a service announcer using these 3.5 times 60 seconds. When a service announcer using these
parameters unexpectedly dies immediately after sending the M_FLOOD, parameters unexpectedly dies immediately after sending the M_FLOOD,
receivers would consider it expired 210 seconds later. When a receivers would consider it expired 210 seconds later. When a
receiver tries to connect to this dead service before this timeout, receiver tries to connect to this dead service before this timeout,
it will experience a failing connection and use that as an indication it will experience a failing connection and use that as an indication
that the service is dead and select another instance of the same that the service is dead and select another instance of the same
service instead. service instead.
skipping to change at page 29, line 28 skipping to change at page 29, line 28
error diagnostics. error diagnostics.
This type of failure can happen during setup/refresh of a secure ACP This type of failure can happen during setup/refresh of a secure ACP
channel connections or any other use of the ACP domain certificate, channel connections or any other use of the ACP domain certificate,
such as for the TLS connection to an EST server for the renewal of such as for the TLS connection to an EST server for the renewal of
the ACP domain certificate. the ACP domain certificate.
Example reasons for failing certificates that the ACP node can only Example reasons for failing certificates that the ACP node can only
discover through connection failure are that the domain certificate discover through connection failure are that the domain certificate
or any of its signing certificates could have been revoked or may or any of its signing certificates could have been revoked or may
have expired, but the ACP node can not self-diagnose this condition have expired, but the ACP node cannot self-diagnose this condition
directly. Revocation information or clock synchronization may only directly. Revocation information or clock synchronization may only
be available across the ACP, but the ACP node can not build ACP be available across the ACP, but the ACP node cannot build ACP secure
secure channels because ACP peers reject the ACP node's domain channels because ACP peers reject the ACP node's domain certificate.
certificate.
ACP nodes SHOULD support the option to determines whether its ACP ACP nodes SHOULD support the option to determines whether its ACP
certificate is failing, and when it does, put itself into the role of certificate is failing, and when it does, put itself into the role of
a re-enrolling candidate ACP node as explained above a re-enrolling candidate ACP node as explained above
(Section 6.1.3.5). (Section 6.1.3.5).
6.2. ACP Adjacency Table 6.2. ACP Adjacency Table
To know to which nodes to establish an ACP channel, every ACP node To know to which nodes to establish an ACP channel, every ACP node
maintains an adjacency table. The adjacency table contains maintains an adjacency table. The adjacency table contains
skipping to change at page 35, line 38 skipping to change at page 35, line 38
6.6. Candidate ACP Neighbor verification 6.6. Candidate ACP Neighbor verification
Independent of the security association protocol chosen, candidate Independent of the security association protocol chosen, candidate
ACP neighbors need to be authenticated based on their domain ACP neighbors need to be authenticated based on their domain
certificate. This implies that any secure channel protocol MUST certificate. This implies that any secure channel protocol MUST
support certificate based authentication that can support the ACP support certificate based authentication that can support the ACP
domain membership check as defined in Section 6.1.2. If it fails, domain membership check as defined in Section 6.1.2. If it fails,
the connection attempt is aborted and an error logged. Attempts to the connection attempt is aborted and an error logged. Attempts to
reconnect MUST be throttled. The RECOMMENDED default is exponential reconnect MUST be throttled. The RECOMMENDED default is exponential
backoff with a a minimum delay of 10 seconds and a maximum delay of backoff with a minimum delay of 10 seconds and a maximum delay of 640
640 seconds. seconds.
6.7. Security Association protocols 6.7. Security Association protocols
The following sections define the security association protocols that The following sections define the security association protocols that
we consider to be important and feasible to specify in this document: we consider to be important and feasible to specify in this document:
6.7.1. ACP via IKEv2 6.7.1. ACP via IKEv2
An ACP node announces its ability to support IKEv2 as the ACP secure An ACP node announces its ability to support IKEv2 as the ACP secure
channel protocol in GRASP as "IKEv2". channel protocol in GRASP as "IKEv2".
skipping to change at page 37, line 37 skipping to change at page 37, line 37
for any transport application relying solely on DTLS. for any transport application relying solely on DTLS.
6.7.3. ACP Secure Channel Requirements 6.7.3. ACP Secure Channel Requirements
As explained in the beginning of Section 6.5, there is no single As explained in the beginning of Section 6.5, there is no single
secure channel mechanism mandated for all ACP nodes. Instead, this secure channel mechanism mandated for all ACP nodes. Instead, this
section defines two ACP profiles (baseline and constrained) for ACP section defines two ACP profiles (baseline and constrained) for ACP
nodes that do introduce such requirements. nodes that do introduce such requirements.
A baseline ACP node MUST support IPsec natively and MAY support IPsec A baseline ACP node MUST support IPsec natively and MAY support IPsec
via GRE. A constrained ACP node that can not support IPsec MUST via GRE. A constrained ACP node that cannot support IPsec MUST
support DTLS. An ACP node connecting an area of constrained ACP support DTLS. An ACP node connecting an area of constrained ACP
nodes with an area of baseline ACP nodes MUST therefore support IPsec nodes with an area of baseline ACP nodes MUST therefore support IPsec
and DTLS and supports threefore the baseline and constrained profile. and DTLS and supports therefore the baseline and constrained profile.
ACP nodes need to specify in documentation the set of secure ACP ACP nodes need to specify in documentation the set of secure ACP
mechanisms they support and should declare which profile they support mechanisms they support and should declare which profile they support
according to above requirements. according to above requirements.
An ACP secure channel MUST immediately be terminated when the An ACP secure channel MUST immediately be terminated when the
lifetime of any certificate in the chain used to authenticate the lifetime of any certificate in the chain used to authenticate the
neighbor expires or becomes revoked. Note that this is not standard neighbor expires or becomes revoked. Note that this is not standard
behavior in secure channel protocols such as IPsec because the behavior in secure channel protocols such as IPsec because the
certificate authentication only influences the setup of the secure certificate authentication only influences the setup of the secure
skipping to change at page 38, line 47 skipping to change at page 38, line 47
interface because of new ACP secure channels or loss thereof, the ACP interface because of new ACP secure channels or loss thereof, the ACP
needs to indicate this to the ACP instance of GRASP. The ACP exists needs to indicate this to the ACP instance of GRASP. The ACP exists
also in the absence of any active ACP neighbors. It is created when 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 the node has a domain certificate, and continues to exist even if all
of its neighbors cease operation. of its neighbors cease operation.
In this case ASAs using GRASP running on the same node would still In this case ASAs using GRASP running on the same node would still
need to be able to discover each other's objectives. When the ACP need to be able to discover each other's objectives. When the ACP
does not exist, ASAs leveraging the ACP instance of GRASP via APIs does not exist, ASAs leveraging the ACP instance of GRASP via APIs
MUST still be able to operate, and MUST be able to understand that MUST still be able to operate, and MUST be able to understand that
there is no ACP and that therefore the ACP instance of GRASP can not there is no ACP and that therefore the ACP instance of GRASP cannot
operate. operate.
The way ACP acts as the security and transport substrate for GRASP is The way ACP acts as the security and transport substrate for GRASP is
visualized in the following picture: visualized in the following picture:
..............................ACP.............................. ..............................ACP..............................
. . . .
. /-GRASP-flooding-\ ACP GRASP instance . . /-GRASP-flooding-\ ACP GRASP instance .
. / \ A . / \ A
. GRASP GRASP GRASP C . GRASP GRASP GRASP C
skipping to change at page 41, line 22 skipping to change at page 41, line 22
application level proxy. This of course requires that the application level proxy. This of course requires that the
compromised ACP node understand the semantics of the GRASP compromised ACP node understand the semantics of the GRASP
negotiation to an extent that allows it to proxy it without being negotiation to an extent that allows it to proxy it without being
detected, but in an ACP environment this is quite likely public detected, but in an ACP environment this is quite likely public
knowledge or even standardized. knowledge or even standardized.
The GRASP TLS connections are run the same as any other ACP traffic The GRASP TLS connections are run the same as any other ACP traffic
through the ACP secure channels. This leads to double through the ACP secure channels. This leads to double
authentication/encryption, which has the following benefits: authentication/encryption, which has the following benefits:
o Secure channel methods such as IPsec may provide protecation o Secure channel methods such as IPsec may provide protection
against additional attacks from such as reset-attacks. against additional attacks, for example reset-attacks.
o The secure channel method may leverage hardware acceleration and o The secure channel method may leverage hardware acceleration and
there may be little or no gain in eliminating it. there may be little or no gain in eliminating it.
o There is no different security model for ACP GRASP from other ACP o There is no different security model for ACP GRASP from other ACP
traffic. Instead, there is just another layer of protection traffic. Instead, there is just another layer of protection
against certain attacks from the inside which is important due to against certain attacks from the inside which is important due to
the role of GRASP in the ACP. the role of GRASP in the ACP.
6.9. Context Separation 6.9. Context Separation
skipping to change at page 43, line 44 skipping to change at page 43, line 44
The Base ULA addressing scheme for ACP nodes has the following The Base ULA addressing scheme for ACP nodes has the following
format: format:
8 40 2 78 8 40 2 78
+--+-------------------------+------+------------------------------+ +--+-------------------------+------+------------------------------+
|fd| hash(routing-subdomain) | Type | (sub-scheme) | |fd| hash(routing-subdomain) | Type | (sub-scheme) |
+--+-------------------------+------+------------------------------+ +--+-------------------------+------+------------------------------+
Figure 8: ACP Addressing Base Scheme Figure 8: ACP Addressing Base Scheme
The first 48 bits follow the ULA scheme, as defined in [RFC4193], to The first 48-bits follow the ULA scheme, as defined in [RFC4193], to
which a type field is added: which a type field is added:
o "fd" identifies a locally defined ULA address. o "fd" identifies a locally defined ULA address.
o The 40 bits ULA "global ID" (term from [RFC4193]) for ACP o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP
addresses carried in the domain information field of domain addresses carried in the domain information field of domain
certificates are the first 40 bits of the SHA256 hash of the certificates are the first 40-bits of the SHA256 hash of the
routing subdomain from the same domain information field. In the routing subdomain from the same domain information field. In the
example of Section 6.1.1, the routing subdomain is example of Section 6.1.1, the routing subdomain is
"area51.research.acp.example.com" and the 40 bits ULA "global ID" "area51.research.acp.example.com" and the 40-bits ULA "global ID"
89b714f3db. 89b714f3db.
o To allow for extensibility, the fact that the ULA "global ID" is a o To allow for extensibility, the fact that the ULA "global ID" is a
hash of the routing subdomain SHOULD NOT be assumed by any ACP hash of the routing subdomain SHOULD NOT be assumed by any ACP
node during normal operations. The hash function is only executed node during normal operations. The hash function is only executed
during the creation of the certificate. If BRSKI is used then the during the creation of the certificate. If BRSKI is used then the
BRSKI registrar will create the domain information field in BRSKI registrar will create the domain information field in
response to the EST Certificate Signing Request (CSR) Attribute response to the EST Certificate Signing Request (CSR) Attribute
Request message by the pledge. Request message by the pledge.
skipping to change at page 45, line 7 skipping to change at page 45, line 7
o Zone-ID: If set to all zero bits: The Node-ID bits are used as an o Zone-ID: If set to all zero bits: The Node-ID bits are used as an
identifier (as opposed to a locator). This results in a non- identifier (as opposed to a locator). This results in a non-
hierarchical, flat addressing scheme. Any other value indicates a hierarchical, flat addressing scheme. Any other value indicates a
zone. See Section 6.10.3.1 on how this field is used in detail. zone. See Section 6.10.3.1 on how this field is used in detail.
o Z: MUST be 0. o Z: MUST be 0.
o Node-ID: A unique value for each node. o Node-ID: A unique value for each node.
The 64 bit Node-ID is derived and composed as follows: The 64-bit Node-ID is derived and composed as follows:
o Registrar-ID (48 bit): A number unique inside the domain that o Registrar-ID (48-bit): A number unique inside the domain that
identifies the ACP registrar which assigned the Node-ID to the identifies the ACP registrar which assigned the Node-ID to the
node. A MAC address of the ACP registrar can be used for this node. A MAC address of the ACP registrar can be used for this
purpose. purpose.
o Node-Number: A number which is unique for a given ACP registrar, o Node-Number: A number which is unique for a given ACP registrar,
to identify the node. This can be a sequentially assigned number. to identify the node. This can be a sequentially assigned number.
o V (1 bit): Virtualization bit: 0: Indicates the ACP itself ("ACP o V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP
node base system); 1: Indicates the optional "host" context on the node base system); 1: Indicates the optional "host" context on the
ACP node (see below). ACP node (see below).
In the ACP Zone Addressing Sub-Scheme, the ACP address in the In the ACP Zone Addressing Sub-Scheme, the ACP address in the
certificate has Zone-ID and V fields as all zero bits. The ACP certificate has Zone-ID and V fields as all zero bits. The ACP
address set includes addresses with any Zone-ID value and any V address set includes addresses with any Zone-ID value and any V
value. value.
The "Node-ID" itself is unique in a domain (i.e., the Zone-ID is not The "Node-ID" itself is unique in a domain (i.e., the Zone-ID is not
required for uniqueness). Therefore, a node can be addressed either required for uniqueness). Therefore, a node can be addressed either
skipping to change at page 46, line 18 skipping to change at page 46, line 18
addressing scheme. addressing scheme.
Zone-ID = 0 is the default addressing scheme in an ACP domain. Every Zone-ID = 0 is the default addressing scheme in an ACP domain. Every
ACP node with a Zone Addressing Sub-Scheme address MUST respond to ACP node with a Zone Addressing Sub-Scheme address MUST respond to
its ACP address with Zone-ID = 0. Used on its own this leads to a its ACP address with Zone-ID = 0. Used on its own this leads to a
non-hierarchical address scheme, which is suitable for networks up to non-hierarchical address scheme, which is suitable for networks up to
a certain size. Zone-ID = 0 addresses act as identifiers for the a certain size. Zone-ID = 0 addresses act as identifiers for the
nodes, and aggregation of these address in the ACP routing table is nodes, and aggregation of these address in the ACP routing table is
not possible. not possible.
If aggregation is required, the 13 bit Zone-ID value allows for up to If aggregation is required, the 13-bit Zone-ID value allows for up to
8191 zones. The allocation of Zone-ID's may either happen 8191 zones. The allocation of Zone-ID's may either happen
automatically through a to-be-defined algorithm; or it could be automatically through a to-be-defined algorithm; or it could be
configured and maintained explicitly. configured and maintained explicitly.
If a node learns (see Appendix A.10.1) that it is part of a zone, it If a node learns (see Appendix A.10.1) that it is part of a zone, it
MUST also respond to its ACP address with that Zone-ID. In this case MUST also respond to its ACP address with that Zone-ID. In this case
the ACP Loopback is configured with two ACP addresses: One for Zone- the ACP Loopback is configured with two ACP addresses: One for Zone-
ID = 0 and one for the assigned Zone-ID. This method allows for a ID = 0 and one for the assigned Zone-ID. This method allows for a
smooth transition between a flat addressing scheme and a hierarchical smooth transition between a flat addressing scheme and a hierarchical
one. one.
A node knowing it is in a zone MUST also use that Zone-ID != 0 A node knowing it is in a zone MUST also use that Zone-ID != 0
address in GRASP locator fields. This eliminates the use of the address in GRASP locator fields. This eliminates the use of the
identifier address (Zone-ID = 0) in forwarding and the need for identifier address (Zone-ID = 0) in forwarding and the need for
network wide reachability of those non-aggregatable identifier network wide reachability of those non-aggregable identifier
addresses. Zone-ID != 0 addresses are assumed to be aggregatable in addresses. Zone-ID != 0 addresses are assumed to be aggregable in
routing/forwarding based on how they are allocated in the ACP routing/forwarding based on how they are allocated in the ACP
topology. topology.
Note: The Zone-ID is one method to introduce structure or hierarchy Note: The Zone-ID is one method to introduce structure or hierarchy
into the ACP. Another way is the use of the routing subdomain field into the ACP. Another way is the use of the routing subdomain field
in the ACP that leads to multiple /48 Global IDs within an ACP in the ACP that leads to multiple /48 Global IDs within an ACP
domain. domain.
Note: Zones and Zone-ID as defined here are not related to [RFC4007] Note: Zones and Zone-ID as defined here are not related to [RFC4007]
zones or zone_id. ACP zone addresses are not scoped (reachable only zones or zone_id. ACP zone addresses are not scoped (reachable only
skipping to change at page 47, line 46 skipping to change at page 47, line 46
addressing sub-schemes without requiring one more bit in the base addressing sub-schemes without requiring one more bit in the base
scheme and therefore allowing for the Vlong scheme (described below) scheme and therefore allowing for the Vlong scheme (described below)
to have one more bit available. to have one more bit available.
Manual addressing sub-scheme addresses SHOULD NOT be used in ACP Manual addressing sub-scheme addresses SHOULD NOT be used in ACP
domain certificates. Any node capable to build ACP secure channels domain certificates. Any node capable to build ACP secure channels
and permitted by Registrar policy to participate in building ACP and permitted by Registrar policy to participate in building ACP
secure channels SHOULD receive an ACP address (prefix) from one of secure channels SHOULD receive an ACP address (prefix) from one of
the other ACP addressing sub-schemes. Nodes not capable (or the other ACP addressing sub-schemes. Nodes not capable (or
permitted) to participate in ACP secure channels can connect to the permitted) to participate in ACP secure channels can connect to the
ACP via ACP connect interfaces of ACP edge nodes (see xref ACP via ACP connect interfaces of ACP edge nodes (see Section 8.1),
target="ACPconnect"/>), without setting up an ACP secure channel. without setting up an ACP secure channel. Their ACP domain
Their ACP domain certificate MUST include an empty acp-address to certificate MUST include an empty acp-address to indicate that their
indicate that their ACP domain certificate is only usable for non- ACP domain certificate is only usable for non- ACP secure channel
ACP secure channel authentication, such as end-to-end transport authentication, such as end-to-end transport connections across the
connections across the ACP or Data-Plane. ACP or Data-Plane.
Address management of ACP connect subnets is done using traditional Address management of ACP connect subnets is done using traditional
assignment methods and existing IPv6 protocols. See Section 8.1.3 assignment methods and existing IPv6 protocols. See Section 8.1.3
for details. for details.
6.10.5. ACP Vlong Addressing Sub-Scheme 6.10.5. ACP Vlong Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 01b (one) in The sub-scheme defined here is defined by the Type value 01b (one) in
the base scheme. the base scheme.
skipping to change at page 48, line 38 skipping to change at page 48, line 38
different virtualized addresses within a node, which could be used to different virtualized addresses within a node, which could be used to
address individual software components in an ACP node. address individual software components in an ACP node.
The fields are the same as in the Zone-ID sub-scheme with the The fields are the same as in the Zone-ID sub-scheme with the
following refinements: following refinements:
o V: Virtualization bit: Values 0 and 1 are assigned in the same way o V: Virtualization bit: Values 0 and 1 are assigned in the same way
as in the Zone-ID sub-scheme. as in the Zone-ID sub-scheme.
o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is
reduced to 46 bits. This still permits the use of the MAC address reduced to 46-bits. This still permits the use of the MAC address
of an ACP registrar by removing the V and U bits from the 48 bits of an ACP registrar by removing the V and U bits from the 48-bits
of a MAC address (those two bits are never unique, so they cannot of a MAC address (those two bits are never unique, so they cannot
be used to distinguish MAC addresses). be used to distinguish MAC addresses).
o If the first bit of the "Node-Number" is "1", then the Node-Number o If the first bit of the "Node-Number" is "1", then the Node-Number
is 16 bit long and the V field is 16 bit long. Otherwise the is 16-bit long and the V field is 16-bit long. Otherwise the
Node-Number is 24 bit long and the V field is 8 bit long. Node-Number is 24-bit long and the V field is 8-bit long.
"0" bit Node-Numbers are intended to be used for "general purpose" "0" bit Node-Numbers are intended to be used for "general purpose"
ACP nodes that would potentially have a limited number (< 256) of ACP nodes that would potentially have a limited number (< 256) of
clients (ASA/Autonomic Functions or legacy services) of the ACP that clients (ASA/Autonomic Functions or legacy services) of the ACP that
require separate V(irtual) addresses. "1" bit Node-Numbers are require separate V(irtual) addresses. "1" bit Node-Numbers are
intended for ACP nodes that are ACP edge nodes (see Section 8.1.1) or intended for ACP nodes that are ACP edge nodes (see Section 8.1.1) or
that have a large number of clients requiring separate V(irtual) that have a large number of clients requiring separate V(irtual)
addresses. For example large SDN controllers with container modular addresses. For example large SDN controllers with container modular
software architecture (see Section 8.1.2). software architecture (see Section 8.1.2).
skipping to change at page 49, line 22 skipping to change at page 49, line 22
6.10.6. Other ACP Addressing Sub-Schemes 6.10.6. Other ACP Addressing Sub-Schemes
Before further addressing sub-schemes are defined, experience with Before further addressing sub-schemes are defined, experience with
the schemes defined here should be collected. The schemes defined in the schemes defined here should be collected. The schemes defined in
this document have been devised to allow hopefully sufficiently this document have been devised to allow hopefully sufficiently
flexible setup of ACPs for a variety of situation. These reasons flexible setup of ACPs for a variety of situation. These reasons
also lead to the fairly liberal use of address space: The Zone also lead to the fairly liberal use of address space: The Zone
Addressing Sub-Scheme is intended to enable optimized routing in Addressing Sub-Scheme is intended to enable optimized routing in
large networks by reserving bits for Zone-ID's. The Vlong addressing large networks by reserving bits for Zone-ID's. The Vlong addressing
sub-scheme enables the allocation of 8/16 bit of addresses inside sub-scheme enables the allocation of 8/16-bit of addresses inside
individual ACP nodes. Both address spaces allow distributed, individual ACP nodes. Both address spaces allow distributed,
uncoordinated allocation of node addresses by reserving bits for the uncoordinated allocation of node addresses by reserving bits for the
registrar-ID field in the address. registrar-ID field in the address.
IANA is asked need to assign a new "type" for each new addressing IANA is asked need to assign a new "type" for each new addressing
sub-scheme. With the current allocations, only 2 more schemes are sub-scheme. With the current allocations, only 2 more schemes are
possible, so the last addressing scheme MUST provide further possible, so the last addressing scheme MUST provide further
extensions (e.g., by reserving bits from it for further extensions). extensions (e.g., by reserving bits from it for further extensions).
6.10.7. ACP Registrars 6.10.7. ACP Registrars
skipping to change at page 50, line 31 skipping to change at page 50, line 31
6.10.7.2. Unique Address/Prefix allocation 6.10.7.2. Unique Address/Prefix allocation
ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes
via the ACP domain information field that would collide with the ACP via the ACP domain information field that would collide with the ACP
address prefixes of other ACP nodes in the same ACP domain. This address prefixes of other ACP nodes in the same ACP domain. This
includes both prefixes allocated by the same ACP registrar to includes both prefixes allocated by the same ACP registrar to
different ACP nodes as well as prefixes allocated by other ACP different ACP nodes as well as prefixes allocated by other ACP
registrars for the same ACP domain. registrars for the same ACP domain.
For this purpose, an ACP registrar MUST have one or more unique 46 For this purpose, an ACP registrar MUST have one or more unique
bit identifiers called Registrar-IDs used to allocate ACP address 46-bit identifiers called Registrar-IDs used to allocate ACP address
prefixes. The lower 46 bits of a EUI-48 MAC addresses are globally prefixes. The lower 46-bits of a EUI-48 MAC addresses are globally
unique 46 bit identifiers, so ACP registrars with known unique EUI-48 unique 46 bit identifiers, so ACP registrars with known unique EUI-48
MAC addresses can use these as Registrar-IDs. Registrar-IDs do not MAC addresses can use these as Registrar-IDs. Registrar-IDs do not
need to be globally unique but only unique across the set of ACP need to be globally unique but only unique across the set of ACP
registrars for an ACP domain, so other means to assign unique registrars for an ACP domain, so other means to assign unique
Registrar-IDs to ACP registrars can be used, such as configuration on Registrar-IDs to ACP registrars can be used, such as configuration on
the ACP registrars. the ACP registrars.
When the candidate ACP device (called Pledge in BRSKI) is to be When the candidate ACP device (called Pledge in BRSKI) is to be
enrolled into an ACP domain, the ACP registrar needs to allocate a enrolled into an ACP domain, the ACP registrar needs to allocate a
unique ACP address to the node and ensure that the ACP certificate unique ACP address to the node and ensure that the ACP certificate
skipping to change at page 53, line 27 skipping to change at page 53, line 27
The key limitation of the chosen profile is that it is designed to The key limitation of the chosen profile is that it is designed to
not require any Data-Plane artifacts (such as [RFC6553]). While the not require any Data-Plane artifacts (such as [RFC6553]). While the
senders/receivers of ACP packets can be legacy NOC devices connected senders/receivers of ACP packets can be legacy NOC devices connected
via ACP connect (see Section 8.1.1 to the ACP, their connectivity can via ACP connect (see Section 8.1.1 to the ACP, their connectivity can
be handled as non-RPL-aware leafs (or "Internet") according to the be handled as non-RPL-aware leafs (or "Internet") according to the
Data-Plane architecture explained in [I-D.ietf-roll-useofrplinfo]. Data-Plane architecture explained in [I-D.ietf-roll-useofrplinfo].
This non-artifact profile is largely driven by the desire to avoid This non-artifact profile is largely driven by the desire to avoid
introducing the required Hop-by-Hop headers into the ACP forwarding introducing the required Hop-by-Hop headers into the ACP forwarding
plane, especially to support devices with silicon forwarding planes plane, especially to support devices with silicon forwarding planes
that can not support insertion/removal of these headers in silicon. that cannot support insertion/removal of these headers in silicon.
In this profile choice, RPL has no Data-Plane artifacts. A simple In this profile choice, RPL has no Data-Plane artifacts. A simple
destination prefix based upon the routing table is used. A destination prefix based upon the routing table is used. A
consequence of supporting only a single instanceID that is containing consequence of supporting only a single instanceID that is containing
one Destination Oriented Directed Acyclic Graph (DODAG), the ACP will one Destination Oriented Directed Acyclic Graph (DODAG), the ACP will
only accommodate only a single class of routing table and cannot only accommodate only a single class of routing table and cannot
create optimized routing paths to accomplish latency or energy goals. create optimized routing paths to accomplish latency or energy goals.
Consider a network that has multiple NOCs in different locations. Consider a network that has multiple NOCs in different locations.
Only one NOC will become the DODAG root. Other NOCs will have to Only one NOC will become the DODAG root. Other NOCs will have to
skipping to change at page 54, line 14 skipping to change at page 54, line 14
according to Section 6.11.1.7, loops should be exceedingly rare according to Section 6.11.1.7, loops should be exceedingly rare
though. though.
There are a variety of mechanisms possible in RPL to further avoid There are a variety of mechanisms possible in RPL to further avoid
temporary loops: DODAG Information Objects (DIOs) SHOULD be sent temporary loops: DODAG Information Objects (DIOs) SHOULD be sent
2...3 times to inform children when losing the last parent. The 2...3 times to inform children when losing the last parent. The
technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be
favored over that in section 8.2.2.5., (Poisoning) because it allows favored over that in section 8.2.2.5., (Poisoning) because it allows
local connectivity. Nodes SHOULD select more than one parent, at local connectivity. Nodes SHOULD select more than one parent, at
least 3 if possible, and send Destination Advertisement Objects least 3 if possible, and send Destination Advertisement Objects
(DAO)s to all of then in parallel. (DAO)s to all of them in parallel.
Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer
Detection (which can function as a replacement for a Low-power and Detection (which can function as a replacement for a Low-power and
Lossy Networks' (LLN's) Expected Transmission Count (ETX). A failure Lossy Networks' (LLN's) Expected Transmission Count (ETX). A failure
of an ACP tunnel should signal the RPL control plane to pick a of an ACP tunnel should signal the RPL control plane to pick a
different parent. different parent.
6.11.1.2. RPL Instances 6.11.1.2. RPL Instances
Single RPL instance. Default RPLInstanceID = 0. Single RPL instance. Default RPLInstanceID = 0.
skipping to change at page 57, line 15 skipping to change at page 57, line 15
software-only implementations at potentially low performance, but can software-only implementations at potentially low performance, but can
also support high performance options. See [RFC8368] for more also support high performance options. See [RFC8368] for more
details. details.
6.12.2. Addressing of Secure Channels 6.12.2. Addressing of Secure Channels
In order to be independent of the Data-Plane (routing and addressing) In order to be independent of the Data-Plane (routing and addressing)
the GRASP discovered (autonomic) ACP secure channels use IPv6 link the GRASP discovered (autonomic) ACP secure channels use IPv6 link
local addresses between adjacent neighbors. Note: Section 8.2 local addresses between adjacent neighbors. Note: Section 8.2
specifies extensions in which secure channels are configured tunnels specifies extensions in which secure channels are configured tunnels
operating over the Data-Plane, so those secure channels can not be operating over the Data-Plane, so those secure channels cannot be
independent of the Data-Plane. independent of the Data-Plane.
To avoid that Data-Plane configuration can impact the operations of To avoid that Data-Plane configuration can impact the operations of
the IPv6 (link-local) interface/address used for ACP channels, the IPv6 (link-local) interface/address used for ACP channels,
appropriate implementation considerations are required. If the IPv6 appropriate implementation considerations are required. If the IPv6
interface/link-local address is shared with the Data-Plane it needs interface/link-local address is shared with the Data-Plane it needs
to be impossible to unconfigure/disable it through configuration. to be impossible to unconfigure/disable it through configuration.
Instead of sharing the IPv6 interface/link-local address, a separate Instead of sharing the IPv6 interface/link-local address, a separate
(virtual) interface with a separate IPv6 link-local addresss can be (virtual) interface with a separate IPv6 link-local address can be
used. For example, the ACP interface could be run over a separate used. For example, the ACP interface could be run over a separate
MAC addres of an underlying L2 (Ethernet) interface. For more MAC address of an underlying L2 (Ethernet) interface. For more
details and options, see Appendix A.10.2. details and options, see Appendix A.10.2.
Note that other (non-ideal) implementation choices may introduce Note that other (non-ideal) implementation choices may introduce
additional undesired dependencies against the Data-Plane. For additional undesired dependencies against the Data-Plane. For
example shared code and configuration of the secure channel protocols example shared code and configuration of the secure channel protocols
(IPsec / DTLS). (IPsec / DTLS).
6.12.3. MTU 6.12.3. MTU
The MTU for ACP secure channels must be derived locally from the The MTU for ACP secure channels must be derived locally from the
skipping to change at page 58, line 48 skipping to change at page 58, line 48
resilient. These addresses on Loopback interfaces can be thought of resilient. These addresses on Loopback interfaces can be thought of
as "node addresses" instead of "interface addresses", and that is as "node addresses" instead of "interface addresses", and that is
what ACP address(es) are. This construct makes it therefore possible what ACP address(es) are. This construct makes it therefore possible
to address ACP nodes with a well-defined set of addresses independent to address ACP nodes with a well-defined set of addresses independent
of the number of external interfaces. of the number of external interfaces.
For these reason, the ACP (ULA) address(es) are assigned to Loopback For these reason, the ACP (ULA) address(es) are assigned to Loopback
interface(s). interface(s).
Any type of ACP secure channels to another ACP node can be mapped to Any type of ACP secure channels to another ACP node can be mapped to
ACP virtual interfaces in tollowing ways. This is independent of the ACP virtual interfaces in following ways. This is independent of the
choosen secure channel protocol (IPsec, DTLS or other future protocol chosen secure channel protocol (IPsec, DTLS or other future protocol
- standards or non-standards): - standards or non-standards):
ACP point-to-point virtual interface: ACP point-to-point virtual interface:
Each ACP secure channel is mapped into a separate point-to-point ACP Each ACP secure channel is mapped into a separate point-to-point ACP
virtual interface. If a physical subnet has more than two ACP virtual interface. If a physical subnet has more than two ACP
capable nodes (in the same domain), this implementation approach will capable nodes (in the same domain), this implementation approach will
lead to a full mesh of ACP virtual interfaces between them. lead to a full mesh of ACP virtual interfaces between them.
ACP multi-access virtual interface: ACP multi-access virtual interface:
skipping to change at page 60, line 39 skipping to change at page 60, line 39
ACP GRASP wants to send a link-local GRASP multicast message to Bob ACP GRASP wants to send a link-local GRASP multicast message to Bob
and Carol. If Alice's ACP emulates the LAN as one point-to-point and Carol. If Alice's ACP emulates the LAN as one point-to-point
virtual interface to Bob and one to Carol, The sending applications virtual interface to Bob and one to Carol, The sending applications
itself will send two copies, if Alice's ACP emulates a LAN, GRASP itself will send two copies, if Alice's ACP emulates a LAN, GRASP
will send one packet and the ACP will replicate it. The result is will send one packet and the ACP will replicate it. The result is
the same. The difference happens when Bob and Carol receive their the same. The difference happens when Bob and Carol receive their
packet. If they use ACP point-to-point virtual interfaces, their packet. If they use ACP point-to-point virtual interfaces, their
GRASP instance would forward the packet from Alice to each other as GRASP instance would forward the packet from Alice to each other as
part of the GRASP flooding procedure. These packets are unnecessary part of the GRASP flooding procedure. These packets are unnecessary
and would be discarded by GRASP on receipt as duplicates (by use of and would be discarded by GRASP on receipt as duplicates (by use of
the GRASP Session ID). If Bob and Charly's ACP would emulate a the GRASP Session ID). If Bob and Charlie's ACP would emulate a
multi-access virtual interface, then this would not happen, because multi-access virtual interface, then this would not happen, because
GRASPs flooding procedure does not replicate back packets to the GRASPs flooding procedure does not replicate back packets to the
interface that they were received from. interface that they were received from.
Note that link-local GRASP multicast messages are not sent directly Note that link-local GRASP multicast messages are not sent directly
as IPv6 link-local multicast UDP messages into ACP virtual as IPv6 link-local multicast UDP messages into ACP virtual
interfaces, but instead into ACP GRASP virtual interfaces, that are interfaces, but instead into ACP GRASP virtual interfaces, that are
layered on top of ACP virtual interfaces to add TCP reliability to layered on top of ACP virtual interfaces to add TCP reliability to
link-local multicast GRASP messages. Nevertheless, these ACP GRASP link-local multicast GRASP messages. Nevertheless, these ACP GRASP
virtual interfaces perform the same replication of message and, virtual interfaces perform the same replication of message and,
skipping to change at page 69, line 28 skipping to change at page 69, line 28
announced together with RFC4191 option for the prefixes routed across announced together with RFC4191 option for the prefixes routed across
the ACP and lifetime=0 to disqualify this next-hop as a default the ACP and lifetime=0 to disqualify this next-hop as a default
router. For the Data-Plane, the Data-Plane prefix(es) are announced router. For the Data-Plane, the Data-Plane prefix(es) are announced
together with whatever dafault router parameters are used for the together with whatever dafault router parameters are used for the
Data-Plane. Data-Plane.
In result, RFC6724 source address selection Rule 5.5 may result in In result, RFC6724 source address selection Rule 5.5 may result in
the same correct source address selection behavior of NMS hosts the same correct source address selection behavior of NMS hosts
without further configuration on it as the separate ACP connect and without further configuration on it as the separate ACP connect and
Data-Plane interfaces. As described in the text for Rule 5.5, this Data-Plane interfaces. As described in the text for Rule 5.5, this
is only a may, because IPv6 hosts are not required to track next-hop is only a MAY, because IPv6 hosts are not required to track next-hop
information. If an NMS Host does not do this, then separate ACP information. If an NMS Host does not do this, then separate ACP
connect and Data-Plane interfaces are the preferable method of connect and Data-Plane interfaces are the preferable method of
attachment. Hosts implementing [RFC8028] should (instead of may) attachment. Hosts implementing [RFC8028] should (instead of may)
implement [RFC6724] Rule 5.5, so it is preferred for hosts to support implement [RFC6724] Rule 5.5, so it is preferred for hosts to support
[RFC8028]. [RFC8028].
ACP edge nodes MAY support the Combined ACP and Data-Plane interface. ACP edge nodes MAY support the Combined ACP and Data-Plane interface.
8.1.5. Use of GRASP 8.1.5. Use of GRASP
skipping to change at page 71, line 42 skipping to change at page 71, line 42
o Pmtu should be configurable to overcome issues/limitations of Path o Pmtu should be configurable to overcome issues/limitations of Path
MTU Discovery (PMTUD). MTU Discovery (PMTUD).
o IKEv2/IPsec to remote peers should support the optional NAT o IKEv2/IPsec to remote peers should support the optional NAT
Traversal (NAT-T) procedures. Traversal (NAT-T) procedures.
8.2.2. Tunneled Remote ACP Neighbor 8.2.2. Tunneled Remote ACP Neighbor
An IPinIP, GRE or other form of pre-existing tunnel is configured An IPinIP, GRE or other form of pre-existing tunnel is configured
between two remote ACP peers and the virtual interfaces representing between two remote ACP peers and the virtual interfaces representing
the tunnel are configured to "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. In 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 with DULL and secure channel setup procedures described in this
document. document.
Tunneled Remote ACP Neighbor requires two encapsulations: the Tunneled Remote ACP Neighbor requires two encapsulations: the
configured tunnel and the secure channel inside of that tunnel. This configured tunnel and the secure channel inside of that tunnel. This
makes it in general less desirable than Configured Remote ACP makes it in general less desirable than Configured Remote ACP
Neighbor. Benefits of tunnels are that it may be easier to implement Neighbor. Benefits of tunnels are that it may be easier to implement
because there is no change to the ACP functionality - just running it because there is no change to the ACP functionality - just running it
skipping to change at page 73, line 15 skipping to change at page 73, line 15
There are few central dependencies: A certificate revocation list There are few central dependencies: A certificate revocation list
(CRL) may not be available during a network partition; a suitable (CRL) may not be available during a network partition; a suitable
policy to not immediately disconnect neighbors when no CRL is policy to not immediately disconnect neighbors when no CRL is
available can address this issue. Also, an ACP registrar or available can address this issue. Also, an ACP registrar or
Certificate Authority might not be available during a partition. Certificate Authority might not be available during a partition.
This may delay renewal of certificates that are to expire in the This may delay renewal of certificates that are to expire in the
future, and it may prevent the enrollment of new nodes during the future, and it may prevent the enrollment of new nodes during the
partition. partition.
Highly resilient ACP designs can be built by using ACP registrars Highly resilient ACP designs can be built by using ACP registrars
with embedded sub-CA, as outlined in Section 10.2.4. As long a a with embedded sub-CA, as outlined in Section 10.2.4. As long as a
partition is left with one or more of such ACP registrars, it can partition is left with one or more of such ACP registrars, it can
continue to enroll new candidate ACP nodes as long as the ACP continue to enroll new candidate ACP nodes as long as the ACP
registrars sub-CA certificate does not expire. Because the ACP registrars sub-CA certificate does not expire. Because the ACP
addressing relies on unique Registrar-IDs, a later re-merge of addressing relies on unique Registrar-IDs, a later re-merge of
partitions will also not cause problems with ACP addresses assigned partitions will also not cause problems with ACP addresses assigned
during partitioning. during partitioning.
After a network partition, a re-merge will just establish the After a network partition, a re-merge will just establish the
previous status, certificates can be renewed, the CRL is available, previous status, certificates can be renewed, the CRL is available,
and new nodes can be enrolled everywhere. Since all nodes use the and new nodes can be enrolled everywhere. Since all nodes use the
skipping to change at page 74, line 16 skipping to change at page 74, line 16
and in addition, provide replay protection. and in addition, provide replay protection.
An attacker will not be able to join the ACP unless having a valid An attacker will not be able to join the ACP unless having a valid
domain certificate, also packet injection and sniffing traffic will domain certificate, also packet injection and sniffing traffic will
not be possible due to the security provided by the encryption not be possible due to the security provided by the encryption
protocol. protocol.
The ACP also serves as protection (through authentication and The ACP also serves as protection (through authentication and
encryption) for protocols relevant to OAM that may not have secured encryption) for protocols relevant to OAM that may not have secured
protocol stack options or where implementation or deployment of those protocol stack options or where implementation or deployment of those
options fails on some vendor/product/customer limitations. This options fail on some vendor/product/customer limitations. This
includes protocols such as SNMP, NTP/PTP, DNS, DHCP, syslog, includes protocols such as SNMP, NTP/PTP, DNS, DHCP, syslog,
Radius/Diameter/TACACS, IPFIX/Netflow - just to name a few. Radius/Diameter/TACACS, IPFIX/Netflow - just to name a few.
Protection via the ACP secure hop-by-hop channels for these protocols Protection via the ACP secure hop-by-hop channels for these protocols
is meant to be only a stopgap though: The ultimate goal is for these is meant to be only a stopgap though: The ultimate goal is for these
and other protocols to use end-to-end encryption utilizing the domain and other protocols to use end-to-end encryption utilizing the domain
certificate and rely on the ACP secure channels primarily for zero- certificate and rely on the ACP secure channels primarily for zero-
touch reliable connectivity, but not primarily for security. touch reliable connectivity, but not primarily for security.
The remaining attack vector would be to attack the underlying ACP The remaining attack vector would be to attack the underlying ACP
protocols themselves, either via directed attacks or by denial-of- protocols themselves, either via directed attacks or by denial-of-
skipping to change at page 76, line 13 skipping to change at page 76, line 13
the ACP (see Section 3). the ACP (see Section 3).
o Section 10.1 describes recommended operator diagnostics o Section 10.1 describes recommended operator diagnostics
capabilities of ACP nodes. The have been derived from diagnostic capabilities of ACP nodes. The have been derived from diagnostic
of a commercially available ACP implementation. of a commercially available ACP implementation.
o Section 10.2 describes high level how an ACP registrar needs to o Section 10.2 describes high level how an ACP registrar needs to
work, what its configuration parameters are and specific issues work, what its configuration parameters are and specific issues
impacting the choices of deployment design due to renewal and impacting the choices of deployment design due to renewal and
revocation issues. It describes a model where ACP Registrars have revocation issues. It describes a model where ACP Registrars have
their own sub-CA to provide the most disributed deployment option their own sub-CA to provide the most distributed deployment option
for ACP Registrars, and it describes considerations for for ACP Registrars, and it describes considerations for
centralized policy control of ACP Registrar operations. centralized policy control of ACP Registrar operations.
o Section 10.3 describes suggested ACP node behavior and operational o Section 10.3 describes suggested ACP node behavior and operational
interfaces (configuration options) to manage the ACP in so-called interfaces (configuration options) to manage the ACP in so-called
greenfield devices (previously unconfigured) and brownfield greenfield devices (previously unconfigured) and brownfield
devices (preconfigured). devices (preconfigured).
The recommendations and suggestions of this chapter were derived from The recommendations and suggestions of this chapter were derived from
operational experience gained with a commercially available pre- operational experience gained with a commercially available pre-
skipping to change at page 79, line 24 skipping to change at page 79, line 24
+ The ACP domain certificate membership check (Section 6.1.2) + The ACP domain certificate membership check (Section 6.1.2)
fails: fails:
- The neighbors certificate does not have the required - The neighbors certificate does not have the required
trust anchor. Provide diagnostics which trust anchor it trust anchor. Provide diagnostics which trust anchor it
has (can identify whom the device belongs to). has (can identify whom the device belongs to).
- The neighbors certificate does not have the same domain - The neighbors certificate does not have the same domain
(or no domain at all). Diagnose domain-name and (or no domain at all). Diagnose domain-name and
potentially other other cert info. potentially other cert info.
- The neighbors certificate has been revoked or could not - The neighbors certificate has been revoked or could not
be authenticated by OCSP. be authenticated by OCSP.
- The neighbors certificate has expired - or is not yet - The neighbors certificate has expired - or is not yet
valid. valid.
* Any other connection issues in e.g., IKEv2 / IPsec, DTLS?. * Any other connection issues in e.g., IKEv2 / IPsec, DTLS?.
Question: Is the ACP operating correctly across its secure channels? Question: Is the ACP operating correctly across its secure channels?
skipping to change at page 81, line 34 skipping to change at page 81, line 34
proxy, a design that can be adopted for various protocols that proxy, a design that can be adopted for various protocols that
Pledges/candidate ACP nodes could want to use, for example BRSKI over Pledges/candidate ACP nodes could want to use, for example BRSKI over
CoAP (Constrained Application Protocol), or proxying of Netconf. CoAP (Constrained Application Protocol), or proxying of Netconf.
To reach a trust anchor unaware of the ACP, the ACP registrar would To reach a trust anchor unaware of the ACP, the ACP registrar would
use the Data-Plane. ACP and Data-Plane in an ACP registrar could use the Data-Plane. ACP and Data-Plane in an ACP registrar could
(and by default should be) completely isolated from each other at the (and by default should be) completely isolated from each other at the
network level. Only applications such as the ACP registrar would network level. Only applications such as the ACP registrar would
need the ability for their transport stacks to access both. need the ability for their transport stacks to access both.
In non autonomic enrollment options, the Data-Plane between a ACP In non-autonomic enrollment options, the Data-Plane between a ACP
registrar and the candidate ACP node needs to be configured first. registrar and the candidate ACP node needs to be configured first.
This includes the ACP registrar and the candidate ACP node. Then any This includes the ACP registrar and the candidate ACP node. Then any
appropriate set of protocols can be used between ACP registrar and appropriate set of protocols can be used between ACP registrar and
candidate ACP node to discover the other side, and then connect and candidate ACP node to discover the other side, and then connect and
enroll (configure) the candidate ACP node with an ACP domain enroll (configure) the candidate ACP node with an ACP domain
certificate. Netconf ZeroTouch ([I-D.ietf-netconf-zerotouch]) is an certificate. Netconf ZeroTouch ([I-D.ietf-netconf-zerotouch]) is an
example protocol that could be used for this. BRSKI using optional example 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 attempting to be enrolled across non-ACP networks, such as the
Internet. Internet.
skipping to change at page 82, line 39 skipping to change at page 82, line 39
For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub- For recovery, the next-useable Node-IDs for zone (Zone-ID=0) sub-
addressing scheme, for Vlong /112 and for Vlong /1120 sub- addressing scheme, for Vlong /112 and for Vlong /1120 sub-
addressing scheme. These IDs would only need to be provisioned addressing scheme. These IDs would only need to be provisioned
after recovering from a crash. Some other mechanism would be after recovering from a crash. Some other mechanism would be
required to remember these IDs in a backup location or to recover required to remember these IDs in a backup location or to recover
them from the set of currently known ACP nodes. them from the set of currently known ACP nodes.
Policies if candidate ACP nodes should receive a domain Policies if candidate ACP nodes should receive a domain
certificate or not, for example based on the devices LDevID as in certificate or not, for example based on the devices LDevID as in
BRSKI. The ACP registrar may have a whitelist or blacklist of BRSKI. The ACP registrar may have a whitelist or blacklist of
devices serialNumbers from teir LDevID. devices serialNumbers from their LDevID.
Policies what type of address prefix to assign to a candidate ACP Policies what type of address prefix to assign to a candidate ACP
devices, based on likely the same information. devices, based on likely the same information.
For BRSKI or other mechanisms using vouchers: Parameters to For BRSKI or other mechanisms using vouchers: Parameters to
determine how to retrieve vouchers for specific type of secure determine how to retrieve vouchers for specific type of secure
bootstrap candidate ACP nodes (such as MASA URLs), unless this bootstrap candidate ACP nodes (such as MASA URLs), unless this
information is automatically learned such as from the LDevID of information is automatically learned such as from the LDevID of
candidate ACP nodes (as defined in BRSKI). candidate ACP nodes (as defined in BRSKI).
skipping to change at page 83, line 20 skipping to change at page 83, line 20
because that original ACP registrar is gone. The ACP registrar because that original ACP registrar is gone. The ACP registrar
through which the renewal/rekeying is performed would by default through which the renewal/rekeying is performed would by default
trust the ACP domain information from the ACP nodes current ACP trust the ACP domain information from the ACP nodes current ACP
domain certificate and maintain this information so that the ACP node domain certificate and maintain this information so that the ACP node
maintains its ACP address prefix. In EST renewal/rekeying, the ACP maintains its ACP address prefix. In EST renewal/rekeying, the ACP
nodes current ACP domain certificate is signaled during the TLS nodes current ACP domain certificate is signaled during the TLS
handshake. handshake.
This simple scenario has two limitations: This simple scenario has two limitations:
1. The ACP registrars can not directly assign certificates to nodes 1. The ACP registrars cannot directly assign certificates to nodes
and therefore needs an "online" connection to the trust anchor and therefore needs an "online" connection to the trust anchor
(root CA). (root CA).
2. Recovery from a compromised ACP registrar is difficult. When an 2. Recovery from a compromised ACP registrar is difficult. When an
ACP registrar is compromised, it can insert for example ACP registrar is compromised, it can insert for example
conflicting ACP domain information and create thereby an attack conflicting ACP domain information and create thereby an attack
against other ACP nodes through the ACP routing protocol. against other ACP nodes through the ACP routing protocol.
Even when such a malicious ACP registrar is detected, resolving the Even when such a malicious ACP registrar 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 domain certificates assigned via the ACP registrar after it wrong ACP domain certificates assigned via the ACP registrar after it
was was compromised. And without additional centralized tracking of was compromised. And without additional centralized tracking of
assigned certificates there is no way to do this - assuming one can assigned certificates there is no way to do this.
not retrieve this information from the .
10.2.4. ACP Registrars with sub-CA 10.2.4. ACP Registrars with sub-CA
In situations, where either of the above two limitations are an In situations, where either of the above two limitations are an
issue, ACP registrars could also be sub-CAs. This removes the need issue, ACP registrars could also be sub-CAs. This removes the need
for connectivity to a root-CA whenever an ACP node is enrolled, and for connectivity to a root-CA whenever an ACP node is enrolled, and
reduces the need for connectivity of such an ACP registrar to a root- reduces the need for connectivity of such an ACP registrar to a root-
CA to only those times when it needs to renew its own certificate. CA to only those times when it needs to renew its own certificate.
The ACP registrar would also now use its own (sub-CA) certificate to The ACP registrar would also now use its own (sub-CA) certificate to
enroll and sign the ACP nodes certificates, and therefore it is only enroll and sign the ACP nodes certificates, and therefore it is only
necessary to revoke a compromised ACP registrars sub-CA certificate. necessary to revoke a compromised ACP registrars sub-CA certificate.
Or let it expire and not renew it, when the certificate of the sub-CA Or let it expire and not renew it, when the certificate of the sub-CA
is appropriately short-lived. is appropriately short-lived.
As the ACP domain membership check verifies a peer ACP node's ACP As the ACP domain membership check verifies a peer ACP node's ACP
domain certicate trust chain, it will also verify the signing domain certificate trust chain, it will also verify the signing
certificate which is the compromised/revoked sub-CA certificate. certificate which is the compromised/revoked sub-CA certificate.
Therefore ACP domain membership for an ACP node enrolled from a Therefore ACP domain membership for an ACP node enrolled from a
compromised ACP registrar will fail. compromised ACP registrar will fail.
ACP nodes enrolled by a compromised ACP registrar would automatically ACP nodes enrolled by a compromised ACP registrar would automatically
fail to establish ACP channels and ACP domain certificate renewal via fail to establish ACP channels and ACP domain certificate renewal via
EST and therefore revert to their role as a candidate ACP members and EST and therefore revert to their role as a candidate ACP members and
attempt to get a new ACP domain certificate from an ACP registrar - attempt to get a new ACP domain certificate from an ACP registrar -
for example via BRSKI. In result, ACP registrars that have an for example, via BRSKI. In result, ACP registrars that have an
associated sub-CA makes isolating and resolving issues with associated sub-CA makes isolating and resolving issues with
compromised registrars easier. compromised registrars easier.
Note that ACP registrars with sub-CA functionality also can control Note that ACP registrars with sub-CA functionality also can control
the lifetime of ACP domain certificates easier and therefore also be the lifetime of ACP domain certificates easier and therefore also be
used as a tool to introduce short lived certificates and not rely on used as a tool to introduce short lived certificates and not rely on
CRL, whereas the certificates for the sub-CAs themselves could be CRL, whereas the certificates for the sub-CAs themselves could be
longer lived and subject to CRL. longer lived and subject to CRL.
10.2.5. Centralized Policy Control 10.2.5. Centralized Policy Control
skipping to change at page 84, line 44 skipping to change at page 84, line 41
Tracking of all enrolled ACP nodes and their certificate Tracking of all enrolled ACP nodes and their certificate
information. For example in support of revoking individual ACP information. For example in support of revoking individual ACP
nodes certificates. nodes certificates.
More flexible policies what type of address prefix or even what More flexible policies what type of address prefix or even what
specific address prefix to assign to a candidate ACP node. specific address prefix to assign to a candidate ACP node.
These and other operations could be introduced more easily by These and other operations could be introduced more easily by
introducing a centralized Policy Management System (PMS) and introducing a centralized Policy Management System (PMS) and
modifying ACP registrar behavior so that it queries the PMS for any modifying ACP registrar behavior so that it queries the PMS for any
policy decision occuring during the candidate ACP node enrollment policy decision occurring during the candidate ACP node enrollment
process and/or the ACP node certificate renewal process. For process and/or the ACP node certificate renewal process. For
example, which ACP address prefix to assign. Likewise the ACP example, which ACP address prefix to assign. Likewise the ACP
registrar would report any relevant state change information to the registrar would report any relevant state change information to the
PMS as well, for example when a certificate was successfully enrolled PMS as well, for example when a certificate was successfully enrolled
onto a candidate ACP node. onto a candidate ACP node.
10.3. Enabling and disabling ACP/ANI 10.3. Enabling and disabling ACP/ANI
Both ACP and BRSKI require interfaces to be operational enough to Both ACP and BRSKI require interfaces to be operational enough to
support sending/receiving their packets. In node types where support sending/receiving their packets. In node types where
skipping to change at page 88, line 28 skipping to change at page 88, line 23
ACP, ASA on both nodes of the link could perform a negotiated ACP, ASA on both nodes of the link could perform a negotiated
diagnostics that automatically terminates in a predetermined manner diagnostics that automatically terminates in a predetermined manner
without dependence on external input ensuring the link will become without dependence on external input ensuring the link will become
operational again. operational again.
10.3.2.4. Power Consumption Issues 10.3.2.4. Power Consumption Issues
Power consumption of "physical down" interfaces, may be significantly Power consumption of "physical down" interfaces, may be significantly
lower than those in "admin down" state, for example on long-range lower than those in "admin down" state, for example on long-range
fiber interfaces. Bringing up interfaces, for example to probe fiber interfaces. Bringing up interfaces, for example to probe
reachabiliy, may also consume additional power. This can make these reachability, may also consume additional power. This can make these
type of interfaces inappropriate to operate purely for the ACP when type of interfaces inappropriate to operate purely for the ACP when
they are not currently needed for the Data-Plane. they are not currently needed for the Data-Plane.
10.3.3. Interface level ACP/ANI enable 10.3.3. Interface level ACP/ANI enable
The interface level configuration option "ACP enable" enables ACP The interface level configuration option "ACP enable" enables ACP
operations on an interface, starting with ACP neighbor discovery via operations on an interface, starting with ACP neighbor discovery via
DULL GRAP. The interface level configuration option "ANI enable" on DULL GRAP. The interface level configuration option "ANI enable" on
nodes supporting BRSKI and ACP starts with BRSKI pledge operations nodes supporting BRSKI and ACP starts with BRSKI pledge operations
when there is no domain certificate on the node. On ACP/BRSKI nodes, when there is no domain certificate on the node. On ACP/BRSKI nodes,
skipping to change at page 96, line 35 skipping to change at page 96, line 31
device is outside scope for this document. device is outside scope for this document.
o Created a new section 6 "workarounds for non-autonomic nodes", and o Created a new section 6 "workarounds for non-autonomic nodes", and
put the previous controller section (5.9) into this new section. put the previous controller section (5.9) into this new section.
Now, section 5 is "autonomic only", and section 6 explains what to Now, section 5 is "autonomic only", and section 6 explains what to
do with non-autonomic stuff. Much cleaner now. do with non-autonomic stuff. Much cleaner now.
o Added an appendix explaining the choice of RPL as a routing o Added an appendix explaining the choice of RPL as a routing
protocol. protocol.
o Formalised the creation process a bit more. Now, we create a o Formalized the creation process a bit more. Now, we create a
"candidate peer list" from the adjacency table, and form the ACP "candidate peer list" from the adjacency table, and form the ACP
with those candidates. Also it explains now better that policy with those candidates. Also it explains now better that policy
(Intent) can influence the peer selection. (section 4 and 5) (Intent) can influence the peer selection. (section 4 and 5)
o Introduce a section for the capability negotiation protocol o Introduce a section for the capability negotiation protocol
(section 7). This needs to be worked out in more detail. This (section 7). This needs to be worked out in more detail. This
will likely be based on GRASP. will likely be based on GRASP.
o Introduce a new parameter: ACP tunnel type. And defines it in the o Introduce a new parameter: ACP tunnel type. And defines it in the
IANA considerations section. Suggest GRE protected with IPSec IANA considerations section. Suggest GRE protected with IPSec
skipping to change at page 98, line 17 skipping to change at page 98, line 12
o Section 5.3 (candidate ACP neighbor selection): Add that Intent o Section 5.3 (candidate ACP neighbor selection): Add that Intent
can override only AFTER an initial default ACP establishment. can override only AFTER an initial default ACP establishment.
o Section 6.10.1 (addressing): State that addresses in the ACP are o Section 6.10.1 (addressing): State that addresses in the ACP are
permanent, and do not support temporary addresses as defined in permanent, and do not support temporary addresses as defined in
RFC4941. RFC4941.
o Modified Section 6.3 to point to the GRASP objective defined in o Modified Section 6.3 to point to the GRASP objective defined in
draft-carpenter-anima-ani-objectives. (and added that reference) draft-carpenter-anima-ani-objectives. (and added that reference)
o Section 6.10.2: changed from MD5 for calculating the first 40 bits o Section 6.10.2: changed from MD5 for calculating the first 40-bits
to SHA256; reason is MD5 should not be used any more. to SHA256; reason is MD5 should not be used any more.
o Added address sub-scheme to the IANA section. o Added address sub-scheme to the IANA section.
o Made the routing section more prescriptive. o Made the routing section more prescriptive.
o Clarified in Section 8.1.1 the ACP Connect port, and defined that o Clarified in Section 8.1.1 the ACP Connect port, and defined that
term "ACP Connect". term "ACP Connect".
o Section 8.2: Added some thoughts (from mcr) on how traversing a L3 o Section 8.2: Added some thoughts (from mcr) on how traversing a L3
skipping to change at page 98, line 46 skipping to change at page 98, line 41
Richardson on 30 Nov 2016 (see ANIMA list). Richardson on 30 Nov 2016 (see ANIMA list).
14.12. draft-ietf-anima-autonomic-control-plane-06 14.12. draft-ietf-anima-autonomic-control-plane-06
o Added proposed RPL profile. o Added proposed RPL profile.
o detailed DTLS profile - DTLS with any additional negotiation/ o detailed DTLS profile - DTLS with any additional negotiation/
signaling channel. signaling channel.
o Fixed up text for ACP/GRE encap. Removed text claiming its o Fixed up text for ACP/GRE encap. Removed text claiming its
incompatible with non-GRE IPsec and detailled it. incompatible with non-GRE IPsec and detailed it.
o Added text to suggest admin down interfaces should still run ACP. o Added text to suggest admin down interfaces should still run ACP.
14.13. draft-ietf-anima-autonomic-control-plane-07 14.13. draft-ietf-anima-autonomic-control-plane-07
o Changed author association. o Changed author association.
o Improved ACP connect setion (after confusion about term came up in o Improved ACP connect setion (after confusion about term came up in
the stable connectivity draft review). Added picture, defined the stable connectivity draft review). Added picture, defined
complete terminology. complete terminology.
skipping to change at page 100, line 47 skipping to change at page 100, line 39
14.14. draft-ietf-anima-autonomic-control-plane-08 14.14. draft-ietf-anima-autonomic-control-plane-08
Modified mentioning of BRSKI to make it consistent with current Modified mentioning of BRSKI to make it consistent with current
(07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices (07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices
with only insecure UDI would need a security reduced variant of with only insecure UDI would need a security reduced variant of
BRSKI. Also added mentioning of Netconf Zero-Touch. Made BRSKI non- BRSKI. Also added mentioning of Netconf Zero-Touch. Made BRSKI non-
normative for ACP because wrt. ACP it is just one option how the normative for ACP because wrt. ACP it is just one option how the
domain certificate can be provisioned. Instead, BRSKI is mandatory domain certificate can be provisioned. Instead, BRSKI is mandatory
when a device implements ANI which is ACP+BRSKI. when a device implements ANI which is ACP+BRSKI.
Enhanced text for ACP across tunnels to decribe two options: one Enhanced text for ACP across tunnels to describe two options: one
across configured tunnels (GRE, IPinIP etc) a more efficient one via across configured tunnels (GRE, IPinIP etc) a more efficient one via
directed DULL. directed DULL.
Moved decription of BRSKI to appendex to emphasize that BRSKI is not Moved decription of BRSKI to appendix to emphasize that BRSKI is not
a (normative) dependency of GRASP, enhanced text to indicate other a (normative) dependency of GRASP, enhanced text to indicate other
options how Domain Certificates can be provisioned. options how Domain Certificates can be provisioned.
Added terminology section. Added terminology section.
Separated references into normative and non-normative. Separated references into normative and non-normative.
Enhanced section about ACP via "tunnels". Defined an option to run Enhanced section about ACP via "tunnels". Defined an option to run
ACP secure channel without an outer tunnel, discussed PMTU, benefits ACP secure channel without an outer tunnel, discussed PMTU, benefits
of tunneling, potential of using this with BRSKI, made ACP via GREP a of tunneling, potential of using this with BRSKI, made ACP via GREP a
SHOULD requirement. SHOULD requirement.
Moved appendix sections up before IANA section because there where Moved appendix sections up before IANA section because there where
concerns about appendices to be to far on the bottom to be read. concerns about appendices to be too far on the bottom to be read.
Added (Informative) / (Normative) to section titles to clarify which Added (Informative) / (Normative) to section titles to clarify which
sections are informative and which are normative sections are informative and which are normative
Moved explanation of ACP with L2 from precondition to separate Moved explanation of ACP with L2 from precondition to separate
section before workarounds, made it instructive enough to explain how section before workarounds, made it instructive enough to explain how
to implement ACP on L2 ports for L3/L2 switches and made this part of to implement ACP on L2 ports for L3/L2 switches and made this part of
normative requirement (L2/L3 switches SHOULD support this). normative requirement (L2/L3 switches SHOULD support this).
Rewrote section "GRASP in the ACP" to define GRASP in ACP as Rewrote section "GRASP in the ACP" to define GRASP in ACP as
mandatory (and why), and define the ACP as security and transport mandatory (and why), and define the ACP as security and transport
skipping to change at page 102, line 40 skipping to change at page 102, line 33
o The stable connectivity draft was vaguely describing ACP connect o The stable connectivity draft was vaguely describing ACP connect
behavior that is better standardized in this ACP draft. behavior that is better standardized in this ACP draft.
o Added new ACP "Manual" addressing sub-scheme with /64 subnets for o Added new ACP "Manual" addressing sub-scheme with /64 subnets for
use with ACP connect interfaces. Being covered by the ACP ULA use with ACP connect interfaces. Being covered by the ACP ULA
prefix, these subnets do not require additional routing entries prefix, these subnets do not require additional routing entries
for NMS hosts. They also are fully 64-bit IID length compliant for NMS hosts. They also are fully 64-bit IID length compliant
and therefore not subject to 4191bis considerations. And they and therefore not subject to 4191bis considerations. And they
avoid that operators manually assign prefixes from the ACP ULA avoid that operators manually assign prefixes from the ACP ULA
prefixes that might later be assigned autonomiously. prefixes that might later be assigned autonomically.
o ACP connect auto-configuration: Defined that ACP edge devices, NMS o ACP connect auto-configuration: Defined that ACP edge devices, NMS
hosts should use RFC4191 to automatically learn ACP prefixes. hosts should use RFC4191 to automatically learn ACP prefixes.
This is especially necessary when the ACP uses multiple ULA This is especially necessary when the ACP uses multiple ULA
prefixes (via e.g., the rsub domain certificate option), or if ACP prefixes (via e.g., the rsub domain certificate option), or if ACP
connect subinterfaces use manually configured prefixes NOT covered connect sub-interfaces use manually configured prefixes NOT
by the ACP ULA prefixes. covered by the ACP ULA prefixes.
o Explained how rfc6724 is (only) sufficient when the NMS host has a o Explained how rfc6724 is (only) sufficient when the NMS host has a
separate ACP connect and Data-Plane interface. But not when there separate ACP connect and Data-Plane interface. But not when there
is a single interface. is a single interface.
o Added a separate subsection to talk about "software" instead of o Added a separate subsection to talk about "software" instead of
"NMS hosts" connecting to the ACP via the "ACP connect" method. "NMS hosts" connecting to the ACP via the "ACP connect" method.
The reason is to point out that the "ACP connect" method is not The reason is to point out that the "ACP connect" method is not
only a workaround (for NMS hosts), but an actual desirable long only a workaround (for NMS hosts), but an actual desirable long
term architectural component to modularily build software (e.g., term architectural component to modularly build software (e.g.,
ASA or OAM for VNF) into ACP devices. ASA or OAM for VNF) into ACP devices.
o Added a section to define how to run ACP connect across the same o Added a section to define how to run ACP connect across the same
interface as the Data-Plane. This turns out to be quite interface as the Data-Plane. This turns out to be quite
challenging because we only want to rely on existing standards for challenging because we only want to rely on existing standards for
the network stack in the NMS host/software and only define what the network stack in the NMS host/software and only define what
features the ACP edge device needs. features the ACP edge device needs.
o Added section about use of GRASP over ACP connect. o Added section about use of GRASP over ACP connect.
skipping to change at page 103, line 31 skipping to change at page 103, line 24
filter incorrect packets arriving on ACP connect interfaces, filter incorrect packets arriving on ACP connect interfaces,
diagnose on RPL root packets to incorrect destination address (not diagnose on RPL root packets to incorrect destination address (not
in ACP connect section, but because of it). in ACP connect section, but because of it).
o Reaffirm security goal of ACP: Do not permit non-ACP routers into o Reaffirm security goal of ACP: Do not permit non-ACP routers into
ACP routing domain. ACP routing domain.
Made this ACP document be an update to RFC4291 and RFC4193. At the Made this ACP document be an update to RFC4291 and RFC4193. At the
core, some of the ACP addressing sub-schemes do effectively not use core, some of the ACP addressing sub-schemes do effectively not use
64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During 64-bit IIDs as required by RFC4191 and debated in rfc4191bis. During
6man in prague, it was suggested that all documents that do not do 6man in Prague, it was suggested that all documents that do not do
this should be classified as such updates. Add a rather long section this should be classified as such updates. Add a rather long section
that summarizes the relevant parts of ACP addressing and usage and. that summarizes the relevant parts of ACP addressing and usage and.
Aka: This section is meant to be the primary review section for Aka: This section is meant to be the primary review section for
readers interested in these changes (e.g., 6man WG.). readers interested in these changes (e.g., 6man WG.).
Added changes from Michael Richardsons review https://github.com/ Added changes from Michael Richardsons review https://github.com/
anima-wg/autonomic-control-plane/pull/3/commits, textual and: anima-wg/autonomic-control-plane/pull/3/commits, textual and:
o ACP discovery inside ACP is bad *doh*!. o ACP discovery inside ACP is bad *doh*!.
skipping to change at page 104, line 18 skipping to change at page 104, line 12
o Lets use US american english. o Lets use US american english.
14.16. draft-ietf-anima-autonomic-control-plane-10 14.16. draft-ietf-anima-autonomic-control-plane-10
Used the term routing subdomain more consistently where previously Used the term routing subdomain more consistently where previously
only subdomain was used. Clarified use of routing subdomain in only subdomain was used. Clarified use of routing subdomain in
creation of ULA "global ID" addressing prefix. creation of ULA "global ID" addressing prefix.
6.7.1.* Changed native IPsec encapsulation to tunnel mode 6.7.1.* Changed native IPsec encapsulation to tunnel mode
(necessary), explaned why. Added notion that ESP is used, added (necessary), explained why. Added notion that ESP is used, added
explanations why tunnel/transport mode in native vs. GRE cases. explanations why tunnel/transport mode in native vs. GRE cases.
6.10.3/6.10.5 Added term "ACP address range/set" to be able to better 6.10.3/6.10.5 Added term "ACP address range/set" to be able to better
explain how the address in the ACP certificate is actually the base explain how the address in the ACP certificate is actually the base
address (lowest address) of a range/set that is available to the address (lowest address) of a range/set that is available to the
device. device.
6.10.4 Added note that manual address sub-scheme addresses must not 6.10.4 Added note that manual address sub-scheme addresses must not
be used within domain certificates (only for explicit configuration). be used within domain certificates (only for explicit configuration).
6.12.5 Refined explanation of how ACP virtual interfaces work (p2p 6.12.5 Refined explanation of how ACP virtual interfaces work (p2p
and multipoint). Did seek for pre-existing RFCs that explain how to and multipoint). Did seek for pre-existing RFCs that explain how to
built a multi-access interface on top of a full mesh of p2p build a multi-access interface on top of a full mesh of p2p
connections (6man WG, anima WG mailing lists), but could not find any connections (6man WG, anima WG mailing lists), but could not find any
prior work that had a succinct explanation. So wrote up an prior work that had a succinct explanation. So wrote up an
explanation here. Added hopefully all necessary and sufficient explanation here. Added hopefully all necessary and sufficient
details how to map ACP unicast packets to ACP secure channel, how to details how to map ACP unicast packets to ACP secure channel, how to
deal with ND packet details. Added verbage for ACP not to assign the deal with ND packet details. Added verbiage for ACP not to assign
virtual interface link-local address from the underlying interface. the virtual interface link-local address from the underlying
Addd note that GRAP link-local messages are treated specially but interface. Added note that GRAP link-local messages are treated
logically the same. Added paragraph about NBMA interfaces. specially but logically the same. Added paragraph about NBMA
interfaces.
remaining changes from Brian Carpenters review. See Github file remaining changes from Brian Carpenters review. See Github file
draft-ietf-anima-autonomic-control-plane/08-carpenter-review-reply.tx draft-ietf-anima-autonomic-control-plane/08-carpenter-review-reply.tx
for more detailst: for more details:
Added multiple new RFC references for terms/technologies used. Added multiple new RFC references for terms/technologies used.
Fixed verbage in several places. Fixed verbage in several places.
2. (terminology) Added 802.1AR as reference. 2. (terminology) Added 802.1AR as reference.
2. Fixed up definition of ULA. 2. Fixed up definition of ULA.
6.1.1 Changed definition of ACP information in cert into ABNF format. 6.1.1 Changed definition of ACP information in cert into ABNF format.
skipping to change at page 105, line 23 skipping to change at page 105, line 19
6.8.2 MAYOR: expanded security/transport substrate text: 6.8.2 MAYOR: expanded security/transport substrate text:
Introduced term ACP GRASP virtual interface to explain how GRASP Introduced term ACP GRASP virtual interface to explain how GRASP
link-local multicast messages are encapsulated and replicated to link-local multicast messages are encapsulated and replicated to
neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only
for link-local address (sockets). Introduced "ladder" picture to for link-local address (sockets). Introduced "ladder" picture to
visualize stack. visualize stack.
6.8.2.1 Expanded discussion/explanation of security model. TLS for 6.8.2.1 Expanded discussion/explanation of security model. TLS for
GRASP unicsast connections across ACP is double encryption (plus GRASP unicast connections across ACP is double encryption (plus
underlying ACP secure channel), but highly necessary to avoid very underlying ACP secure channel), but highly necessary to avoid very
simple man-in-the-middle attacks by compromised ACP members on-path. simple man-in-the-middle attacks by compromised ACP members on-path.
Ultimately, this is done to ensure that any apps using GRASP can get Ultimately, this is done to ensure that any apps using GRASP can get
full end-to-end secrecy for information sent across GRASP. But for full end-to-end secrecy for information sent across GRASP. But for
publically known ASA services, even this will not provide 100% publically known ASA services, even this will not provide 100%
security (this is discussed). Also why double encryption is the security (this is discussed). Also why double encryption is the
better/easier solution than trying to optimize this. better/easier solution than trying to optimize this.
6.10.1 Added discussion about pseudo-random addressing, scanning- 6.10.1 Added discussion about pseudo-random addressing, scanning-
attaacks (not an issue for ACP). attacks (not an issue for ACP).
6.12.2 New performance requirements section added. 6.12.2 New performance requirements section added.
6.10.1 Added notion to first experiment with existing addressing 6.10.1 Added notion to first experiment with existing addressing
schemes before defining new ones - we should be flexible enough. schemes before defining new ones - we should be flexible enough.
6.3/7.2 clarified the interactions between MLD and DULL GRASP and 6.3/7.2 clarified the interactions between MLD and DULL GRASP and
specified what needs to be done (e.g., in 2 switches doing ACP per L2 specified what needs to be done (e.g., in 2 switches doing ACP per L2
port). port).
skipping to change at page 106, line 9 skipping to change at page 105, line 51
aspects of ACP discussed elsewhere in the document. aspects of ACP discussed elsewhere in the document.
13. Added IANA requirements. 13. Added IANA requirements.
Added RFC2119 boilerplate. Added RFC2119 boilerplate.
14.17. draft-ietf-anima-autonomic-control-plane-11 14.17. draft-ietf-anima-autonomic-control-plane-11
Same text as -10 Unfortunately when uploading -10 .xml/.txt to Same text as -10 Unfortunately when uploading -10 .xml/.txt to
datatracker, a wrong version of .txt got uploaded, only the .xml was datatracker, a wrong version of .txt got uploaded, only the .xml was
correct. This impacts the -10 html version on datatra cker and the correct. This impacts the -10 html version on datatracker and the
PDF versions as well. Because rfcdiff also compares the .txt PDF versions as well. Because rfcdiff also compares the .txt
version, this -11 version was crea ted so that one can compare version, this -11 version was created so that one can compare changes
changes from -09 and changes to the next version (-12). from -09 and changes to the next version (-12).
14.18. draft-ietf-anima-autonomic-control-plane-12 14.18. draft-ietf-anima-autonomic-control-plane-12
Sheng Jiangs extensive review. Thanks! See Github file draft-ietf- Sheng Jiangs extensive review. Thanks! See Github file draft-ietf-
anima-autonomic-control-plane/09-sheng-review-reply.txt for more anima-autonomic-control-plane/09-sheng-review-reply.txt for more
details. Many of the larger changes listed below where inspired by details. Many of the larger changes listed below where inspired by
the review. the review.
Removed the claim that the document is updating RFC4291,RFC4193 and Removed the claim that the document is updating RFC4291,RFC4193 and
the section detailling it. Done on suggestion of Michael Richardson the section detailing it. Done on suggestion of Michael Richardson -
- just try to describe use of addressing in a way that would not just try to describe use of addressing in a way that would not
suggest a need claim update to architecture. suggest a need claim update to architecture.
Terminology cleanup: Terminology cleanup:
o Replaced "device" with "node" in text. Kept "device" only when o Replaced "device" with "node" in text. Kept "device" only when
referring to "physical node". Added definitions for those words. referring to "physical node". Added definitions for those words.
Includes changes of derived terms, especially in addressing: Includes changes of derived terms, especially in addressing:
"Node-ID" and "Node-Number" in the addressing details. "Node-ID" and "Node-Number" in the addressing details.
o Replaced term "autonomic FOOBAR" with "acp FOOBAR" as whereever o Replaced term "autonomic FOOBAR" with "acp FOOBAR" as wherever
appropriate: "autonomic" would imply that the node would need to appropriate: "autonomic" would imply that the node would need to
support more than the ACP, but that is not correct in most of the support more than the ACP, but that is not correct in most of the
cases. Wanted to make sure that implementers know they only need cases. Wanted to make sure that implementers know they only need
to support/implement ACP - unless stated otherwise. Includes to support/implement ACP - unless stated otherwise. Includes
"AN->ACP node", "AN->ACP adjacency table" and so on. "AN->ACP node", "AN->ACP adjacency table" and so on.
1 Added explanation in the introduction about relationship between 1 Added explanation in the introduction about relationship between
ACP, BRSKI, ANI and Autonomic Networks. ACP, BRSKI, ANI and Autonomic Networks.
6.1.1 Improved terminology and features of the certificate 6.1.1 Improved terminology and features of the certificate
information field. Now called domain information field instead of information field. Now called domain information field instead of
ACP information field. The acp-address field in the domain ACP information field. The acp-address field in the domain
information field is now optional, enabling easier introduction of information field is now optional, enabling easier introduction of
various future options. various future options.
6.1.2 Moved ACP domainer membership check from section 6.6 to (ACP 6.1.2 Moved ACP domain membership check from section 6.6 to (ACP
secure channels setup) here because it is not only used for ACP secure channels setup) here because it is not only used for ACP
secure channel setup. secure channel setup.
6.1.3 Fix text about certificate renewal after discussion with Max 6.1.3 Fix text about certificate renewal after discussion with Max
Pritikin/Michael Richardson/Brian Carpenter: Pritikin/Michael Richardson/Brian Carpenter:
o Version 10 erroneously assumed that the certificate itself could o Version 10 erroneously assumed that the certificate itself could
store a URL for renewal, but that is only possible for CRL URLs. store a URL for renewal, but that is only possible for CRL URLs.
Text now only refers to "remembered EST server" without implying Text now only refers to "remembered EST server" without implying
that this is stored in the certificate. that this is stored in the certificate.
o Objective for RFC7030/EST domain certificate renewal was changed o Objective for RFC7030/EST domain certificate renewal was changed
to "SRV.est" See also IANA section for explanation. to "SRV.est" See also IANA section for explanation.
o Removed detail of distance based service selection. This can be o Removed detail of distance based service selection. This can be
better done in future work because it would require a lot more better done in future work because it would require a lot more
detail for a good DNS-SD compatible approach. detail for a good DNS-SD compatible approach.
skipping to change at page 107, line 33 skipping to change at page 107, line 28
6.10 Added reference to 6.12.5 in initial use of "loopback interface" 6.10 Added reference to 6.12.5 in initial use of "loopback interface"
in section 6.10 in result of email discussion michaelR/michaelB. in section 6.10 in result of email discussion michaelR/michaelB.
10.2 Introduced informational section (diagnostics) because of 10.2 Introduced informational section (diagnostics) because of
operational experience - ACP/ANI undeployable without at least operational experience - ACP/ANI undeployable without at least
diagnostics like this. diagnostics like this.
10.3 Introduced informational section (enabling/disabling) ACP. 10.3 Introduced informational section (enabling/disabling) ACP.
Important to discuss this for security reasons (e.g., why to never Important to discuss this for security reasons (e.g., why to never
never auto-enable ANI on brownfield devices), for implementers and to auto-enable ANI on brownfield devices), for implementers and to
answer ongoing questions during WG meetings about how to deal with answer ongoing questions during WG meetings about how to deal with
shutdown interface. shutdown interface.
10.8 Added informational section discussing possible future 10.8 Added informational section discussing possible future
variations of the ACP for potential adopters that cannot directly use variations of the ACP for potential adopters that cannot directly use
the complete solution described in this document unmodified. the complete solution described in this document unmodified.
14.19. draft-ietf-anima-autonomic-control-plane-13 14.19. draft-ietf-anima-autonomic-control-plane-13
Swap author list (with permission). Swap author list (with permission).
skipping to change at page 108, line 12 skipping to change at page 108, line 5
to use Zone-ID != 0 in GRASP so that we can avoid routing/forwarding to use Zone-ID != 0 in GRASP so that we can avoid routing/forwarding
of Zone-ID = 0 prefixes. of Zone-ID = 0 prefixes.
Rest of feedback from review of -12, see Rest of feedback from review of -12, see
https://raw.githubusercontent.com/anima-wg/autonomic-control- https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/master/draft-ietf-anima-autonomic-control-plane/12-feedback- plane/master/draft-ietf-anima-autonomic-control-plane/12-feedback-
reply.txt reply.txt
Review from Brian Carpenter: Review from Brian Carpenter:
various: Autonomous -> autonomic(ally) in all remaining occurences. various: Autonomous -> autonomic(ally) in all remaining occurrences.
various: changed "manual (configured)" to "explicitly (configured)" various: changed "manual (configured)" to "explicitly (configured)"
to not exclude the option of (SDN controller) automatic configuration to not exclude the option of (SDN controller) automatic configuration
(no humans involved). (no humans involved).
1. Fixed reference to section 9. 1. Fixed reference to section 9.
2. Added definition of loopback interface == internal interface. 2. Added definition of loopback interface == internal interface.
After discus on WG mailing lists, including 6man. After discus on WG mailing lists, including 6man.
skipping to change at page 109, line 24 skipping to change at page 109, line 17
6.7.2 normative: AND MUST NOT (permit weaker crypto options. 6.7.2 normative: AND MUST NOT (permit weaker crypto options.
6.7.1.1 also included text denying weaker IPsec profile options. 6.7.1.1 also included text denying weaker IPsec profile options.
6.8.2 Fixed description how to build ACP GRASP virtual interfaces. 6.8.2 Fixed description how to build ACP GRASP virtual interfaces.
Added text that ACP continues to exist in absence of ACP neighbors. Added text that ACP continues to exist in absence of ACP neighbors.
various: Make sure all "zone" words are used consistently. various: Make sure all "zone" words are used consistently.
6.10.2/various: fixed 40 bit RFC4193 ULA prefix in all examples to 6.10.2/various: fixed 40-bit RFC4193 ULA prefix in all examples to
89b714f3db (thanks MichaelR). 89b714f3db (thanks MichaelR).
6.10.1 Removed comment about assigned ULA addressing. Decision not 6.10.1 Removed comment about assigned ULA addressing. Decision not
to use it now ancient history of WG decision making process, not to use it now ancient history of WG decision making process, not
worth nothing anymore in the RFC. worth nothing anymore in the RFC.
Review from Yongkang Zhang: Review from Yongkang Zhang:
6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub- 6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub-
Scheme. Scheme.
14.20. draft-ietf-anima-autonomic-control-plane-14 14.20. draft-ietf-anima-autonomic-control-plane-14
Disclaimer: All new text introduced by this revision provides only Disclaimer: All new text introduced by this revision provides only
additional explanations/ details based on received reviews and additional explanations/ details based on received reviews and
analysis by the authors. No changes to beavior already specified in analysis by the authors. No changes to behavior already specified in
prior revisions. prior revisions.
Joel Halpern, review part 3: Joel Halpern, review part 3:
Define/explain "ACP registrar" in reply to Joel Halpern review part Define/explain "ACP registrar" in reply to Joel Halpern review part
3, resolving primarily 2 documentation issues:: 3, resolving primarily 2 documentation issues::
1. Unclear how much ACP depends on BRSKI. ACP document was 1. Unclear how much ACP depends on BRSKI. ACP document was
referring unqualified to registrars and Registrar-ID in the referring unqualified to registrars and Registrar-ID in the
addressing section without explaining what a registrar is, addressing section without explaining what a registrar is,
skipping to change at page 110, line 25 skipping to change at page 110, line 17
Registrars. In non-ANI ACP networks, the registrar may simply be a Registrars. In non-ANI ACP networks, the registrar may simply be a
person using CLI/web-interfaces to provision domain certificates and person using CLI/web-interfaces to provision domain certificates and
set the ACP address correctly in the ACP domain certificate. set the ACP address correctly in the ACP domain certificate.
Wrt. 2.: The BRSKI document does rightfully not define how the ACP Wrt. 2.: The BRSKI document does rightfully not define how the ACP
address assignment and creation of the ACP domain information field address assignment and creation of the ACP domain information field
has to work because this is independent of BRSKI and needs to follow has to work because this is independent of BRSKI and needs to follow
the same rules whatever protocol/mechanisms are used to implement an the same rules whatever protocol/mechanisms are used to implement an
ACP Registrar. Another set of protocols that could be used instead ACP Registrar. Another set of protocols that could be used instead
of BRSKI is Netconf/Netconf-Call-Home, but such an alternative ACP of BRSKI is Netconf/Netconf-Call-Home, but such an alternative ACP
Registrar solution would need to be speficied in it's own document. Registrar solution would need to be specified in its own document.
Additional text/sections had to be added to detail important Additional text/sections had to be added to detail important
conditions so that automatic certificate maintenance for ACP nodes conditions so that automatic certificate maintenance for ACP nodes
(with BRSKI or other mechanisms) can be done in a way that as good as (with BRSKI or other mechanisms) can be done in a way that as good as
possible maintains ACP address information of ACP nodes across the possible maintains ACP address information of ACP nodes across the
nodes lifetime because that ACP address is intended as an identifier nodes lifetime because that ACP address is intended as an identifier
of the ACP node. of the ACP node.
Summary of sections added: Summary of sections added:
o 6.1.3.5/6.1.3.6 (normative): re-enrollment of ACP nodes after o 6.1.3.5/6.1.3.6 (normative): re-enrollment of ACP nodes after
certificate exiry/failure in a way that allows to maintain as much certificate expiry/failure in a way that allows to maintain as
as possible ACP address information. much as possible ACP address information.
o 6.10.7 (normative): defines "ACP Registrar" including requirements o 6.10.7 (normative): defines "ACP Registrar" including requirements
and how it can perform ACP address assignment. and how it can perform ACP address assignment.
o 10.3 (informative): details / examples about registrars to help o 10.3 (informative): details / examples about registrars to help
implementers and operators understand easier how they operate, and implementers and operators understand easier how they operate, and
provide suggestion of models that a likely very ueful (sub-CA and/ provide suggestion of models that a likely very useful (sub-CA
or centralized policy manaement). and/or centralized policy management).
o 10.4 (informative): Explains the need for the multiple address o 10.4 (informative): Explains the need for the multiple address
sub-spaces defined in response to discuss with Joel. sub-spaces defined in response to discuss with Joel.
Other changes: Other changes:
Updated references (RFC8366, RFC8368). Updated references (RFC8366, RFC8368).
Introduced sub-section headings for 6.1.3 (certificate maintenance) Introduced sub-section headings for 6.1.3 (certificate maintenance)
because section became too long with newly added sub-sections. Also because section became too long with newly added sub-sections. Also
skipping to change at page 111, line 22 skipping to change at page 111, line 14
[RFC Editor: how can i raise the issue of problematic cross [RFC Editor: how can i raise the issue of problematic cross
references of terms in the terminology section - rendering is references of terms in the terminology section - rendering is
problematic. ]. problematic. ].
4. added explanation for ACP4 (finally). 4. added explanation for ACP4 (finally).
6.1.1 Simplified text in bullet list explaining rfc822 encoding. 6.1.1 Simplified text in bullet list explaining rfc822 encoding.
6.1.3 refined second paragraph defining remembering of previous EST 6.1.3 refined second paragraph defining remembering of previous EST
server and explaiing how to do this with BRSKI. server and explaining how to do this with BRSKI.
9.1 Added paragraph outlining the benefit of the sub-CA Registrar 9.1 Added paragraph outlining the benefit of the sub-CA Registrar
option for supporting partitioned networks. option for supporting partitioned networks.
Roughly 100 more nits/minor fixes throughout the document. See: Roughly 100 more nits/minor fixes throughout the document. See:
https://raw.githubusercontent.com/anima-wg/autonomic-control- https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/master/draft-ietf-anima-autonomic-control-plane/13-elwynd- plane/master/draft-ietf-anima-autonomic-control-plane/13-elwynd-
reply.txt reply.txt
Joel Halpern, review part 2: Joel Halpern, review part 2:
skipping to change at page 112, line 10 skipping to change at page 111, line 50
IOT directorate review from Pascal Thubert: IOT directorate review from Pascal Thubert:
Various Nits/typos. Various Nits/typos.
TBD: Punted wish for mentioning RFC reference titles to RFC editor TBD: Punted wish for mentioning RFC reference titles to RFC editor
for now. for now.
1. Added section 1.1 - applicability, discussing protocol choices 1. Added section 1.1 - applicability, discussing protocol choices
re. applicability to constrained devices (or not). Added notion of re. applicability to constrained devices (or not). Added notion of
TCP/TLS va CoAP/DTLS to section 10.4 in support of this. TCP/TLS via CoAP/DTLS to section 10.4 in support of this.
2. Added in-band / out-of-band into terminology. 2. Added in-band / out-of-band into terminology.
5. Referenced section 8.2 for remote ACP channel configuration. 5. Referenced section 8.2 for remote ACP channel configuration.
6.3 made M_FLOOD periods RECOMMENDED (less guesswork) 6.3 made M_FLOOD periods RECOMMENDED (less guesswork)
6.7.x Clarified conditional nature of MUST for the profile details of 6.7.x Clarified conditional nature of MUST for the profile details of
IPsec parameters (aka: onlt 6.7.3 defines actual MUST for nodes, IPsec parameters (aka: only 6.7.3 defines actual MUST for nodes,
prior notions only define the requirements for IPsec profiles IF prior notions only define the requirements for IPsec profiles IF
IPsec is supported. IPsec is supported.
6.8.1 Moved discussion about IP multicast, IGP, RPL for GRASP into a 6.8.1 Moved discussion about IP multicast, IGP, RPL for GRASP into a
new subsection in the informative part (section 10) to tighten up new subsection in the informative part (section 10) to tighten up
text in normative part. text in normative part.
6.10.1 added another reference to stable-connectivity for interop 6.10.1 added another reference to stable-connectivity for interop
with IPv4 management. with IPv4 management.
skipping to change at page 112, line 41 skipping to change at page 112, line 32
discus of ULA with L=1, but term actually not defined in rfc4193, so discus of ULA with L=1, but term actually not defined in rfc4193, so
mentioning it is just confusing/redundant. Also added note about the mentioning it is just confusing/redundant. Also added note about the
random hash being defined in this document, not using SHA1 from random hash being defined in this document, not using SHA1 from
rfc4193. rfc4193.
6.11.1.1 added suggested text about mechanisms to further reduce 6.11.1.1 added suggested text about mechanisms to further reduce
opportunities for loop during reconvergence (active signaling options opportunities for loop during reconvergence (active signaling options
from RFC6550). from RFC6550).
6.11.1.3 made mode 2 MUST and mode 2 MAY (RPL MOP - mode of 6.11.1.3 made mode 2 MUST and mode 2 MAY (RPL MOP - mode of
operations). Removes ambiguity ambiguity. operations). Removes ambiguity.
6.12.5 Added recommendation for RFC4429 (optimistic DAD). 6.12.5 Added recommendation for RFC4429 (optimistic DAD).
Nits from Benjamin Kaduk: dTLS -> DTLS: Nits from Benjamin Kaduk: dTLS -> DTLS:
Review from Joel Halpern: Review from Joel Halpern:
1. swapped order of "purposes" for ACP to match order in section 3. 1. swapped order of "purposes" for ACP to match order in section 3.
1. Added notion about manageability of ACP gong beyond RFC7575 1. Added notion about manageability of ACP gong beyond RFC7575
(before discussion of stable connectivity). (before discussion of stable connectivity).
2. Changed definition of Intent to be same as reference model 2. Changed definition of Intent to be same as reference model
(policy lanuage instead of API). (policy language instead of API).
6.1.1 changed BNF specification so that a local-part without acp- 6.1.1 changed BNF specification so that a local-part without acp-
address (for future extensions) would not be rfcSELF.+rsub but address (for future extensions) would not be rfcSELF.+rsub but
simpler rfcSELF+rsub. Added explanation why rsub is in local-part. simpler rfcSELF+rsub. Added explanation why rsub is in local-part.
Tried to eliminate unnecessary references to VRF to minimize Tried to eliminate unnecessary references to VRF to minimize
assumption how system is designed. assumption how system is designed.
6.1.3 Explained how to make CDP reachable via ACP. 6.1.3 Explained how to make CDP reachable via ACP.
6.7.2 Made it clearer that constrained devices MUST support DTLS if 6.7.2 Made it clearer that constrained devices MUST support DTLS if
they can not support IPsec. they cannot support IPsec.
6.8.2.1 clarified first paragraph (TCP restransmissions lightweight). 6.8.2.1 clarified first paragraph (TCP retransmissions lightweight).
6.11.1 fixed up RPL profile text - to remove "VRF". Text was also 6.11.1 fixed up RPL profile text - to remove "VRF". Text was also
buggy. mentioned control plane, but its a forwarding/silicon issue to buggy. mentioned control plane, but it's a forwarding/silicon issue
have these header. to have these header.
6.12.5 Clarified how link-local ACP channel address can be derived, 6.12.5 Clarified how link-local ACP channel address can be derived,
and how not. and how not.
8.2.1 Fixed up text to distinguish between configuration and model 8.2.1 Fixed up text to distinguish between configuration and model
describing parameters of the configuration (spec only provides describing parameters of the configuration (spec only provides
parameter model). parameter model).
Various Nits. Various Nits.
skipping to change at page 114, line 11 skipping to change at page 113, line 49
wasn't so horrible that you really only want to avoid using them (all wasn't so horrible that you really only want to avoid using them (all
the way after a lot of text like references that stop most readers the way after a lot of text like references that stop most readers
from proceeding any further). from proceeding any further).
14.22. draft-ietf-anima-autonomic-control-plane-16 14.22. draft-ietf-anima-autonomic-control-plane-16
Mirja Kuehlewind: Mirja Kuehlewind:
Tightened requirements for ACP related GRASP objective timers. Tightened requirements for ACP related GRASP objective timers.
Better text to introduce/explaine baseline and constrained ACP Better text to introduce/explains baseline and constrained ACP
profiles. profiles.
IANA guideline: MUST only accept extensible last allocation for IANA guideline: MUST only accept extensible last allocation for
address sub-scheme. address sub-scheme.
Moved section 11 into appendix. Moved section 11 into appendix.
Warren Kumari: Warren Kumari:
Removed "global routing table", replacced with "Data-Plane routing Removed "global routing table", replaced with "Data-Plane routing
(and forwarding) tables. (and forwarding) tables.
added text to indicate how routing protocols do like to have data- added text to indicate how routing protocols do like to have data-
plane dependencies. plane dependencies.
Changed power consumption section re. admin-down state. Power needed Changed power consumption section re. admin-down state. Power needed
to bring up such interfaces make t inappropriate to probe. Need to to bring up such interfaces make t inappropriate to probe. Need to
think more about best sugests -> beyond scope. think more about best suggests -> beyond scope.
Replaced "console" with out-of-band... (console/management ethernet). Replaced "console" with out-of-band... (console/management ethernet).
Various nits. Various nits.
Joel Halpern: Joel Halpern:
Fixed up domain information field ABNF to eliminate confusion that Fixed up domain information field ABNF to eliminate confusion that
rsub is not an FQDN but only a prefix to routing-subdomain. rsub is not an FQDN but only a prefix to routing-subdomain.
skipping to change at page 115, line 6 skipping to change at page 114, line 44
Fixed pagination for "ACP as security and transport substrate for Fixed pagination for "ACP as security and transport substrate for
GRASP" picture. GRASP" picture.
14.23. draft-ietf-anima-autonomic-control-plane-17 14.23. draft-ietf-anima-autonomic-control-plane-17
Review Alissa Cooper: Review Alissa Cooper:
Main discuss point fixed by untangling two specific node type cases: Main discuss point fixed by untangling two specific node type cases:
NOC nodes have ACP domain cert without acp-address field. Are ACP NOC nodes have ACP domain cert without acp-address field. Are ACP
domain members, but can not build ACP secure channels (just end-to- domain members, but cannot build ACP secure channels (just end-to-end
end or nay other authentications. or nay other authentications.
ACP nodes may have other methods to assign ACP address than getting ACP nodes may have other methods to assign ACP address than getting
it through the cert. This is indicated through new vlue 0 for acp- it through the cert. This is indicated through new value 0 for acp-
address in certificate. address in certificate.
Accordingly modified texts in ABNF/explanation and Cert-Check Accordingly modified texts in ABNF/explanation and Cert-Check
section. section.
Other: Other:
Better separation of normative text and considerations for "future" Better separation of normative text and considerations for "future"
work: work:
- Marked missing chapters as Informative. Reworded requirements - Marked missing chapters as Informative. Reworded requirements
section to indicate its informative nature, changed reqirements to section to indicate its informative nature, changed requirements to
_MUST_/_SHOULD_ to indicate these are not RFC2119 requirements but _MUST_/_SHOULD_ to indicate these are not RFC2119 requirements but
that this requirements section is really just in place of a separate that this requirements section is really just in place of a separate
solutions requirements document (that ANIMA was not allowed to solutions requirements document (that ANIMA was not allowed to
produce). produce).
- removed ca. 20 instances of "futures" in normative part of - removed ca. 20 instances of "futures" in normative part of
document. document.
- moved important instances of "futures" into new section A.10 (last - moved important instances of "futures" into new section A.10 (last
section of appendix). These serve as reminder os work discussed section of appendix). These serve as reminder of work discussed
dduring WG but not able to finish specifying it. during WG but not able to finish specifying it.
Eliminated perception that "rsub" (routing subdomain) is only Eliminated perception that "rsub" (routing subdomain) is only
beneficial with future work. Example in A.7. beneficial with future work. Example in A.7.
Added RFC-editor note re formatting of references to terms defined in Added RFC-editor note re formatting of references to terms defined in
terminology section. terminology section.
Using now correct RFC 8174 boilerplate. Using now correct RFC 8174 boilerplate.
Clarified semantic and use of manual ACP sub-scheme. Not used in Clarified semantic and use of manual ACP sub-scheme. Not used in
certificates, only assigned via traditional methods. Use for ACP- certificates, only assigned via traditional methods. Use for ACP-
connect subnets or the like. connect subnets or the like.
Corrected text about Data-Plane dependencies of ACP. Appropriate Corrected text about Data-Plane dependencies of ACP. Appropriate
implementations can be fully data-plane independent (without more implementations can be fully data-plane independent (without more
spec work) if not sharing link-local address with Data-Plane. 6.12.2 spec work) if not sharing link-local address with Data-Plane. 6.12.2
text updated to discuss those (MAC address), A.10.2 discusses options text updated to discuss those (MAC address), A.10.2 discusses options
that would require new standards work. that would require new standards work.
Moved all text about Intent into A.8 to clearl mark it as futures. Moved all text about Intent into A.8 to clearly mark it as futures.
Changed suggestion of future insecure ACP option to future "end-to- Changed suggestion of future insecure ACP option to future "end-to-
end-security-only" option. end-security-only" option.
Various textual fixes. Various textual fixes.
Gen-ART review by Elwyn Davies: Gen-ART review by Elwyn Davies:
Some fixes also mentioned by Alissa. Some fixes also mentioned by Alissa.
skipping to change at page 116, line 36 skipping to change at page 116, line 25
Moved RFC-editor request for better first RFC reference closer to the Moved RFC-editor request for better first RFC reference closer to the
top of the document. top of the document.
Fixed typo /126 -> 127 for prefix length with zone address scheme. Fixed typo /126 -> 127 for prefix length with zone address scheme.
Overlooked early SecDir review from frank.xialiang@huawei.com: Overlooked early SecDir review from frank.xialiang@huawei.com:
most issues fixed through other review in -16. Added reference to most issues fixed through other review in -16. Added reference to
self-protection section 9.2 into security considerations section. self-protection section 9.2 into security considerations section.
14.24. draft-ietf-anima-autonomic-control-plane-18
Too many word/grammar mistakes in -17.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
skipping to change at page 123, line 52 skipping to change at page 123, line 37
[1] https://en.wikipedia.org/wiki/Operational_Technology [1] https://en.wikipedia.org/wiki/Operational_Technology
[2] https://en.wikipedia.org/wiki/Single-root_input/ [2] https://en.wikipedia.org/wiki/Single-root_input/
output_virtualization output_virtualization
Appendix A. Background and Futures (Informative) Appendix A. Background and Futures (Informative)
The following sections discuss additional background information The following sections discuss additional background information
about aspects of the normative parts of this document or associated about aspects of the normative parts of this document or associated
mechanisms such as BRSKI (such as why specific choices where made by mechanisms such as BRSKI (such as why specific choices were made by
the ACP) and they provide discussion about possble future variations the ACP) and they provide discussion about possible future variations
of the ACP. of the ACP.
A.1. ACP Address Space Schemes A.1. ACP Address Space Schemes
This document defines the Zone, Vlong and Manual sub address schemes This document defines the Zone, Vlong and Manual sub address schemes
primarily to support address prefix assignment via distributed, primarily to support address prefix assignment via distributed,
potentially uncoordinated ACP registrars as defined in potentially uncoordinated ACP registrars as defined in
Section 6.10.7. This costs 48/46 bit identifier so that these ACP Section 6.10.7. This costs 48/46-bit identifier so that these ACP
registrar can assign non-conflicting address prefixes. This design registrar can assign non-conflicting address prefixes. This design
does not leave enough bits to simultaneously support a large number does not leave enough bits to simultaneously support a large number
of nodes (Node-ID) plus a large prefix of local addresses for every of nodes (Node-ID) plus a large prefix of local addresses for every
node plus a large enough set of bits to identify a routing Zone. In node plus a large enough set of bits to identify a routing Zone. In
result, Zone, Vlong 8/16 attempt to support all features, but in via result, Zone, Vlong 8/16 attempt to support all features, but in via
separate prefixes. separate prefixes.
In networks that always expect to rely on a centralized PMS as In networks that always expect to rely on a centralized PMS as
described above (Section 10.2.5), the 48/46 bits for the Registrar-ID described above (Section 10.2.5), the 48/46-bits for the Registrar-ID
could be saved. Such variations of the ACP addressing mecchanisms could be saved. Such variations of the ACP addressing mechanisms
could be introduct through future work in different ways. If the could be introduced through future work in different ways. If the
prefix rfcSELF in the ACP information field was changed, incompatible prefix rfcSELF in the ACP information field was changed, incompatible
ACP variations could be created where every design aspect of the ACP ACP variations could be created where every design aspect of the ACP
could be changed. Including all addressing choices. If instead a could be changed. Including all addressing choices. If instead a
new addressing sub-type would be defined, it could be a backward new addressing sub-type would be defined, it could be a backward
compatible extension of this ACP specification. Information such as compatible extension of this ACP specification. Information such as
the size of a zone-prefix and the length of the prefix assigned to the size of a zone-prefix and the length of the prefix assigned to
the ACP node itself could be encoded via the extension field of the the ACP node itself could be encoded via the extension field of the
ACP domain information. ACP domain information.
Note that an explicitly defined "Manual" addressing sub-scheme is Note that an explicitly defined "Manual" addressing sub-scheme is
always beneficial to provide an easy way for ACP nodes to prohibit always beneficial to provide an easy way for ACP nodes to prohibit
incorrect manual configuration of any non-"Manual" ACP address spaces incorrect manual configuration of any non-"Manual" ACP address spaces
and therefore ensure hat "Manual" operations will never impact and therefore ensure that "Manual" operations will never impact
correct routing for any non-"Manual" ACP addresses assigned via ACP correct routing for any non-"Manual" ACP addresses assigned via ACP
domain certificates. domain certificates.
A.2. BRSKI Bootstrap (ANI) A.2. BRSKI Bootstrap (ANI)
[I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes
with an IDevID certificate can securely and zero-touch enroll with a with an IDevID certificate can securely and zero-touch enroll with a
domain certificate (LDevID) to support the ACP. BRSKI also leverages domain certificate (LDevID) to support the ACP. BRSKI also leverages
the ACP to enable zero-touch bootstrap of new nodes across networks the ACP to enable zero-touch bootstrap of new nodes across networks
without any configuration requirements across the transit nodes without any configuration requirements across the transit nodes
skipping to change at page 130, line 24 skipping to change at page 129, line 50
future requirements for ACP secure channel negotiation: future requirements for ACP secure channel negotiation:
Consider the simple case where the use of native IPsec vs. IPsec via Consider the simple case where the use of native IPsec vs. IPsec via
GRE is to be negotiated and the objective is the maximum throughput. GRE is to be negotiated and the objective is the maximum throughput.
Both sides would indicate some agreed upon performance metric and the Both sides would indicate some agreed upon performance metric and the
preferred encapsulation is the one with the higher performance of the preferred encapsulation is the one with the higher performance of the
slower side. IKEv2 does not support negotiation with this objective. slower side. IKEv2 does not support negotiation with this objective.
Consider DTLS and some form of MacSec are to be added as negotiation Consider DTLS and some form of MacSec are to be added as negotiation
options - and the performance objective should work across all IPsec, options - and the performance objective should work across all IPsec,
dDTLS and MacSec options. In the case of MacSEC, the negotiation DTLS and MacSec options. In the case of MacSEC, the negotiation
would also need to determine a key for the peering. It is unclear if would also need to determine a key for the peering. It is unclear if
it would be even appropriate to consider extending the scope of it would be even appropriate to consider extending the scope of
negotiation in IKEv2 to those cases. Even if feasible to define, it negotiation in IKEv2 to those cases. Even if feasible to define, it
is unclear if implementations of IKEv2 would be eager to adopt those is unclear if implementations of IKEv2 would be eager to adopt those
type of extension given the long cycles of security testing that type of extension given the long cycles of security testing that
necessarily goes along with core security protocols such as IKEv2 necessarily goes along with core security protocols such as IKEv2
implementations. implementations.
A more modular alternative to extending IKEv2 could be to layer a A more modular alternative to extending IKEv2 could be to layer a
modular negotiation mechanism on top of the multitude of existing or modular negotiation mechanism on top of the multitude of existing or
skipping to change at page 133, line 5 skipping to change at page 132, line 32
For example, Intent could indicate the desire to build an ACP across For example, Intent could indicate the desire to build an ACP across
all domains that have a common parent domain (without relying on the all domains that have a common parent domain (without relying on the
rsub/routing-subdomain solution defined in this document). For rsub/routing-subdomain solution defined in this document). For
example ACP nodes with domain "example.com", nodes of "example.com", example ACP nodes with domain "example.com", nodes of "example.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. should all establish one single ACP.
If each domain has its own source of Intent, then the Intent would If each domain has its own source of Intent, then the Intent would
simply have to allow adding the peer domains trust anchors (CA) and simply have to allow adding the peer domains trust anchors (CA) and
domain names to the ACP domain membership check (Section 6.1.2) so domain names to the ACP domain membership check (Section 6.1.2) so
that nodes from those other nodes are accepted as ACP peers. that nodes from those other domains are accepted as ACP peers.
If this Intent was to be originated only from one domain, it could If this Intent was to be originated only from one domain, it could
likely not be made to work because the other domains will not build likely not be made to work because the other domains will not build
any ACP connection amongst each other, whether they use the same or any ACP connection amongst each other, whether they use the same or
different CA due to the ACP domain membership check. different CA due to the ACP domain membership check.
If the domains use the same CA one could change the ACP setup to If the domains use the same CA one could change the ACP setup to
permit for the ACP to be established between the two ACP nodes even permit for the ACP to be established between two ACP nodes with
when the acp-domain-names of the peers are different, but only for different acp-domain-names, but only for the purpose of disseminating
the purpose of disseminating limited information, such as Intent, but limited information, such as Intent, but not to set up full ACP
not to set up full ACP connectivity, specifically not RPL routing and connectivity, specifically not RPL routing and passing of arbitrary
passing of arbitrary GRASP information. Unless the Intent policies GRASP information. Unless the Intent policies permit this to happen
permit this to happen across domain boundaries. across domain boundaries.
This type of approach where the ACP first allows Intent to operate This type of approach where the ACP first allows Intent to operate
and only then sets up the rest of ACP connectivity based on Intent and only then sets up the rest of ACP connectivity based on Intent
policy could also be used to enable Intent policies that would limit policy could also be used to enable Intent policies that would limit
functionality across the ACP inside a domain, as long as no policy functionality across the ACP inside a domain, as long as no policy
would disturb the operations of Intent. For example to limit would disturb the distribution of Intent. For example to limit
reachability across the ACP to certain type of nodes or locations of reachability across the ACP to certain type of nodes or locations of
nodes. nodes.
A.9. Adopting ACP concepts for other environments A.9. Adopting ACP concepts for other environments
The ACP as specified in this document is very explicit about the The ACP as specified in this document is very explicit about the
choice of options to allow interoperable implementations. The choice of options to allow interoperable implementations. The
choices made may not be the best for all environments, but the choices made may not be the best for all environments, but the
concepts used by the ACP can be used to build derived solutions: concepts used by the ACP can be used to build derived solutions:
skipping to change at page 135, line 8 skipping to change at page 134, line 36
the certificate. Parameters in certificates should be limited to the certificate. Parameters in certificates should be limited to
those that would not need to be changed more often than certificates those that would not need to be changed more often than certificates
would need to be updated anyhow; Or by ensuring that these parameters would need to be updated anyhow; Or by ensuring that these parameters
can be provisioned before the variation of an ACP is activated in a can be provisioned before the variation of an ACP is activated in a
node. Using BRSKI, this could be done for example as additional node. Using BRSKI, this could be done for example as additional
follow-up signaling directly after the certificate enrollment, still follow-up signaling directly after the certificate enrollment, still
leveraging the BRSKI TLS connection and therefore not introducing any leveraging the BRSKI TLS connection and therefore not introducing any
additional connectivity requirements. additional connectivity requirements.
Last but not least, secure channel protocols including their Last but not least, secure channel protocols including their
encapsulation are easily added to ACP solutions. ACP hop-by-hop encapsulations are easily added to ACP solutions. ACP hop-by-hop
network layer secure channels could also be replaced by end-to-end network layer secure channels could also be replaced by end-to-end
security plus other means for infrastructure protection. Any future security plus other means for infrastructure protection. Any future
network OAM should always use end-to-end security anyhow and can network OAM should always use end-to-end security anyhow and can
leverage the domain certificates and is therefore not dependent on leverage the domain certificates and is therefore not dependent on
security to be provided for by ACP secure channels. security to be provided for by ACP secure channels.
A.10. Further options / futures A.10. Further options / futures
A.10.1. Auto-aggregation of routes A.10.1. Auto-aggregation of routes
Routing in the ACP according to this specification only leverages the Routing in the ACP according to this specification only leverages the
standard RPL mechanism of route optimization, e.g. keeping only standard RPL mechanism of route optimization, e.g. keeping only
routes that are not towards the RPL root. This is known to scale to routes that 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 networks with 20,000 or more nodes. There is no auto-aggregation of
routes for /48 ULA prefixes (when using rsub in the domain routes for /48 ULA prefixes (when using rsub in the domain
information field) and/or Zone-ID based prefixes. information field) and/or Zone-ID based prefixes.
Automatic assignment of Zone-ID and auto-aggregation of routes could Automatic assignment of Zone-ID and auto-aggregation of routes could
be achieved for example by configuring zone-boundaries, announcing be achieved for example by configuring zone-boundaries, announcing
via GRASP into the zones the zone parameters (zone-ID and /48 ULA via GRASP into the zones the zone parameters (zone-ID and /48 ULA
prefix) and auto-aggrating routes on the zone-boundaries. Nodes prefix) and auto-aggegating routes on the zone-boundaries. Nodes
would assign their Zone-ID and potentially even /48 prefix based on would assign their Zone-ID and potentially even /48 prefix based on
the GRASP announcements. the GRASP announcements.
A.10.2. More options for avoiding IPv6 Data-Plane dependency A.10.2. More options for avoiding IPv6 Data-Plane dependency
As described in Section 6.12.2, the ACP depends on the Data-Plane to As described in Section 6.12.2, the ACP depends on the Data-Plane to
establish IPv6 link-local addressing on interfaces. Using a separate establish IPv6 link-local addressing on interfaces. Using a separate
MAC address for the ACP allows to fully isolate the ACP from the data MAC address for the ACP allows to fully isolate the ACP from the data
plane in a way that is compatible with this specification. It is plane in a way that is compatible with this specification. It is
also an ideal option when using Single-root input/output also an ideal option when using Single-root input/output
virtualization (SR-IOV) in an implementation to isolate the ACP virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single-
(https://en.wikipedia.org/wiki/Single-root_input/ root_input/output_virtualization [2]) in an implementation to isolate
output_virtualization [2]) because different SR-IOV interfaces use the ACP because different SR-IOV interfaces use different MAC
different MAC addresses. addresses.
When additional MAC address(es) are not available to the ACP, When additional MAC address(es) are not available, separation of the
separation of the ACP could be done at different demux points. The ACP could be done at different demux points. The same subnet
same subnet interface could have a separate IPv6 IPv6 interface for interface could have a separate IPv6 interface for the ACP and Data-
the ACP and Data-Plane and therefore separate link-local addresses Plane and therefore separate link-local addresses for both, where the
for both, where the ACP interface is non-configurable on the data- ACP interface is non-configurable on the Data-Plane. This too would
plane. This too would be compatible with this specification and not be compatible with this specification and not impact
impact interoperability. interoperability.
An option that would require additional specification is to use a An option that would require additional specification is to use a
different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets
for the ACP. This would be a similar approach as used for IP for the ACP. This would be a similar approach as used for IP
authentication packets in [IEEE-802.1X] that they use the Extensible authentication packets in [IEEE-802.1X] which use the Extensible
Authentication Protocol over Local Area Network (EAPoL) ethertype Authentication Protocol over Local Area Network (EAPoL) ethertype
(0x88A2). (0x88A2).
Note that in the case of ANI nodes, all the above considerations Note that in the case of ANI nodes, all the above considerations
equally apply to the encapsulation of BRSKI packets including GRASP equally apply to the encapsulation of BRSKI packets including GRASP
used for BRSKI. used for BRSKI.
A.10.3. ACP APIs and operational models (YANG) A.10.3. ACP APIs and operational models (YANG)
Future work should define YANG ([RFC7950]) data model and/or node Future work should define YANG ([RFC7950]) data model and/or node
internal APIs to monitor and manage the ACP. internal APIs to monitor and manage the ACP.
The elements to include into this model/API include the ACP Adjacency Support for the ACP Adjacency Table (Section 6.2) and ACP GRASP need
Table (Section 6.2) and ACP GRASP. to be included into such model/API.
A.10.4. RPL enhancements A.10.4. RPL enhancements
..... USA ...... ..... Europe ...... ..... USA ...... ..... Europe ......
NOC1 NOC2 NOC1 NOC2
| | | |
| metric 100 | | metric 100 |
ACP1 --------------------------- ACP2 . ACP1 --------------------------- ACP2 .
| | . WAN | | . WAN
skipping to change at page 136, line 44 skipping to change at page 136, line 25
| | . | | .
ACP3 --------------------------- ACP4 . ACP3 --------------------------- ACP4 .
| metric 100 | | metric 100 |
| | . | | .
| | . Sites | | . Sites
ACP10 ACP11 . ACP10 ACP11 .
Figure 16: Dual NOC Figure 16: Dual NOC
The profile for RPL specified in this document builds only one The profile for RPL specified in this document builds only one
spanning-tree pathset to a root (NOC). In the presence of multiple spanning-tree path set to a root (NOC). In the presence of multiple
NOCs, routing toward the non-root NOCs may be suboptimal. Figure 16 NOCs, routing toward the non-root NOCs may be suboptimal. Figure 16
shows an extreme example. Assuming that node ACP1 becomes the RPL shows an extreme example. Assuming that node ACP1 becomes the RPL
root, traffic between ACP11 and NOC2 will pass through root, traffic between ACP11 and NOC2 will pass through
ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated
DODAG/routes are shortest paths towards the RPL root. DODAG/routes are shortest paths towards the RPL root.
To overcome these limitations, extensions/modifications to the RPL To overcome these limitations, extensions/modifications to the RPL
profile can provide optimality for multiple NOCs. This requires profile can provide optimality for multiple NOCs. This requires
utilizing Data-Plane artifact including IPinIP encap/decap on ACP utilizing Data-Plane artifact including IPinIP encap/decap on ACP
routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst)
skipping to change at page 137, line 24 skipping to change at page 137, line 4
A.10.5. Role assignments A.10.5. Role assignments
ACP connect is an explicit mechanism to "leak" ACP traffic explicitly ACP connect is an explicit mechanism to "leak" ACP traffic explicitly
(for example in a NOC). It is therefore also a possible security gap (for example in a NOC). It is therefore also a possible security gap
when it is easy to enable ACP connect on arbitrary compromised ACP when it is easy to enable ACP connect on arbitrary compromised ACP
nodes. nodes.
One simple solution is to define an extension in the ACP certificates One simple solution is to define an extension in the ACP certificates
ACP information field indicating the permission for ACP connect to be ACP information field indicating the permission for ACP connect to be
configured on that ACP node. This could similarily be done to decide configured on that ACP node. This could similarly be done to decide
whether a node is permitted to be a registrar or not. whether a node is permitted to be a registrar or not.
Tying the permitted "roles" of an ACP node to the ACP domain Tying the permitted "roles" of an ACP node to the ACP domain
certificate provides fairly strong protection against certificate provides fairly strong protection against
misconfiguration, but is still subject to code modifications. misconfiguration, but is still subject to code modifications.
Another interesting role to assign to certificates is that of a NOC Another interesting role to assign to certificates is that of a NOC
node. This would allow to limit certain type of connections such as node. This would allow to limit certain type of connections such as
OAM TLS connections to only NOC initiator or responders. OAM TLS connections to only NOC initiator or responders.
A.10.6. Autonomic L3 transit A.10.6. Autonomic L3 transit
In this specification, the ACP can only establish autonomic In this specification, the ACP can only establish autonomic
connectivity across L2 hops and only explicitly confiured options to connectivity across L2 hops and only explicitly configured options to
tunnel across L3. Future work should specify mechanisms to tunnel across L3. Future work should specify mechanisms to
automatically tunnel ACP across L3 networks. A hub&spoke option automatically tunnel ACP across L3 networks. A hub&spoke option
would allow to tunnel across the Internet to a cloud or central would allow to tunnel across the Internet to a cloud or central
instance of the ACP, a peer-to-peer tunneling mechanism could tunnel instance of the ACP, a peer-to-peer tunneling mechanism could tunnel
ACP islands across an L3VPN infrastructure. ACP islands across an L3VPN infrastructure.
A.10.7. Diagnostics A.10.7. Diagnostics
Section 10.1 describes diagnostics options that can be done without Section 10.1 describes diagnostics options that can be done without
changing the external, interoperability affecting characteristics of changing the external, interoperability affecting characteristics of
ACP implementation. ACP implementations.
Even better diagnostics of ACP operations is possible with additional Even better diagnostics of ACP operations is possible with additional
signaling extensions, such as: signaling extensions, such as:
1. Consider if LLDP should be a recommended functionality for ANI 1. Consider if LLDP should be a recommended functionality for ANI
devices to improve diagnostics, and if so, which information devices to improve diagnostics, and if so, which information
elements it should signal (insecure). Includes potentially new elements it should signal (insecure). Includes potentially new
information elements. information elements.
2. In alternative to LLDP, A DULL GRASP diagnostics objective could 2. In alternative to LLDP, A DULL GRASP diagnostics objective could
 End of changes. 148 change blocks. 
220 lines changed or deleted 225 lines changed or added

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