< draft-ietf-anima-autonomic-control-plane.txt   draft-ietf-anima-autonomic-control-plane.txt >
skipping to change at page 3, line 8 skipping to change at page 3, line 8
6.8. Security Association (Secure Channel) protocols . . . . . 49 6.8. Security Association (Secure Channel) protocols . . . . . 49
6.8.1. General considerations . . . . . . . . . . . . . . . 50 6.8.1. General considerations . . . . . . . . . . . . . . . 50
6.8.2. Common requirements . . . . . . . . . . . . . . . . . 51 6.8.2. Common requirements . . . . . . . . . . . . . . . . . 51
6.8.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 52 6.8.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 52
6.8.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 52 6.8.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 52
6.8.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 53 6.8.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 53
6.8.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 54 6.8.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 54
6.8.3.2. IPsec with GRE encapsulation . . . . . . . . . . 55 6.8.3.2. IPsec with GRE encapsulation . . . . . . . . . . 55
6.8.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 56 6.8.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 56
6.8.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 58 6.8.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 58
6.9. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 58 6.9. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 59
6.9.1. GRASP as a core service of the ACP . . . . . . . . . 58 6.9.1. GRASP as a core service of the ACP . . . . . . . . . 59
6.9.2. ACP as the Security and Transport substrate for 6.9.2. ACP as the Security and Transport substrate for
GRASP . . . . . . . . . . . . . . . . . . . . . . . . 59 GRASP . . . . . . . . . . . . . . . . . . . . . . . . 59
6.9.2.1. Discussion . . . . . . . . . . . . . . . . . . . 62 6.9.2.1. Discussion . . . . . . . . . . . . . . . . . . . 62
6.10. Context Separation . . . . . . . . . . . . . . . . . . . 63 6.10. Context Separation . . . . . . . . . . . . . . . . . . . 63
6.11. Addressing inside the ACP . . . . . . . . . . . . . . . . 63 6.11. Addressing inside the ACP . . . . . . . . . . . . . . . . 63
6.11.1. Fundamental Concepts of Autonomic Addressing . . . . 63 6.11.1. Fundamental Concepts of Autonomic Addressing . . . . 63
6.11.2. The ACP Addressing Base Scheme . . . . . . . . . . . 65 6.11.2. The ACP Addressing Base Scheme . . . . . . . . . . . 65
6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 67 6.11.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 67
6.11.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 68 6.11.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 68
6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ 6.11.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/
skipping to change at page 5, line 24 skipping to change at page 5, line 24
15.1.3. Normative enhancements since start of IESG review . 132 15.1.3. Normative enhancements since start of IESG review . 132
15.1.4. Explanatory enhancements since start of IESG 15.1.4. Explanatory enhancements since start of IESG
review . . . . . . . . . . . . . . . . . . . . . . . 133 review . . . . . . . . . . . . . . . . . . . . . . . 133
15.2. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 134 15.2. draft-ietf-anima-autonomic-control-plane-29 . . . . . . 134
15.3. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 137 15.3. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 137
15.4. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 138 15.4. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 138
15.5. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 138 15.5. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 138
15.6. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 139 15.6. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 139
15.7. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 143 15.7. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 143
15.8. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 143 15.8. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 143
15.9. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 144 15.9. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 145
16. Normative References . . . . . . . . . . . . . . . . . . . . 146 16. Normative References . . . . . . . . . . . . . . . . . . . . 147
17. Informative References . . . . . . . . . . . . . . . . . . . 150 17. Informative References . . . . . . . . . . . . . . . . . . . 150
Appendix A. Background and Futures (Informative) . . . . . . . . 158 Appendix A. Background and Futures (Informative) . . . . . . . . 158
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 158 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 158
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 158 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 159
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 160 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 160
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 160 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 160
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 160 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 161
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 160 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 161
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 161 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 161
A.5. ACP Information Distribution and multicast . . . . . . . 162 A.5. ACP Information Distribution and multicast . . . . . . . 163
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 163 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 164
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 165 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 166
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 166 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 167
A.9. Adopting ACP concepts for other environments . . . . . . 167 A.9. Adopting ACP concepts for other environments . . . . . . 168
A.10. Further (future) options . . . . . . . . . . . . . . . . 169 A.10. Further (future) options . . . . . . . . . . . . . . . . 170
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 169 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 170
A.10.2. More options for avoiding IPv6 Data-Plane A.10.2. More options for avoiding IPv6 Data-Plane
dependencies . . . . . . . . . . . . . . . . . . . . 170 dependencies . . . . . . . . . . . . . . . . . . . . 170
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 170 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 171
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 170 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 171
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 171 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 172
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 172 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 172
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 172 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 172
A.10.8. Avoiding and dealing with compromised ACP nodes . . 173 A.10.8. Avoiding and dealing with compromised ACP nodes . . 173
A.10.9. Detecting ACP secure channel downgrade attacks . . . 174 A.10.9. Detecting ACP secure channel downgrade attacks . . . 174
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 175
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
Networking is given in [RFC7576]. The reference architecture for Networking is given in [RFC7576]. The reference architecture for
Autonomic Networking in the IETF is specified in the document Autonomic Networking in the IETF is specified in the document
[I-D.ietf-anima-reference-model]. [I-D.ietf-anima-reference-model].
skipping to change at page 21, line 43 skipping to change at page 21, line 43
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 specifies the components and steps to set up an ACP. This section specifies the components and steps to set up an ACP.
The ACP is automatically "self-creating", which makes it The ACP is automatically "self-creating", which makes it
"indestructible" against most changes to the Data-Plane, including "indestructible" against most changes to the Data-Plane, including
misconfigurations of routing, addressing, NAT, firewall or any other misconfigurations of routing, addressing, NAT, firewall or any other
traffic policy filters that inadvertently or otherwise unavoidably traffic policy filters that inadvertently or otherwise unavoidably
would also impact the management plane traffic, such as the actual would also impact the management plane traffic, such as the actual
operator CLI session or controller NetConf session through which the operator CLI session or controller NETCONF session through which the
configuration changes to the Data-Plane are executed. configuration changes to the Data-Plane are executed.
Physical misconfiguration of wiring between ACP nodes will also not Physical misconfiguration of wiring between ACP nodes will also not
break the ACP: As long as there is a transitive physical path between break the ACP: As long as there is a transitive physical path between
ACP nodes, the ACP should be able to recover given that it ACP nodes, the ACP should be able to recover given that it
automatically operates across all interfaces of the ACP nodes and automatically operates across all interfaces of the ACP nodes and
automatically determines paths between them. automatically determines paths between them.
Attacks against the network via incorrect routing or addressing Attacks against the network via incorrect routing or addressing
information for the Data-Plane will not impact the ACP. Even information for the Data-Plane will not impact the ACP. Even
skipping to change at page 26, line 10 skipping to change at page 26, line 10
"serialNumber" attribute in the subjects field distinguished name "serialNumber" attribute in the subjects field distinguished name
encoding. Note that this is not the certificate serial number. See encoding. Note that this is not the certificate serial number. See
also [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1. This can also [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1. This can
be done for example if it would be acceptable for the device's be done for example if it would be acceptable for the device's
"serialNumber" to be signalled via the Link Layer Discovery Protocol "serialNumber" to be signalled via the Link Layer Discovery Protocol
(LLDP, [LLDP]) because like LLDP signalled information, the ACP (LLDP, [LLDP]) because like LLDP signalled information, the ACP
certificate information can be retrieved by neighboring nodes without certificate information can be retrieved by neighboring nodes without
further authentication and be used either for beneficial diagnostics further authentication and be used either for beneficial diagnostics
or for malicious attacks. Retrieval of the ACP certificate is or for malicious attacks. Retrieval of the ACP certificate is
possible via a (failing) attempt to set up an ACP secure channel, and possible via a (failing) attempt to set up an ACP secure channel, and
the "serialNumber" contains usually device type information that may the "serialNumber" usually contains device type information that may
help to faster determine working exploits/attacks against the device. help to faster determine working exploits/attacks against the device.
Note that there is no intention to constrain authorization within the Note that there is no intention to constrain authorization within the
ACP or autonomic networks using the ACP to just the ACP domain ACP or autonomic networks using the ACP to just the ACP domain
membership check as defined in this document. It can be extended or membership check as defined in this document. It can be extended or
modified with additional requirements. Such future authorizations modified with additional requirements. Such future authorizations
can use and require additional elements in certificates or policies can use and require additional elements in certificates or policies
or even additional certificates. See the additional check agagainst or even additional certificates. See the additional check agagainst
the id-kp-cmcRA [RFC6402] extended key usage attribute the id-kp-cmcRA [RFC6402] extended key usage attribute
(Section 6.2.5) and for possible future extensions, see (Section 6.2.5) and for possible future extensions, see
skipping to change at page 27, line 35 skipping to change at page 27, line 35
administration of the ACP and ideally reserved to only be used for administration of the ACP and ideally reserved to only be used for
the ACP. In this specification it serves to be a name for the ACP the ACP. In this specification it serves to be a name for the ACP
that ideally is globally unique. When acp-domain-name is a globally that ideally is globally unique. When acp-domain-name is a globally
unique name, collision of ACP addresses across different ACP domains unique name, collision of ACP addresses across different ACP domains
can only happen due to ULA hash collisions (see Section 6.11.2). can only happen due to ULA hash collisions (see Section 6.11.2).
Using different acp-domain-names, operators can distinguish multiple Using different acp-domain-names, operators can distinguish multiple
ACP even when using the same TA. ACP even when using the same TA.
To keep the encoding simple, there is no consideration for To keep the encoding simple, there is no consideration for
internationalized acp-domain-names. The acp-node-name is not internationalized acp-domain-names. The acp-node-name is not
intended for end user consumption, and there is no protection against intended for end user consumption. There is no protection against an
someone not owning a domain name to simply choose it. Instead, it operator to pick any domain name for an ACP whether or not the
serves as a hash seed for the ULA and for diagnostics to the operator can claim to own the domain name. Instead, the domain name
only serves as a hash seed for the ULA and for diagnostics to the
operator. Therefore, any operator owning only an internationalized operator. Therefore, any operator owning only an internationalized
domain name should be able to pick an equivalently unique 7-bit ASCII domain name should be able to pick an equivalently unique 7-bit ASCII
acp-domain-name string representing the internationalized domain acp-domain-name string representing the internationalized domain
name. name.
"routing-subdomain" is a string that can be constructed from the acp- "routing-subdomain" is a string that can be constructed from the acp-
node-name, and it is used in the hash-creation of the ULA (see node-name, and it is used in the hash-creation of the ULA (see
below). The presence of the "rsub" component allows a single ACP below). The presence of the "rsub" component allows a single ACP
domain to employ multiple /48 ULA prefixes. See Appendix A.7 for domain to employ multiple /48 ULA prefixes. See Appendix A.7 for
example use-cases. example use-cases.
skipping to change at page 53, line 18 skipping to change at page 53, line 18
payload), it would only be possible to send packets originated by the payload), it would only be possible to send packets originated by the
ACP node itself because the IPv6 addresses of the ESP must be the ACP node itself because the IPv6 addresses of the ESP must be the
same as that of the outer IPv6 header. same as that of the outer IPv6 header.
6.8.3.1.1. RFC8221 (IPsec/ESP) 6.8.3.1.1. RFC8221 (IPsec/ESP)
ACP IPsec implementations MUST comply with [RFC8221] (and its ACP IPsec implementations MUST comply with [RFC8221] (and its
updates). The requirements from above and this section amend and updates). The requirements from above and this section amend and
superseded its requirements. superseded its requirements.
AH MUST NOT be used (because it does not provide confidentiality). The IP Authentication Header (AH) MUST NOT be used (because it does
not provide confidentiality).
For the required ESP encryption algorithms in section 5 of [RFC8221] For the required ESP encryption algorithms in section 5 of [RFC8221]
the following guidance applies: the following guidance applies:
* ENCR_NULL AH MUST NOT be used (because it does not provide * ENCR_NULL AH MUST NOT be used (because it does not provide
confidentiality). confidentiality).
* ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP * ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP
via IPsec/ESP (it is already listed as MUST in [RFC8221]). via IPsec/ESP (it is already listed as MUST in [RFC8221]).
* ENCR_AES_CBC with AUTH_HMAC_SHA2_256_128 (as the ESP * ENCR_AES_CBC with AUTH_HMAC_SHA2_256_128 (as the ESP
authentication algorithm) and ENCR_AES_CCM_8 MAY be supported. If authentication algorithm) and ENCR_AES_CCM_8 MAY be supported. If
skipping to change at page 56, line 24 skipping to change at page 56, line 24
addr) addr)
If IKEv2 initiator and responder support IPsec over GRE, it will be If IKEv2 initiator and responder support IPsec over GRE, it will be
preferred over native IPsec because of the way how IKEv2 negotiates preferred over native IPsec because of the way how IKEv2 negotiates
transport mode as used by this IPsec over GRE profile) versus tunnel transport mode as used by this IPsec over GRE profile) versus tunnel
mode as used by native IPsec (see [RFC7296], section 1.3.1). The ACP mode as used by native IPsec (see [RFC7296], section 1.3.1). The ACP
IPv6 traffic has to be carried across GRE according to [RFC7676]. IPv6 traffic has to be carried across GRE according to [RFC7676].
6.8.4. ACP via DTLS 6.8.4. ACP via DTLS
This document defines the use of ACP via DTLS in the assumption that This document defines the use of ACP via DTLS, on the assumption that
it is likely the first transport encryption supported in some classes it is likely the first transport encryption supported in some classes
of constrained devices because DTLS is already used in those devices of constrained devices: DTLS is commonly used in constrained devices
but IPsec is not, and code-space may be limited. when IPsec is not. Code-space on those devices may be also be too
limited to support more than the minimum number of required
protocols.
An ACP node announces its ability to support DTLS version 1.2 An ACP node announces its ability to support DTLS version 1.2
([RFC6347]) compliant with the requirements defined in this document ([RFC6347]) compliant with the requirements defined in this document
as an ACP secure channel protocol in GRASP through the "DTLS" as an ACP secure channel protocol in GRASP through the "DTLS"
objective-value in the "AN_ACP" objective (see Section 6.4). objective-value in the "AN_ACP" objective (see Section 6.4).
To run ACP via UDP and DTLS, a locally assigned UDP port is used that To run ACP via UDP and DTLS, a locally assigned UDP port is used that
is announced as a parameter in the GRASP AN_ACP objective to is announced as a parameter in the GRASP AN_ACP objective to
candidate neighbors. This port can also be any newer version of DTLS candidate neighbors. This port can also be any newer version of DTLS
as long as that version can negotiate a DTLS v1.2 connection in the as long as that version can negotiate a DTLS v1.2 connection in the
skipping to change at page 64, line 49 skipping to change at page 64, line 49
reasons: reasons:
* Simplicity, reliability and scale: If other network layer * Simplicity, reliability and scale: If other network layer
protocols were supported, each would have to have its own set of protocols were supported, each would have to have its own set of
security associations, routing table and process, etc. security associations, routing table and process, etc.
* Autonomic functions do not require IPv4: Autonomic functions and * Autonomic functions do not require IPv4: Autonomic functions and
autonomic service agents are new concepts. They can be autonomic service agents are new concepts. They can be
exclusively built on IPv6 from day one. There is no need for exclusively built on IPv6 from day one. There is no need for
backward compatibility. backward compatibility.
* OAM protocols do not require IPv4: The ACP may carry OAM * OAM protocols do not require IPv4: The ACP may carry OAM
protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, RADIUS,
Diameter, ...) are available in IPv6. See also [RFC8368] for how Diameter, NETCONF ...) are available in IPv6. See also [RFC8368]
ACP could be made to interoperate with IPv4 only OAM. for how ACP could be made to interoperate with IPv4 only OAM.
Further explanation about the addressing and routing related reasons Further explanation about the addressing and routing related reasons
for the choice of the autonomous ACP addressing can be found in for the choice of the autonomous ACP addressing can be found in
Section 6.13.5.1. Section 6.13.5.1.
6.11.2. The ACP Addressing Base Scheme 6.11.2. The ACP Addressing Base Scheme
The Base ULA addressing scheme for ACP nodes has the following The Base ULA addressing scheme for ACP nodes has the following
format: format:
skipping to change at page 104, line 47 skipping to change at page 104, line 47
beside a TA is required. Typically, this is a root CA. One or more beside a TA is required. Typically, this is a root CA. One or more
uncoordinated acting ACP registrar can be set up, performing the uncoordinated acting ACP registrar can be set up, performing the
following interactions: following interactions:
To orchestrate enrolling a candidate ACP node autonomically, the ACP To orchestrate enrolling a candidate ACP node autonomically, the ACP
registrar can rely on the ACP and use Proxies to reach the candidate registrar can rely on the ACP and use Proxies to reach the candidate
ACP node, therefore allowing minimum pre-existing (auto-)configured ACP node, therefore allowing minimum pre-existing (auto-)configured
network services on the candidate ACP node. BRSKI defines the BRSKI network services on the candidate ACP node. BRSKI defines the BRSKI
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 TA that has no ACP connectivity, the ACP registrar would To reach a TA that has no ACP connectivity, 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 certificate. enroll (configure) the candidate ACP node with an ACP certificate.
Netconf ZeroTouch ([RFC8572]) is an example protocol that could be NETCONF ZeroTouch ([RFC8572]) is an example protocol that could be
used for this. BRSKI using optional discovery mechanisms is equally used for this. BRSKI using optional discovery mechanisms is equally
a possibility for candidate ACP nodes attempting to be enrolled a possibility for candidate ACP nodes attempting to be enrolled
across non-ACP networks, such as the Internet. across non-ACP networks, such as the Internet.
When candidate ACP nodes have secure bootstrap, such as BRSKI When candidate ACP nodes have secure bootstrap, such as BRSKI
Pledges, they will not trust to be configured/enrolled across the Pledges, they will not trust to be configured/enrolled across the
network, unless being presented with a voucher (see [RFC8366]) network, unless being presented with a voucher (see [RFC8366])
authorizing the network to take possession of the node. An ACP authorizing the network to take possession of the node. An ACP
registrar will then need a method to retrieve such a voucher, either registrar will then need a method to retrieve such a voucher, either
offline, or online from a MASA (Manufacturer Authorized Signing offline, or online from a MASA (Manufacturer Authorized Signing
Authority). BRSKI and Netconf ZeroTouch are two protocols that Authority). BRSKI and NETCONF ZeroTouch are two protocols that
include capabilities to present the voucher to the candidate ACP include capabilities to present the voucher to the candidate ACP
node. node.
An ACP registrar could operate EST for ACP certificate renewal and/or An ACP registrar could operate EST for ACP certificate renewal and/or
act as a CRL Distribution point. A node performing these services act as a CRL Distribution point. A node performing these services
does not need to support performing (initial) enrollment, but it does does not need to support performing (initial) enrollment, but it does
require the same above described connectivity as an ACP registrar: require the same above described connectivity as an ACP registrar:
via the ACP to ACP nodes and via the Data-Plane to the TA and other via the ACP to ACP nodes and via the Data-Plane to the TA and other
sources of CRL information. sources of CRL information.
skipping to change at page 110, line 14 skipping to change at page 110, line 14
An example of non-ACP but ANI traffic that should be permitted to An example of non-ACP but ANI traffic that should be permitted to
pass even in "admin-down" state is BRSKI enrollment traffic between pass even in "admin-down" state is BRSKI enrollment traffic between
BRSKI pledge and a BRSKI proxy. BRSKI pledge and a BRSKI proxy.
As necessary (see discussion below) new configuration options could As necessary (see discussion below) new configuration options could
be introduced to issue "physical down". The options should be be introduced to issue "physical down". The options should be
provided with additional checks to minimize the risk of issuing them provided with additional checks to minimize the risk of issuing them
in a way that breaks the ACP without automatic restoration. For in a way that breaks the ACP without automatic restoration. For
example they could be denied to be issued from a control connection example they could be denied to be issued from a control connection
(netconf/ssh) that goes across the interface itself ("do not (NETCONF/SSH) that goes across the interface itself ("do not
disconnect yourself"). Or they could be performed only temporary and disconnect yourself"). Or they could be performed only temporary and
only be made permanent with additional later reconfirmation. only be made permanent with additional later reconfirmation.
In the following sub-sections important aspects to the introduction In the following sub-sections important aspects to the introduction
of "admin down" state are discussed. of "admin down" state are discussed.
9.3.2.1. Security 9.3.2.1. Security
Interfaces are physically brought down (or left in default down Interfaces are physically brought down (or left in default down
state) as a form of security. "Admin down" state as described above state) as a form of security. "Admin down" state as described above
skipping to change at page 119, line 23 skipping to change at page 119, line 23
Section 9.3. Section 9.3.
* When the ACP needs to be extended across interfacess other than * When the ACP needs to be extended across interfacess other than
L2, the ACP as defined in this document can not autodiscover L2, the ACP as defined in this document can not autodiscover
candidate neighbors automatically. Remote neighbors need to be candidate neighbors automatically. Remote neighbors need to be
configured, see Section 8.2. configured, see Section 8.2.
Once the ACP is operating, any further configuration for the Data- Once the ACP is operating, any further configuration for the Data-
Plane can be configured more reliably across the ACP itself because Plane can be configured more reliably across the ACP itself because
the ACP provides addressing and connectivity (routing) independent of the ACP provides addressing and connectivity (routing) independent of
the Data-Plane itself. For this, the configuration methods simply the Data-Plane itself. For this, the configuration methods simply
need to also allow to operate across the ACP VRF - netconf, ssh or need to also allow to operate across the ACP VRF - NETCONF, SSH or
any other method. any other method.
The ACP also provides additional security through its hop-by-hop The ACP also provides additional security through its hop-by-hop
encryption for any such configuration operations: Some legacy encryption for any such configuration operations: Some legacy
configuration methods (SNMP, TFTP, HTTP) may not use end-to-end configuration methods (SNMP, TFTP, HTTP) may not use end-to-end
encryption, and most of the end-to-end secured configuration methods encryption, and most of the end-to-end secured configuration methods
still allow for easy passive observation along the path about still allow for easy passive observation along the path about
configuration taking place (transport flows, port numbers, IP configuration taking place (transport flows, port numbers, IP
addresses). addresses).
skipping to change at page 122, line 23 skipping to change at page 122, line 23
impaired ACP node supports ACP connect (see Section 8.1) and the impaired ACP node supports ACP connect (see Section 8.1) and the
attacker can control traffic into/from one of the ACP nodes attacker can control traffic into/from one of the ACP nodes
interfaces, such as by having physical access to the ACP node. interfaces, such as by having physical access to the ACP node.
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 fail on some vendor/product/customer limitations. This options fail on some vendor/product/customer limitations. This
includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP
([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog ([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog
([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS ([RFC3164]), RADIUS ([RFC2865]), Diameter ([RFC6733]), TACACS
([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a
few. Not all of these protocol references are necessarily the latest few. Not all of these protocol references are necessarily the latest
version of protocols but versions that are still widely deployed. version of protocols but versions that are still widely deployed.
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-
service attacks. However, as the ACP is built using link-local IPv6 service attacks. However, as the ACP is built using link-local IPv6
addresses, remote attacks from the Data-Plane are impossible as long addresses, remote attacks from the Data-Plane are impossible as long
as the Data-Plane has no facilities to remotely sent IPv6 link-local as the Data-Plane has no facilities to remotely send IPv6 link-local
packets. The only exception are ACP connected interfaces which packets. The only exception are ACP connected interfaces which
require higher physical protection. The ULA addresses are only require higher physical protection. The ULA addresses are only
reachable inside the ACP context, therefore, unreachable from the reachable inside the ACP context, therefore, unreachable from the
Data-Plane. Also, the ACP protocols should be implemented to be Data-Plane. Also, the ACP protocols should be implemented to be
attack resistant and not consume unnecessary resources even while attack resistant and not consume unnecessary resources even while
under attack. under attack.
10.2.2. From the inside 10.2.2. From the inside
The security model of the ACP is based on trusting all members of the The security model of the ACP is based on trusting all members of the
skipping to change at page 127, line 45 skipping to change at page 127, line 45
Mitigation against compromised ACP members is possible through Mitigation against compromised ACP members is possible through
standard automated certificate management mechanisms including standard automated certificate management mechanisms including
revocation and non-renewal of short-lived certificates. In this revocation and non-renewal of short-lived certificates. In this
version of the specification, there are no further optimization of version of the specification, there are no further optimization of
these mechanisms defined for the ACP (but see Appendix A.10.8). these mechanisms defined for the ACP (but see Appendix A.10.8).
Higher layer service built using ACP certificates should not solely Higher layer service built using ACP certificates should not solely
rely on undifferentiated group security when another model is more rely on undifferentiated group security when another model is more
appropriate/more secure. For example central network configuration appropriate/more secure. For example central network configuration
relies on a security model where only few especially trusted nodes relies on a security model where only few especially trusted nodes
are allowed to configure the Data-Plane of network nodes (CLIL, are allowed to configure the Data-Plane of network nodes (CLI,
Netconf). This can be done through ACP certificates by NETCONF). This can be done through ACP certificates by
differentiating them and introduce roles. See Appendix A.10.5. differentiating them and introduce roles. See Appendix A.10.5.
Operators and provisioning software developers need to be aware of Operators and provisioning software developers need to be aware of
how the provisioning/configuration of network devices impacts the how the provisioning/configuration of network devices impacts the
ability of the operator / provisioning software to remotely access ability of the operator / provisioning software to remotely access
the network nodes. By using the ACP, most of the issues of the network nodes. By using the ACP, most of the issues of
configuration/provisioning caused loss of connectivity for remote configuration/provisioning caused loss of connectivity for remote
provisioning/configuration will be eliminated, see Section 6. Only provisioning/configuration will be eliminated, see Section 6. Only
few exceptions such as explicit physical interface down configuration few exceptions such as explicit physical interface down configuration
will be left Section 9.3.2. will be left Section 9.3.2.
skipping to change at page 132, line 15 skipping to change at page 132, line 15
15.1.2. BRSKI / ACP registrar related enhancements 15.1.2. BRSKI / ACP registrar related enhancements
Only after ACP entered IESG review did it become clear that the in- Only after ACP entered IESG review did it become clear that the in-
progress BRSKI document would not provide all the explanations needed progress BRSKI document would not provide all the explanations needed
for ACP registrars as expected earlier by ACP authors. Instead, for ACP registrars as expected earlier by ACP authors. Instead,
BRSKI will only specify a subset of required ACP behavior related to BRSKI will only specify a subset of required ACP behavior related to
certificate handling and registrar. There, it became clear that the certificate handling and registrar. There, it became clear that the
ACP draft should specify generic ACP registrar behavior independent ACP draft should specify generic ACP registrar behavior independent
of BRSKI so ACP could be implemented with or without BRSKI and any of BRSKI so ACP could be implemented with or without BRSKI and any
manual/proprietary or future standardized BRSKI alternatives (for manual/proprietary or future standardized BRSKI alternatives (for
example via NetConf) would understand the requirements for ACP example via NETCONF) would understand the requirements for ACP
registrars and its certificate handling. registrars and its certificate handling.
This lead to additional text about ACP registrars in the ACP This lead to additional text about ACP registrars in the ACP
document: document:
1. Defined relationship ACP / ANI (ANI = ACP + BRSKI). 1. Defined relationship ACP / ANI (ANI = ACP + BRSKI).
6.1.4 (new) Overview of TA required for ACP. 6.1.4 (new) Overview of TA required for ACP.
6.1.5.5 Added explanations/requirements for Re-enrollment. 6.1.5.5 Added explanations/requirements for Re-enrollment.
skipping to change at page 134, line 21 skipping to change at page 134, line 21
A. (new) Moved all explanations and discussions about futures from A. (new) Moved all explanations and discussions about futures from
section 10 into this new appendix. This text should not be removed section 10 into this new appendix. This text should not be removed
because it captures a lot of repeated asked questions in WG and because it captures a lot of repeated asked questions in WG and
during reviews and from users, and also captures ideas for some during reviews and from users, and also captures ideas for some
likely important followup work. But none of this is relevant to likely important followup work. But none of this is relevant to
implementing (section 6) and operating (section 10) the ACP. implementing (section 6) and operating (section 10) the ACP.
15.2. draft-ietf-anima-autonomic-control-plane-29 15.2. draft-ietf-anima-autonomic-control-plane-29
Comments from Robert Wilton:
Improved several textual nits.
Discuss/Comments from Erik Kline: Discuss/Comments from Erik Kline:
Editorial suggestions and nits. Thanks!. Editorial suggestions and nits. Thanks!.
6.1.3 Added text about how/why rsub is irrelevant for domain 6.1.3 Added text about how/why rsub is irrelevant for domain
membership check. membership check.
6.3 Added extension points to AN_ACP DULL GRASP objective because for 6.3 Added extension points to AN_ACP DULL GRASP objective because for
example ACP domain certificate could be a nice optional additional example ACP domain certificate could be a nice optional additional
parameter and prior syntax would have forced us to encode into parameter and prior syntax would have forced us to encode into
skipping to change at page 159, line 44 skipping to change at page 160, line 18
expired domain certificate before falling back to attempting to use expired domain certificate before falling back to attempting to use
its IDevID certificate for BRSKI. This mechanism could also render its IDevID certificate for BRSKI. This mechanism could also render
CRLs unnecessary because the BRSKI registrar in conjunction with the CRLs unnecessary because the BRSKI registrar in conjunction with the
CA would not renew revoked certificates - only a "Do-not-renew" list CA would not renew revoked certificates - only a "Do-not-renew" list
would be necessary on BRSKI registrars/CA. would be necessary on BRSKI registrars/CA.
In the absence of BRSKI or less secure variants thereof, provisioning In the absence of BRSKI or less secure variants thereof, provisioning
of certificates may involve one or more touches or non-standardized of certificates may involve one or more touches or non-standardized
automation. Node vendors usually support provisioning of automation. Node vendors usually support provisioning of
certificates into nodes via PKCS#7 (see [RFC2315]) and may support certificates into nodes via PKCS#7 (see [RFC2315]) and may support
this provisioning through vendor specific models via Netconf this provisioning through vendor specific models via NETCONF
([RFC6241]). If such nodes also support Netconf Zero-Touch ([RFC6241]). If such nodes also support NETCONF Zero-Touch
([RFC8572]) then this can be combined to zero-touch provisioning of ([RFC8572]) then this can be combined to zero-touch provisioning of
domain certificates into nodes. Unless there are equivalent domain certificates into nodes. Unless there are equivalent
integration of Netconf connections across the ACP as there is in integration of NETCONF connections across the ACP as there is in
BRSKI, this combination would not support zero-touch bootstrap across BRSKI, this combination would not support zero-touch bootstrap across
a not configured network though. a not configured network though.
A.3. ACP Neighbor discovery protocol selection A.3. ACP Neighbor discovery protocol selection
This section discusses why GRASP DULL was chosen as the discovery This section discusses why GRASP DULL was chosen as the discovery
protocol for L2 adjacent candidate ACP neighbors. The contenders protocol for L2 adjacent candidate ACP neighbors. The contenders
considered where GRASP, mDNS or LLDP. considered where GRASP, mDNS or LLDP.
A.3.1. LLDP A.3.1. LLDP
skipping to change at page 173, line 23 skipping to change at page 173, line 39
that introduce malicious software should be a lot harder. that introduce malicious software should be a lot harder.
The most important aspect of security design against these type of The most important aspect of security design against these type of
attacks is to eliminate password based configuration access methods attacks is to eliminate password based configuration access methods
and instead rely on certificate based credentials handed out only to and instead rely on certificate based credentials handed out only to
nodes where it is clear that the private keys can not leak. This nodes where it is clear that the private keys can not leak. This
limits unexpected propagation of credentials. limits unexpected propagation of credentials.
If password based credentials to configure devices still need to be If password based credentials to configure devices still need to be
supported, they must not be locally configurable, but only be supported, they must not be locally configurable, but only be
remotely provisioned or verified (through protocols like Radius or remotely provisioned or verified (through protocols like RADIUS or
Diameter), and there must be no local configuration permitting to Diameter), and there must be no local configuration permitting to
change these authentication mechanisms, but ideally they should be change these authentication mechanisms, but ideally they should be
autoconfiguring across the ACP. See autoconfiguring across the ACP. See
[I-D.eckert-anima-noc-autoconfig]. [I-D.eckert-anima-noc-autoconfig].
Without physical access to the compromised device, attackers with Without physical access to the compromised device, attackers with
access to configuration should not be able to break the ACP access to configuration should not be able to break the ACP
connectivity, even when they can break or otherwise manipulate connectivity, even when they can break or otherwise manipulate
(spoof) the Data-Plane connectivity through configuration. To (spoof) the Data-Plane connectivity through configuration. To
achieve this, it is necessary to avoid providing configuration achieve this, it is necessary to avoid providing configuration
 End of changes. 27 change blocks. 
44 lines changed or deleted 52 lines changed or added

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