draft-ietf-anima-autonomic-control-plane-20.txt   draft-ietf-anima-autonomic-control-plane-21.txt 
ANIMA WG T. Eckert, Ed. ANIMA WG T. Eckert, Ed.
Internet-Draft Futurewei USA Internet-Draft Futurewei USA
Intended status: Standards Track M. Behringer, Ed. Intended status: Standards Track M. Behringer, Ed.
Expires: January 23, 2020 Expires: May 5, 2020
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
July 22, 2019 November 2, 2019
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-20 draft-ietf-anima-autonomic-control-plane-21
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 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 23, 2020. This Internet-Draft will expire on May 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
2. Acronyms and Terminology (Informative) . . . . . . . . . . . 10 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 10
3. Use Cases for an Autonomic Control Plane (Informative) . . . 16 3. Use Cases for an Autonomic Control Plane (Informative) . . . 16
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 16 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 16
3.2. Secure Bootstrap over a not configured Network . . . . . 16 3.2. Secure Bootstrap over a not configured Network . . . . . 16
3.3. Data-Plane Independent Permanent Reachability . . . . . . 16 3.3. Data-Plane Independent Permanent Reachability . . . . . . 16
4. Requirements (Informative) . . . . . . . . . . . . . . . . . 18 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 18
5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 19 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 19
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 20 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 20
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20
6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 21 6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 21
6.1.2. ACP Certificate ACP Domain Information Field . . . . 22 6.1.2. ACP Certificate ACP Domain Information Field . . . . 23
6.1.3. ACP domain membership check . . . . . . . . . . . . . 26 6.1.3. ACP domain membership check . . . . . . . . . . . . . 26
6.1.4. Trust Points and Trust Anchors . . . . . . . . . . . 28 6.1.4. Trust Points and Trust Anchors . . . . . . . . . . . 28
6.1.5. Certificate and Trust Point Maintenance . . . . . . . 29 6.1.5. Certificate and Trust Point Maintenance . . . . . . . 29
6.1.5.1. GRASP objective for EST server . . . . . . . . . 30 6.1.5.1. GRASP objective for EST server . . . . . . . . . 30
6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 31 6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 31
6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 31 6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 32
6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 32 6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 32
6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 32 6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 33
6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 34 6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 34
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 34 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 35
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 35 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 35
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 38 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 39
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 39 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 39
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 42 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 42
6.7. Security Association protocols . . . . . . . . . . . . . 42 6.7. Security Association (Secure Channel) protocols . . . . . 42
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 43 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 43
6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 43 6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 43
6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 44 6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 44
6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 45 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 45
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 45 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 45
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 46 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 46
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 46 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 46
6.8.2. ACP as the Security and Transport substrate for GRASP 46 6.8.2. ACP as the Security and Transport substrate for GRASP 46
6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 49 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 49
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 50 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 50
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 51 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 51
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 51 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 51
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 52 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 53
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 54 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 54
6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 55 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 56
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 56 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 57
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 58 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 58
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 59 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 59
6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 59 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 59
6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 60 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 60
6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 60 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 60
6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 61 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 61
6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 62 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 62
6.10.7.5. Further Details . . . . . . . . . . . . . . . . 62 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 62
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 62 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 62
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 63 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 63
skipping to change at page 5, line 20 skipping to change at page 5, line 20
14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 120 14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 120
14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 122 14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 122
14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 124 14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 124
14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 128 14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 128
14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 128 14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 128
14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 129 14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 129
14.24. draft-ietf-anima-autonomic-control-plane-18 . . . . . . 131 14.24. draft-ietf-anima-autonomic-control-plane-18 . . . . . . 131
14.25. draft-ietf-anima-autonomic-control-plane-19 . . . . . . 131 14.25. draft-ietf-anima-autonomic-control-plane-19 . . . . . . 131
14.26. Open Issues in -19 . . . . . . . . . . . . . . . . . . . 133 14.26. Open Issues in -19 . . . . . . . . . . . . . . . . . . . 133
14.27. draft-ietf-anima-autonomic-control-plane-20 . . . . . . 133 14.27. draft-ietf-anima-autonomic-control-plane-20 . . . . . . 133
14.28. draft-ietf-anima-autonomic-control-plane-21 . . . . . . 137
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 137 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 137
15.1. Normative References . . . . . . . . . . . . . . . . . . 137 15.1. Normative References . . . . . . . . . . . . . . . . . . 137
15.2. Informative References . . . . . . . . . . . . . . . . . 140 15.2. Informative References . . . . . . . . . . . . . . . . . 140
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 147 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Appendix A. Background and Futures (Informative) . . . . . . . . 147 Appendix A. Background and Futures (Informative) . . . . . . . . 147
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 147 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 147
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 148 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 148
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 149 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 149
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 149 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 149
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 149 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 150
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 150 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 150
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 150 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 150
A.5. ACP Information Distribution and multicast . . . . . . . 151 A.5. ACP Information Distribution and multicast . . . . . . . 152
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 153 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 153
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 154 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 155
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 156 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 156
A.9. Adopting ACP concepts for other environments . . . . . . 157 A.9. Adopting ACP concepts for other environments . . . . . . 157
A.10. Further (future) options . . . . . . . . . . . . . . . . 158 A.10. Further (future) options . . . . . . . . . . . . . . . . 159
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 158 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 159
A.10.2. More options for avoiding IPv6 Data-Plane dependency 159 A.10.2. More options for avoiding IPv6 Data-Plane dependency 159
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 159 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 160
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 160 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 160
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 160 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 161
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 161 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 161
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 161 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 161
A.10.8. Avoiding and dealing with compromised ACP nodes . . 162 A.10.8. Avoiding and dealing with compromised ACP nodes . . 162
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163
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
skipping to change at page 21, line 10 skipping to change at page 21, line 10
members. The LDevID is used to cryptographically authenticate the members. The LDevID is used to cryptographically authenticate the
membership of its owner node in the ACP domain to other ACP domain membership of its owner node in the ACP domain to other ACP domain
members. The TA is used to authenticate the ACP domain membership of members. The TA is used to authenticate the ACP domain membership of
other nodes (see Section 6.1.3). other nodes (see Section 6.1.3).
The LDevID is called the ACP domain certificate, the TA is the The LDevID is called the ACP domain certificate, the TA is the
Certificate Authority (CA) of the ACP domain. Certificate Authority (CA) of the ACP domain.
The ACP does not mandate specific mechanisms by which this keying The ACP does not mandate specific mechanisms by which this keying
material is provisioned into the ACP node. It only requires the material is provisioned into the ACP node. It only requires the
Domain information field as specified in Section 6.1.2 in its domain certificate to comply with Section 6.1.1, specifically the Domain
information field as specified in Section 6.1.2 in its domain
certificate as well as those of candidate ACP peers. See certificate as well as those of candidate ACP peers. See
Appendix A.2 for more information about enrollment or provisioning Appendix A.2 for more information about enrollment or provisioning
options. options.
This document uses the term ACP in many places where the Autonomic This document uses the term ACP in many places where the Autonomic
Networking reference documents [RFC7575] and Networking reference documents [RFC7575] and
[I-D.ietf-anima-reference-model] use the word autonomic. This is [I-D.ietf-anima-reference-model] use the word autonomic. This is
done because those reference documents consider (only) fully done because those reference documents consider (only) fully
autonomic networks and nodes, but support of ACP does not require autonomic networks and nodes, but support of ACP does not require
support for other components of autonomic networks except for relying support for other components of autonomic networks except for relying
skipping to change at page 21, line 38 skipping to change at page 21, line 39
[I-D.ietf-anima-reference-model] defines the term "Domain [I-D.ietf-anima-reference-model] defines the term "Domain
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.
6.1.1. ACP Certificates 6.1.1. ACP Certificates
ACP domain certificates are [RFC5280] compliant X.509 certificates. ACP domain certificates MUST be [RFC5280] compliant X.509
certificates.
An ACP domain certificate MUST have an Elliptic Curve Diffie-Hellman ACP nodes MUST support RSA and Elliptic Curve Diffie-Hellman (ECDH)
(ECDH) public key. It SHOULD be signed with an ECDH public key. public keys in ACP certificates. ACP nodes MUST support RSA and
Otherwise it MUST be signed with an RSA key. Any secure channel Elliptic Curve Diffie-Hellman (ECDH) signatures for ACP certificates.
protocols used for the ACP as specified in this document or The ACP certificate SHOULD use an RSA key and an RSA signature when
extensions MUST therefore support authentication (e.g.:signing) the ACP certificate is intended to be used not only for ACP
starting with these type of certificates. See [RFC4492] for more authentication but also for other purposes. The ACP certificate MAY
information. use an ECDH key and an ECDH signature if the ACP certificate is only
used for ACP and ANI authentication and authorization. ACP nodes
MUST support 2048-bit RSA using SHA-256, SHA-384 or SHA-512 or
Elliptic Curve using NIST P-256, P-384, or P-521 as key lengths in
ACP certificates/signatures.
Any secure channel protocols used for the ACP as specified in this
document or extensions of this document MUST therefore support
authentication (e.g.:signing) starting with these type of
certificates. See [RFC4492] for more information.
The reason for these choices are as follows: As of 2019, RSA is more
widely used than ECDH, therefore the MUST for RSA. ECDH offers
equivalent security at shorter key lengths (see [RFC4492]). This can
be beneficial especially in the presence of constrained bandwidth or
constrained nodes in an ACP/ANI network. Some ACP functions such as
GRASP peer-2-peer across the ACP require end-to-end/any-to-any
authenticatio/authorization, therefore ECDH can only reliably be used
in the ACP when it MUST be supported on all ACP nodes.
For further certificate details, ACP certificates may follow the
recommendations from [CABFORUM].
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 authorization condition is ACP domain membership, where the required authorization condition is ACP domain membership,
such as ACP node to NOC/OAM end-to-end security and ASA to ASA end- such as ACP node to NOC/OAM end-to-end security and ASA to ASA end-
to-end security. Section 6.1.3 defines this "ACP domain membership to-end security. Section 6.1.3 defines this "ACP domain membership
check". The uses of this check that are standardized in this check". The uses of this check that are standardized in this
document are for the establishment of hop-by-hop ACP secure channels document are for the establishment of hop-by-hop ACP secure channels
(Section 6.6) and for ACP GRASP (Section 6.8.2) end-to-end via TLS (Section 6.6) and for ACP GRASP (Section 6.8.2) end-to-end via TLS
([RFC5246]). ([RFC5246]).
skipping to change at page 42, line 22 skipping to change at page 42, line 22
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.3. If it fails, domain membership check as defined in Section 6.1.3. 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
base 2 backoff with a minimum delay of 10 seconds and a maximum delay base 2 backoff with a minimum delay of 10 seconds and a maximum delay
of 640 seconds. of 640 seconds.
6.7. Security Association protocols 6.7. Security Association (Secure Channel) protocols
Due to Channel Selection (Section 6.5), ACP can support an evolving Due to Channel Selection (Section 6.5), ACP can support an evolving
set of security association protocols. These protocols only need to set of security association protocols. These protocols only need to
be used to establish secure channels with L2 adjacent ACP neighbors be used to establish secure channels with L2 adjacent ACP neighbors
and only optionally (where needed) across non-ACP capable L3 network and only optionally (where needed) across non-ACP capable L3 network
(see Section 8.2). Therefore, there is architecturally no need for (see Section 8.2). Therefore, there is architecturally no need for
any network wide mandatory to implement (MTI) security association any network wide mandatory to implement (MTI) security association
protocols. Instead, ACP nodes only need to implement those protocols protocols. Instead, ACP nodes only need to implement those protocols
required to be supported by their neighbors. See Section 6.7.3 for required to be supported by their neighbors. See Section 6.7.3 for
an example of this. an example of this.
skipping to change at page 42, line 44 skipping to change at page 42, line 44
The authentication of peers in any security association protocol MUST The authentication of peers in any security association protocol MUST
use the ACP domain certificate according to Section 6.1.3. Because use the ACP domain certificate according to Section 6.1.3. Because
auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3) auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3)
as specified in this document does not communicate the neighbors ACP as specified in this document does not communicate the neighbors ACP
domain certificate, and ACP nodes may not (yet) have any other domain certificate, and ACP nodes may not (yet) have any other
network connectivity to retrieve certificates, any security network connectivity to retrieve certificates, any security
association protocol MUST use a mechanism to communicate the association protocol MUST use a mechanism to communicate the
certificate directly instead of relying on a referential mechanism certificate directly instead of relying on a referential mechanism
such as communicating only a hash and/or URL for the certificate. such as communicating only a hash and/or URL for the certificate.
Any security association protocol MUST use PFS (such as profiles
providing PFS).
The degree of security required on every hop of an ACP network needs The degree of security required on every hop of an ACP network needs
to be consistent across the network so that there is no designated to be consistent across the network so that there is no designated
"weakest link" because it is that "weakest link" that would otherwise "weakest link" because it is that "weakest link" that would otherwise
become the designated point of attack. When the secure channel become the designated point of attack. When the secure channel
protection on one link is compromised, it can be used to send/receive protection on one link is compromised, it can be used to send/receive
packets across the whole ACP network. This principle does not imply packets across the whole ACP network. This principle does not imply
that the requirements against ACP security association protocols have that the requirements against ACP security association protocols have
to be the same across all subnets in an ACP network: to be the same across all subnets in an ACP network:
o Underlying L2 mechanisms such as strong encrypted radio o Underlying L2 mechanisms such as strong encrypted radio
technologies or [MACSEC] may offer equivalent encryption and the technologies or [MACSEC] may offer equivalent encryption and the
ACP security association protocol may only be required to ACP security association protocol may only be required to
authenticate ACP domain membership of a peer. Mechanisms to auto- authenticate ACP domain membership of a peer and/or derive a key
discover and associate ACP peers leveraging such underlying L2 for the L2 mechanism. Mechanisms to auto-discover and associate
security are possible and desirable to avoid duplication of ACP peers leveraging such underlying L2 security are possible and
encryption, but none are specified in this document. desirable to avoid duplication of encryption, but none are
specified in this document.
o Strong physical security of a link may stand in where o Strong physical security of a link may stand in where
cryptographic security is infeasible. As there is no secure cryptographic security is infeasible. As there is no secure
mechanism to automatically discover strong physical security mechanism to automatically discover strong physical security
solely between two peers, it can only be used with explicit solely between two peers, it can only be used with explicit
configuration and that configuration too could become an attack configuration and that configuration too could become an attack
vector. This document therefore only specifies with ACP connect vector. This document therefore only specifies with ACP connect
(Figure 15) one explicitly configured mechanism without any secure (Figure 15) one explicitly configured mechanism without any secure
channel association protocol - for the case where both the link channel association protocol - for the case where both the link
and the nodes attached to it have strong physical security. and the nodes attached to it have strong physical security.
skipping to change at page 44, line 7 skipping to change at page 44, line 11
this text). If certificate chains are used, all intermediate this text). If certificate chains are used, all intermediate
certificates up to, but not including the locally provisioned trust certificates up to, but not including the locally provisioned trust
anchor certificate must be signaled. anchor certificate must be signaled.
IPsec tunnel mode is required because the ACP will route/forward IPsec tunnel mode is required because the ACP will route/forward
packets received from any other ACP node across the ACP secure packets received from any other ACP node across the ACP secure
channels, and not only its own generated ACP packets. With IPsec channels, and not only its own generated ACP packets. With IPsec
transport mode, it would only be possible to send packets originated transport mode, it would only be possible to send packets originated
by the ACP node itself. by the ACP node itself.
IPsec MUST use ESP with ENCR_AES_GCM_16 ([RFC4106]) due to its higher IPsec MUST support ESP with ENCR_AES_GCM_16 ([RFC4106]) due to its
performance over ENCR_AES_CBC. ACP MUST NOT use any NULL encryption higher performance over ENCR_AES_CBC. ACP MUST NOT use any NULL
option due to the confidentiality of ACP payload that may not be encryption option due to the confidentiality of ACP payload that may
encrypted by itself (when carrying legacy management protocol not be encrypted by itself (when carrying legacy management protocol
traffics as well as hop-by-hop GRASP). traffics as well as hop-by-hop GRASP).
These IPsec requirements are based on [RFC8221] but limited to the These IPsec requirements are based on [RFC8221] but limited to the
minimum necessary options because ACP is not a general purpose use minimum necessary options because ACP is not a general purpose use
case today with a wide range of interoperability requirements against case today with a wide range of interoperability requirements against
legacy devices originally developed against older profile legacy devices originally developed against older profile
recommendations. Once there are updates to [RFC8221], these should recommendations. Once there are updates to [RFC8221], these should
accordingly be reflected in updates to these ACP requirements (for accordingly be reflected in updates to these ACP requirements (for
example if ENCR_AES_GCM_16 was to be superceeded in the future). example if ENCR_AES_GCM_16 was to be superceeded in the future).
skipping to change at page 49, line 22 skipping to change at page 49, line 22
(Section 6.1.3). (Section 6.1.3).
GRASP link-local multicast messages are targeted for a specific ACP GRASP link-local multicast messages are targeted for a specific ACP
virtual interface (as defined Section 6.12.5) but are sent by the ACP virtual interface (as defined Section 6.12.5) but are sent by the ACP
into an ACP GRASP virtual interface that is constructed from the TCP into an ACP GRASP virtual interface that is constructed from the TCP
connection(s) to the IPv6 link-local neighbor address(es) on the connection(s) to the IPv6 link-local neighbor address(es) on the
underlying ACP virtual interface. If the ACP GRASP virtual interface underlying ACP virtual interface. If the ACP GRASP virtual interface
has two or more neighbors, the GRASP link-local multicast messages has two or more neighbors, the GRASP link-local multicast messages
are replicated to all neighbor TCP connections. are replicated to all neighbor TCP connections.
TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options
with less than 256bit AES or less than SHA384. TLS for GRASP MUST
also include the "Supported Elliptic Curves" extension, it MUST
support support the NIST P-256 (secp256r1) and P-384 (secp384r1(24))
curves [RFC4492]. In addition, GRASP TLS clients SHOULD send an
ec_point_formats extension with a single element, "uncompressed".
For further interoperability recommendations, GRASP TLS
implementations SHOULD follow [RFC7525].
TCP and TLS connections for GRASP in the ACP use the IANA assigned TCP and TLS connections for GRASP in the ACP use the IANA assigned
TCP port for GRASP (7107). Effectively the transport stack is TCP port for GRASP (7107). Effectively the transport stack is
expected to be TLS for connections from/to the ACP address (e.g., expected to be TLS for connections from/to the ACP address (e.g.,
global scope address(es)) and TCP for connections from/to link-local global scope address(es)) and TCP for connections from/to link-local
addresses on the ACP virtual interfaces. The latter ones are only addresses on the ACP virtual interfaces. The latter ones are only
used for flooding of GRASP messages. used for flooding of GRASP messages.
6.8.2.1. Discussion 6.8.2.1. Discussion
TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local
skipping to change at page 137, line 26 skipping to change at page 137, line 26
introducing F-bit to distinguish 23/15 Vlong address prefixes. introducing F-bit to distinguish 23/15 Vlong address prefixes.
Adjusted explanatory text accordingly. Adjusted explanatory text accordingly.
6.1.5.1 - Changed TCP port for SRV.est from 80 to 443 (EST is using 6.1.5.1 - Changed TCP port for SRV.est from 80 to 443 (EST is using
TLS). TLS).
Other: Other:
Change author association: Toerless Eckert, Huawei -> Futurewei USA. Change author association: Toerless Eckert, Huawei -> Futurewei USA.
14.28. draft-ietf-anima-autonomic-control-plane-21
In reply to review of -19 by Ben Kaduk (also for Eric Rescorla) that
where not fixed in -20:
6.1.1 Added missing detail about ACP domain certificate requirements
and explanations.
Also added pointer to CABFORUM cert recommendations as suggested by
MichaelR (changing pointer, external non-IETF document, so can not be
a real MUST/SHOULD).
6.7 Added requirement for PFS in secure channel protocols.
6.8.2 Added TLS security profile based on 'intersection' of Bens
recommended profiles and RFC7525.
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 140, line 34 skipping to change at page 141, line 5
RFC 8247, DOI 10.17487/RFC8247, September 2017, RFC 8247, DOI 10.17487/RFC8247, September 2017,
<https://www.rfc-editor.org/info/rfc8247>. <https://www.rfc-editor.org/info/rfc8247>.
15.2. Informative References 15.2. Informative References
[AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[CABFORUM]
CA/Browser Forum, "Certificate Contents for Baseline SSL",
Nov 2019, <https://cabforum.org/baseline-requirements-
certificate-contents/>.
[I-D.eckert-anima-noc-autoconfig] [I-D.eckert-anima-noc-autoconfig]
Eckert, T., "Autoconfiguration of NOC services in ACP Eckert, T., "Autoconfiguration of NOC services in ACP
networks via GRASP", draft-eckert-anima-noc-autoconfig-00 networks via GRASP", draft-eckert-anima-noc-autoconfig-00
(work in progress), July 2018. (work in progress), July 2018.
[I-D.ietf-acme-star] [I-D.ietf-acme-star]
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Support for Short-Term, Automatically-Renewed Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management (STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-06 (work in Environment (ACME)", draft-ietf-acme-star-11 (work in
progress), July 2019. progress), October 2019.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., and K. Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
Watsen, "Bootstrapping Remote Secure Key Infrastructures and K. Watsen, "Bootstrapping Remote Secure Key
(BRSKI)", draft-ietf-anima-bootstrapping-keyinfra-24 (work Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
in progress), July 2019. keyinfra-29 (work in progress), October 2019.
[I-D.ietf-anima-prefix-management] [I-D.ietf-anima-prefix-management]
Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic
IPv6 Edge Prefix Management in Large-scale Networks", IPv6 Edge Prefix Management in Large-scale Networks",
draft-ietf-anima-prefix-management-07 (work in progress), draft-ietf-anima-prefix-management-07 (work in progress),
December 2017. December 2017.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
skipping to change at page 141, line 31 skipping to change at page 142, line 9
[I-D.ietf-roll-applicability-template] [I-D.ietf-roll-applicability-template]
Richardson, M., "ROLL Applicability Statement Template", Richardson, M., "ROLL Applicability Statement Template",
draft-ietf-roll-applicability-template-09 (work in draft-ietf-roll-applicability-template-09 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPL Robles, I., Richardson, M., and P. Thubert, "Using RPL
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", draft-ietf- IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-31 (work in progress), July 2019. roll-useofrplinfo-31 (work in progress), August 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-32 (work in progress), July 1.3", draft-ietf-tls-dtls13-33 (work in progress), October
2019. 2019.
[IEEE-1588-2008] [IEEE-1588-2008]
IEEE, "IEEE Standard for a Precision Clock Synchronization IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
December 2008, <http://standards.ieee.org/findstds/ December 2008, <http://standards.ieee.org/findstds/
standard/1588-2008.html>. standard/1588-2008.html>.
[IEEE-802.1X] [IEEE-802.1X]
Group, W. -. H. L. L. P. W., "IEEE Standard for Local and Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
Metropolitan Area Networks: Port-Based Network Access Metropolitan Area Networks: Port-Based Network Access
Control", February 2010, Control", February 2010,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/standard/802.1X-
standard/802.1X-2010.html>. 2010.html>.
[LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
Metropolitan Area Networks: Station and Media Access Metropolitan Area Networks: Station and Media Access
Control Connectivity Discovery", June 2016, Control Connectivity Discovery", June 2016,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/standard/802.1AB-
standard/802.1AB-2016.html>. 2016.html>.
[MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
Metropolitan Area Networks: Media Access Control (MAC) Metropolitan Area Networks: Media Access Control (MAC)
Security", June 2006, Security", June 2006,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/standard/802.1AE-
standard/802.1AE-2006.html>. 2006.html>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989, RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>. <https://www.rfc-editor.org/info/rfc1112>.
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993,
<https://www.rfc-editor.org/info/rfc1492>. <https://www.rfc-editor.org/info/rfc1492>.
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP
 End of changes. 36 change blocks. 
52 lines changed or deleted 112 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/