draft-ietf-anima-autonomic-control-plane-14.txt   draft-ietf-anima-autonomic-control-plane-15.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: December 8, 2018 Expires: December 8, 2018
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
June 6, 2018 June 6, 2018
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-14 draft-ietf-anima-autonomic-control-plane-15
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 2, line 14 skipping to change at page 2, line 14
(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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 7 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 7
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 8 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 9
3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 13 3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 14
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 13 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 14
3.2. Secure Bootstrap over a not configured Network . . . . . 13 3.2. Secure Bootstrap over a not configured Network . . . . . 14
3.3. Data-Plane Independent Permanent Reachability . . . . . . 14 3.3. Data-Plane Independent Permanent Reachability . . . . . . 15
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 17 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 18
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 17 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 18
6.1.1. Certificate Domain Information Field . . . . . . . . 19 6.1.1. Certificate Domain Information Field . . . . . . . . 19
6.1.2. ACP domain membership check . . . . . . . . . . . . . 21 6.1.2. ACP domain membership check . . . . . . . . . . . . . 22
6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 22 6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 23
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 27 6.1.3.1. GRASP objective for EST server . . . . . . . . . 23
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 27 6.1.3.2. Renewal . . . . . . . . . . . . . . . . . . . . . 24
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 30 6.1.3.3. Certificate Revocation Lists (CRLs) . . . . . . . 25
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 31 6.1.3.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 25
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 33 6.1.3.5. Re-enrollment . . . . . . . . . . . . . . . . . . 26
6.7. Security Association protocols . . . . . . . . . . . . . 33 6.1.3.6. Failing Certificates . . . . . . . . . . . . . . 27
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 33 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 28
6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 34 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 28
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 35 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 31
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 35 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 32
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 35 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 34
6.8.2. ACP as the Security and Transport substrate for GRASP 36 6.7. Security Association protocols . . . . . . . . . . . . . 34
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 39 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 34
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 39 6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 34
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 40 6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 35
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 41 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 35
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 42 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 36
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 44 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 36
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 46 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 36
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 47 6.8.2. ACP as the Security and Transport substrate for GRASP 37
6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 47 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 39
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 50 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 40
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 51 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 40
6.12. General ACP Considerations . . . . . . . . . . . . . . . 54 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 41
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 55 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 42
6.12.2. Addressing of Secure Channels in the Data-Plane . . 55 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 43
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 55 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 44
6.12.4. Multiple links between nodes . . . . . . . . . . . . 56 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 45
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 56 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 47
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 59 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 48
7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 48
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 60 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 48
8. Support for Non-ACP Components (Normative) . . . . . . . . . 62 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 49
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 62 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 50
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 62 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 51
8.1.2. Software Components . . . . . . . . . . . . . . . . . 64 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 51
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 65 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 51
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 66 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 52
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 67 6.11.1.1. Summary . . . . . . . . . . . . . . . . . . . . 52
8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 68 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 53
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 68 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 53
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 70 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 53
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 70 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 54
9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 70 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 54
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 70 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 54
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 72 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 54
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 72 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 54
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 73 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 54
9.3. The Administrator View . . . . . . . . . . . . . . . . . 73 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 54
10. Further Considerations (Informative) . . . . . . . . . . . . 74 6.11.1.12. Administrative parameters . . . . . . . . . . . 55
10.1. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . 74 6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 55
10.2. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 75 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 55
10.3. ACP Registrar Considerations . . . . . . . . . . . . . . 80 6.12. General ACP Considerations . . . . . . . . . . . . . . . 55
10.3.1. Registrar interactions . . . . . . . . . . . . . . . 80 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 56
10.3.2. Registrar Parameter . . . . . . . . . . . . . . . . 81 6.12.2. Addressing of Secure Channels in the Data-Plane . . 56
10.3.3. Certificate renewal and limitations . . . . . . . . 82 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 56
10.3.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83 6.12.4. Multiple links between nodes . . . . . . . . . . . . 57
10.3.5. Centralized Policy Control . . . . . . . . . . . . . 83 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 57
10.4. Address Space Considerations . . . . . . . . . . . . . . 84 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 60
10.5. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 85 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
10.5.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 61
10.5.2. Admin Down State . . . . . . . . . . . . . . . . . . 86 8. Support for Non-ACP Components (Normative) . . . . . . . . . 63
10.5.3. Interface level ACP/ANI enable . . . . . . . . . . . 88 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 63
10.5.4. Which interfaces to auto-enable? . . . . . . . . . . 89 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 63
10.5.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90 8.1.2. Software Components . . . . . . . . . . . . . . . . . 65
10.5.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 92 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 66
10.5.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 67
10.6. ACP Neighbor discovery protocol selection . . . . . . . 92 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 68
10.6.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 93 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 69
10.6.2. mDNS and L2 support . . . . . . . . . . . . . . . . 93 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 69
10.6.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 93 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 71
10.7. Choice of routing protocol (RPL) . . . . . . . . . . . . 94 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 71
10.8. ACP Information Distribution and multicast . . . . . . . 95
10.9. Extending ACP channel negotiation (via GRASP) . . . . . 96 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 71
10.10. CAs, domains and routing subdomains . . . . . . . . . . 98 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 71
10.11. Adopting ACP concepts for other environments . . . . . . 99 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 73
11. Security Considerations . . . . . . . . . . . . . . . . . . . 101 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 73
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 74
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103 9.3. The Administrator View . . . . . . . . . . . . . . . . . 74
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 104 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 75
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 104 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 75
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 104 10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 80
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 104 10.2.1. Registrar interactions . . . . . . . . . . . . . . . 80
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 104 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 104 10.2.3. Certificate renewal and limitations . . . . . . . . 82
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 105 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 105 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 106 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 84
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 106 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85
14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 106 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85
14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 107 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86
14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 107 10.3.2.2. Fast state propagation and Diagnostics . . . . . 86
14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 108 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87
14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 109 10.3.2.4. Power Consumption . . . . . . . . . . . . . . . 88
14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 111 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88
14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 113 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88
14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 115 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90
14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 115 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90
14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 116 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91
14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 118 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91
14.21. wish-list . . . . . . . . . . . . . . . . . . . . . . . 122 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 122 11. Background and Futures (Informative) . . . . . . . . . . . . 92
15.1. Normative References . . . . . . . . . . . . . . . . . . 122 11.1. ACP Address Space Schemes . . . . . . . . . . . . . . . 92
15.2. Informative References . . . . . . . . . . . . . . . . . 125 11.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 129 11.3. ACP Neighbor discovery protocol selection . . . . . . . 94
11.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 94
11.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . 95
11.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 95
11.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 95
11.5. ACP Information Distribution and multicast . . . . . . . 97
11.6. Extending ACP channel negotiation (via GRASP) . . . . . 98
11.7. CAs, domains and routing subdomains . . . . . . . . . . 100
11.8. Adopting ACP concepts for other environments . . . . . . 101
12. Security Considerations . . . . . . . . . . . . . . . . . . . 103
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 105
15.1. Initial version . . . . . . . . . . . . . . . . . . . . 105
15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 105
15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 106
15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 106
15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 106
15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 106
15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 107
15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 107
15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 108
15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 108
15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 108
15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 109
15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 109
15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 111
15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 113
15.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 115
15.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 116
15.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 117
15.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 118
15.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 120
15.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 124
15.22. wish-list . . . . . . . . . . . . . . . . . . . . . . . 124
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 125
16.1. Normative References . . . . . . . . . . . . . . . . . . 125
16.2. Informative References . . . . . . . . . . . . . . . . . 127
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131
1. Introduction 1. Introduction
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 6, line 19 skipping to change at page 7, line 9
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, and in Section 6 the process an overview how the ACP is constructed, and in Section 6 the process
is defined in detail. Section 7 defines how to support ACP on L2 is defined in detail. Section 7 defines how to support ACP on L2
switches. Section 8 explains how non-ACP nodes and networks can be switches. Section 8 explains how non-ACP nodes and networks can be
integrated. integrated.
The following sections are non-normative: Section 9 reviews benefits The following 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 additional explanations and describes additional details or provides operational recommendations, Section 11 provides additional
future work possibilities that where considered not to be appropriate explanations and describes additional details or future work
for standardization in this document but nevertheless assumed to be possibilities that where considered not to be appropriate for
helpful for candidate adopters of the ACP. standardization in this document but were considered important to
document.
The ACP provides secure IPv6 connectivity, therefore it can not only The ACP provides secure IPv6 connectivity, therefore it can not 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
skipping to change at page 8, line 15 skipping to change at page 9, line 6
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 Section 10.11 for discussions about how variations environments. See Section 11.8 for discussions about how variations
of the ACP could be defined in the future to better meet different of the ACP could be defined in the future to better meet different
expectations from those on which the current design is based. expectations from those on which the current design is based.
2. Acronyms and Terminology 2. Acronyms and Terminology
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.
skipping to change at page 18, line 17 skipping to change at page 19, line 12
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.2). other nodes (see Section 6.1.2).
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.1 in its domain Domain information field as specified in Section 6.1.1 in its domain
certificate as well as those of candidate ACP peers. See certificate as well as those of candidate ACP peers. See
Section 10.1 for more information about enrollment or provisioning Section 11.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. Therefore the support for other components of autonomic networks. Therefore the
word autonomic might be misleading to operators interested in only word autonomic might be misleading to operators interested in only
the ACP: the ACP:
skipping to change at page 20, line 20 skipping to change at page 21, line 14
routing for the ACP. When "rsub" is not used, "routing-subdomain" is routing for the ACP. When "rsub" is not used, "routing-subdomain" is
the same as "domain". "rsub" needs to be in the "local-part"; it the same as "domain". "rsub" needs to be in the "local-part"; it
could not syntactically be separated from "domain-name" if "domain" could not syntactically be separated from "domain-name" if "domain"
is just a domain name. It also makes it easier for domain name to be is just a domain name. It also makes it easier for domain name to be
a valid e-mail target. a valid e-mail target.
The optional "extensions" field is used for future extensions to this The optional "extensions" field is used for future extensions to this
specification. It MUST be ignored if present and not understood. specification. It MUST be ignored if present and not understood.
In this specification, the "acp-address" field is REQUIRED, but In this specification, the "acp-address" field is REQUIRED, but
future variations (see Section 10.11) may use local information to future variations (see Section 11.8) may use local information to
derive the ACP address. In this case, "acp-address" could be empty. derive the ACP address. In this case, "acp-address" could be empty.
Such a variation would be indicated by an appropriate "extension". Such a variation would be indicated by an appropriate "extension".
If "acp-address" is empty, and "rsub" is empty too, the "local-part" If "acp-address" is empty, and "rsub" is empty too, the "local-part"
will have the format "rfcSELF + + extension(s)". The two plus will have the format "rfcSELF + + extension(s)". The two plus
characters are necessary so the node can unambiguously parse that characters are necessary so the node can unambiguously parse that
both "acp-address" and "rsub" are empty. both "acp-address" and "rsub" are empty.
Note that the maximum size of "domain-information" is 254 characters Note that the maximum size of "domain-information" is 254 characters
and the maximum size of node-info is 64 characters according to and the maximum size of node-info is 64 characters according to
[RFC5280] that is referring to [RFC2821] (superseded by [RFC5321]). [RFC5280] that is referring to [RFC2821] (superseded by [RFC5321]).
skipping to change at page 22, line 11 skipping to change at page 23, line 5
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 peers according to those criteria: An OCSP check for the peers
certificate across the ACP must succeed or the peer certificate certificate across the ACP must succeed or the peer certificate
must not be listed in the CRL retrieved from the CDP. must not be listed in the CRL retrieved from the CDP.
o The peers certificate has a syntactically valid domain information o The peers certificate has a syntactically valid domain information
field (subjectAltName / rfc822Name) and the domain name in that field (subjectAltName / rfc822Name) and the domain name in that
peers domain information field is the same as in this ACP node peers domain information field is the same as in this ACP node
certificate. Note that future Intent rules may modify this. See certificate. Note that future Intent rules may modify this. See
Section 10.10. Section 11.7.
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 24, line 47 skipping to change at page 25, line 47
certificate certificate
6.1.3.4. Lifetimes 6.1.3.4. Lifetimes
Certificate lifetime may be set to shorter lifetimes than customary Certificate lifetime may be set to shorter lifetimes than customary
(1 year) because certificate renewal is fully automated via ACP and (1 year) because certificate renewal is fully automated via ACP and
EST. The primary limiting factor for shorter certificate lifetimes EST. The primary limiting factor for shorter certificate lifetimes
is load on the EST server(s) and CA. It is therefore recommended is load on the EST server(s) and CA. It is therefore recommended
that ACP domain certificates are managed via a CA chain where the that ACP domain certificates are managed via a CA chain where the
assigning CA has enough performance to manage short lived assigning CA has enough performance to manage short lived
certificates. See also Section 10.3.4 for discussion about an certificates. See also Section 10.2.4 for discussion about an
example setup achieving this. example setup achieving this.
When certificate lifetimes are sufficiently short, such as few hours, When certificate lifetimes are sufficiently short, such as few hours,
certificate revocation may not be necessary, allowing to simplify the certificate revocation may not be necessary, allowing to simplify the
overall certificate maintenance infrastructure. overall certificate maintenance infrastructure.
See Section 10.1 for further optimizations of certificate maintenance See Section 11.2 for further optimizations of certificate maintenance
when BRSKI can be used ("Bootstrapping Remote Secure Key when BRSKI can be used ("Bootstrapping Remote Secure Key
Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]).
6.1.3.5. Re-enrollment 6.1.3.5. Re-enrollment
An ACP node may determine that its ACP domain certificate has An ACP node may determine that its ACP domain certificate has
expired, for example because the ACP node was powered down or expired, for example because the ACP node was powered down or
disconnected longer than its certificate lifetime. In this case, the disconnected longer than its certificate lifetime. In this case, the
ACP node SHOULD convert to a role of a re-enrolling candidate ACP ACP node SHOULD convert to a role of a re-enrolling candidate ACP
node. node.
skipping to change at page 28, line 23 skipping to change at page 29, line 23
(ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener
Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to
receive packets for that address. Otherwise DULL GRASP could fail to receive packets for that address. Otherwise DULL GRASP could fail to
operate correctly in the presence of MLD snooping, non-ACP enabled L2 operate correctly in the presence of MLD snooping, non-ACP enabled L2
switches - because those would stop forwarding DULL GRASP packets. switches - because those would stop forwarding DULL GRASP packets.
Switches not supporting MLD snooping simply need to operate as pure Switches not supporting MLD snooping simply need to operate as pure
L2 bridges for IPv6 multicast packets for DULL GRASP to work. L2 bridges for IPv6 multicast packets for DULL GRASP to work.
ACP discovery SHOULD NOT be enabled by default on non-native ACP discovery SHOULD NOT be enabled by default on non-native
interfaces. In particular, ACP discovery MUST NOT run inside the ACP interfaces. In particular, ACP discovery MUST NOT run inside the ACP
across ACP virtual interfaces. See Section 10.5 for further, non- across ACP virtual interfaces. See Section 10.3 for further, non-
normative suggestions on how to enable/disable ACP at node and normative suggestions on how to enable/disable ACP at node and
interface level. See Section 8.2.2 for more details about tunnels interface level. See Section 8.2.2 for more details about tunnels
(typical non-native interfaces). See Section 7 for how ACP should be (typical non-native interfaces). See Section 7 for how ACP should be
extended on devices operating (also) as L2 bridges. extended on devices operating (also) as L2 bridges.
Note: If an ACP node also implements BRSKI to enroll its ACP domain Note: If an ACP node also implements BRSKI to enroll its ACP domain
certificate (see Section 10.1 for a summary), then the above certificate (see Section 11.2 for a summary), then the above
considerations also apply to GRASP discovery for BRSKI. Each DULL considerations also apply to GRASP discovery for BRSKI. Each DULL
instance of GRASP set up for ACP is then also used for the discovery instance of GRASP set up for ACP is then also used for the discovery
of a bootstrap proxy via BRSKI when the node does not have a domain of a bootstrap proxy via BRSKI when the node does not have a domain
certificate. Discovery of ACP neighbors happens only when the node certificate. Discovery of ACP neighbors happens only when the node
does have the certificate. The node therefore never needs to does have the certificate. The node therefore never needs to
discover both a bootstrap proxy and ACP neighbor at the same time. discover both a bootstrap proxy and ACP neighbor at the same time.
An ACP node announces itself to potential ACP peers by use of the An ACP node announces itself to potential ACP peers by use of the
"AN_ACP" objective. This is a synchronization objective intended to "AN_ACP" objective. This is a synchronization objective intended to
be flooded on a single link using the GRASP Flood Synchronization be flooded on a single link using the GRASP Flood Synchronization
skipping to change at page 30, line 50 skipping to change at page 31, line 50
Adjacency Table, see Section 6.2 which then drives the further Adjacency Table, see Section 6.2 which then drives the further
building of the ACP to that neighbor. building of the ACP to that neighbor.
6.4. Candidate ACP Neighbor Selection 6.4. Candidate ACP Neighbor Selection
An ACP node must determine to which other ACP nodes in the adjacency An ACP node must determine to which other ACP nodes in the adjacency
table it should build an ACP connection. This is based on the table it should build an ACP connection. This is based on the
information in the ACP Adjacency table. information in the ACP Adjacency table.
The ACP is by default established exclusively between nodes in the The ACP is by default established exclusively between nodes in the
same domain. This includes all routing subdomains. Section 10.10 same domain. This includes all routing subdomains. Section 11.7
explains how ACP connections across multiple routing subdomains are explains how ACP connections across multiple routing subdomains are
special. special.
Future extensions to this document including Intent can change this Future extensions to this document including Intent can change this
default behavior. Examples include: default behavior. Examples include:
o Build the ACP across all domains that have a common parent domain. o Build the ACP across all domains that have a common parent domain.
For example ACP nodes with domain "example.com", nodes of For example ACP nodes with domain "example.com", nodes of
"example.com", "access.example.com", "core.example.com" and "example.com", "access.example.com", "core.example.com" and
"city.core.example.com" could all establish one single ACP. "city.core.example.com" could all establish one single ACP.
o ACP connections across domains with different Certificate o ACP connections across domains with different Certificate
Authorities (CA) could establish a common ACP by installing the Authorities (CA) could establish a common ACP by installing the
alternate domains' CA into the trusted anchor store. This is an alternate domains' CA into the trusted anchor store. This is an
executive management action that could easily be accomplished executive management action that could easily be accomplished
through the control channel created by the ACP. through the control channel created by the ACP.
Since Intent is transported over the ACP, the first ACP connection a Since Intent is transported over the ACP, the first ACP connection a
node establishes is always following the default behavior. See node establishes is always following the default behavior. See
Section 10.10 for more details. Section 11.7 for more details.
The result of the candidate ACP neighbor selection process is a list The result of the candidate ACP neighbor selection process is a list
of adjacent or configured autonomic neighbors to which an ACP channel of adjacent or configured autonomic neighbors to which an ACP channel
should be established. The next step begins that channel should be established. The next step begins that channel
establishment. establishment.
6.5. Channel Selection 6.5. Channel Selection
To avoid attacks, initial discovery of candidate ACP peers cannot To avoid attacks, initial discovery of candidate ACP peers cannot
include any non-protected negotiation. To avoid re-inventing and include any non-protected negotiation. To avoid re-inventing and
skipping to change at page 35, line 45 skipping to change at page 36, line 45
The ACP does not use IP multicast routing nor does it provide generic The ACP does not use IP multicast routing nor does it provide generic
IP multicast services (the handling of GRASP link-local multicast IP multicast services (the handling of GRASP link-local multicast
messages is explained in Section 6.8.2). Instead, the ACP provides messages is explained in Section 6.8.2). Instead, the ACP provides
service discovery via the objective discovery/announcement and service discovery via the objective discovery/announcement and
negotiation mechanisms of the ACP GRASP instance (services are a form negotiation mechanisms of the ACP GRASP instance (services are a form
of objectives). These mechanisms use hop-by-hop reliable flooding of of objectives). These mechanisms use hop-by-hop reliable flooding of
GRASP messages for both service discovery (GRASP M_DISCOVERY GRASP messages for both service discovery (GRASP M_DISCOVERY
messages) and service announcement (GRASP M_FLOOD messages). messages) and service announcement (GRASP M_FLOOD messages).
See Section 10.8 for more discussion about this design choice of the See Section 11.5 for more discussion about this design choice of the
ACP and considerations for possible future variations. ACP and considerations for possible future variations.
6.8.2. ACP as the Security and Transport substrate for GRASP 6.8.2. ACP as the Security and Transport substrate for GRASP
In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the
security and transport substrate for the GRASP instance run inside security and transport substrate for the GRASP instance run inside
the ACP ("ACP GRASP"). the ACP ("ACP GRASP").
This means that the ACP is responsible for ensuring that this This means that the ACP is responsible for ensuring that this
instance of GRASP is only sending messages across the ACP GRASP instance of GRASP is only sending messages across the ACP GRASP
skipping to change at page 42, line 13 skipping to change at page 43, line 13
Request message by the pledge. Request message by the pledge.
o Type: This field allows different address sub-schemes. This o Type: This field allows different address sub-schemes. This
addresses the "upgradability" requirement. Assignment of types addresses the "upgradability" requirement. Assignment of types
for this field will be maintained by IANA. for this field will be maintained by IANA.
The sub-scheme may imply a range or set of addresses assigned to the The sub-scheme may imply a range or set of addresses assigned to the
node, this is called the ACP address range/set and explained in each node, this is called the ACP address range/set and explained in each
sub-scheme. sub-scheme.
Please refer to Section 6.10.7 and Section 10.4 for further Please refer to Section 6.10.7 and Section 11.1 for further
explanations why the following Sub-Addressing schemes are used and explanations why the following Sub-Addressing schemes are used and
why multiple are necessary. why multiple are necessary.
6.10.3. ACP Zone Addressing Sub-Scheme 6.10.3. ACP Zone Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 00b (zero) The sub-scheme defined here is defined by the Type value 00b (zero)
in the base scheme and 0 in the Z bit. in the base scheme and 0 in the Z bit.
64 64 64 64
+-----------------+---+---------++-----------------------------+---+ +-----------------+---+---------++-----------------------------+---+
skipping to change at page 50, line 13 skipping to change at page 51, line 13
address prefixes from no longer used ACP nodes. address prefixes from no longer used ACP nodes.
6.10.7.4. Address/Prefix Persistence 6.10.7.4. Address/Prefix Persistence
When an ACP domain certificate is renewed or rekeyed via EST or other When an ACP domain certificate is renewed or rekeyed via EST or other
mechanisms, the ACP address/prefix in the ACP domain information mechanisms, the ACP address/prefix in the ACP domain information
field MUST be maintained unless security issues or violations of the field MUST be maintained unless security issues or violations of the
unique address assignment requirements exist or are suspected by the unique address assignment requirements exist or are suspected by the
ACP registrar. Even when the renewing/rekeying ACP registrar is not ACP registrar. Even when the renewing/rekeying ACP registrar is not
the same as the one that enrolled the prior ACP certificate. See the same as the one that enrolled the prior ACP certificate. See
Section 10.3.4 for an example. ACP address information SHOULD also Section 10.2.4 for an example. ACP address information SHOULD also
be maintained even after an ACP certificate did expire or failed. be maintained even after an ACP certificate did expire or failed.
See Section 6.1.3.5 and Section 6.1.3.6. See Section 6.1.3.5 and Section 6.1.3.6.
6.10.7.5. Further Details 6.10.7.5. Further Details
Section 10.3 discusses further non-normative details of ACP Section 10.2 discusses further informative details of ACP registrars:
registrars: What interactions registrars need, what parameters they What interactions registrars need, what parameters they require,
require, certificate renewal and limitations, use of sub-CAs on certificate renewal and limitations, use of sub-CAs on registrars and
registrars and centralized policy control. centralized policy control.
6.11. Routing in the ACP 6.11. Routing in the ACP
Once ULA address are set up all autonomic entities should run a Once ULA address are set up all autonomic entities should run a
routing protocol within the autonomic control plane context. This routing protocol within the autonomic control plane context. This
routing protocol distributes the ULA created in the previous section routing protocol distributes the ULA created in the previous section
for reachability. The use of the autonomic control plane specific for reachability. The use of the autonomic control plane specific
context eliminates the probable clash with the global routing table context eliminates the probable clash with the global routing table
and also secures the ACP from interference from the configuration and also secures the ACP from interference from the configuration
mismatch or incorrect routing updates. mismatch or incorrect routing updates.
The establishment of the routing plane and its parameters are The establishment of the routing plane and its parameters are
automatic and strictly within the confines of the autonomic control automatic and strictly within the confines of the autonomic control
plane. Therefore, no explicit configuration is required. plane. Therefore, no explicit configuration is required.
All routing updates are automatically secured in transit as the All routing updates are automatically secured in transit as the
channels of the autonomic control plane are by default secured, and channels of the autonomic control plane are by default secured, and
this routing runs only inside the ACP. this routing runs only inside the ACP.
The routing protocol inside the ACP is RPL ([RFC6550]). See The routing protocol inside the ACP is RPL ([RFC6550]). See
Section 10.7 for more details on the choice of RPL. Section 11.4 for more details on the choice of RPL.
RPL adjacencies are set up across all ACP channels in the same domain RPL adjacencies are set up across all ACP channels in the same domain
including all its routing subdomains. See Section 10.10 for more including all its routing subdomains. See Section 11.7 for more
details. details.
6.11.1. RPL Profile 6.11.1. RPL Profile
The following is a description of the RPL profile that ACP nodes need The following is a description of the RPL profile that ACP nodes need
to support by default. The format of this section is derived from to support by default. The format of this section is derived from
draft-ietf-roll-applicability-template. draft-ietf-roll-applicability-template.
6.11.1.1. Summary 6.11.1.1. Summary
skipping to change at page 71, line 35 skipping to change at page 72, line 35
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.3.4. As long a a with embedded sub-CA, as outlined in Section 10.2.4. As long a 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 18 skipping to change at page 75, line 18
be separated from visibility of Data-Plane so automated systems will be separated from visibility of Data-Plane so automated systems will
never have to deal with ACP aspect unless they explicitly desire to never have to deal with ACP aspect unless they explicitly desire to
do so. do so.
Since an ACP is self-protecting, a node not supporting the ACP, or Since an ACP is self-protecting, a node not supporting the ACP, or
without a valid domain certificate cannot connect to it. This means without a valid domain certificate cannot connect to it. This means
that by default a traditional controller or network management system that by default a traditional controller or network management system
cannot connect to an ACP. See Section 8.1.1 for more details on how cannot connect to an ACP. See Section 8.1.1 for more details on how
to connect an NMS host into the ACP. to connect an NMS host into the ACP.
10. Further Considerations (Informative) 10. ACP Operations (Informative)
The following sections cover topics that are beyond the primary scope
of this document (e.g., bootstrap), that explain decisions made in
this document (e.g.: choice of GRASP) or that explain desirable
extensions or implementation details for the ACP that are not
considered to be appropriate to standardize in this document.
10.1. BRSKI Bootstrap (ANI)
[I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes The following sections document important operational aspects of the
with an IDevID certificate can securely and zero-touch enroll with a ACP. They are not normative because they do not impact the
domain certificate (LDevID) to support the ACP. BRSKI also leverages interoperability between components of the ACP, but they include
the ACP to enable zero-touch bootstrap of new nodes across networks recommendations/requirements for possible followup standards work
without any configuration requirements across the transit nodes such as operational YANG model definitions:
(e.g., no DHCP/DNS forwarding/server setup). This includes otherwise
not configured networks as described in Section 3.2. Therefore BRSKI
in conjunction with ACP provides for a secure and zero-touch
management solution for complete networks. Nodes supporting such an
infrastructure (BRSKI and ACP) are called ANI nodes (Autonomic
Networking Infrastructure), see [I-D.ietf-anima-reference-model].
Nodes that do not support an IDevID but only an (insecure) vendor
specific Unique Device Identifier (UDI) or nodes whose manufacturer
does not support a MASA could use some future security reduced
version of BRSKI.
When BRSKI is used to provision a domain certificate (which is called o Section 10.1 describes recommended operator diagnostics
enrollment), the BRSKI registrar (acting as an enhanced EST server) capabilities of ACP nodes. The have been derived from diagnostic
must include the subjectAltName / rfc822Name encoded ACP address and of a commercially available ACP implementation.
domain name to the enrolling node (called pledge) via its response to
the pledges EST CSR Attribute request that is mandatory in BRSKI.
The Certificate Authority in an ACP network must not change the o Section 10.2 describes high level how an ACP registrar needs to
subjectAltName / rfc822Name in the certificate. The ACP nodes can work, what its configuration parameters are and specific issues
therefore find their ACP address and domain using this field in the impacting the choices of deployment design due to renewal and
domain certificate, both for themselves, as well as for other nodes. revocation issues. It describes a model where ACP Registrars have
their own sub-CA to provide the most disributed deployment option
for ACP Registrars, and it describes considerations for
centralized policy control of ACP Registrar operations.
The use of BRSKI in conjunction with the ACP can also help to further o Section 10.3 describes suggested ACP node behavior and operational
simplify maintenance and renewal of domain certificates. Instead of interfaces (configuration options) to manage the ACP in so-called
relying on CRL, the lifetime of certificates can be made extremely greenfield devices (previously unconfigured) and brownfield
small, for example in the order of hours. When a node fails to devices (preconfigured).
connect to the ACP within its certificate lifetime, it cannot connect
to the ACP to renew its certificate across it (using just EST), but
it can still renew its certificate as an "enrolled/expired pledge"
via the BRSKI bootstrap proxy. This requires only that the BRSKI
registrar honors expired domain certificates and that the pledge
first attempts to perform TLS authentication for BRSKI bootstrap with
its expired domain certificate - and only reverts to its IDevID when
this fails. This mechanism could also render CRLs unnecessary
because the BRSKI registrar in conjunction with the CA would not
renew revoked certificates - only a "Do-not-renew" list would be
necessary on BRSKI registrars/CA.
In the absence of BRSKI or less secure variants thereof, provisioning The recommendations and suggestions of this chapter were derived from
of certificates may involve one or more touches or non-standardized operational experience gained with a commercially available pre-
automation. Node vendors usually support provisioning of standard ACP implementation.
certificates into nodes via PKCS#7 (see [RFC2315]) and may support
this provisioning through vendor specific models via Netconf
([RFC6241]). If such nodes also support Netconf Zero-Touch
([I-D.ietf-netconf-zerotouch]) then this can be combined to zero-
touch provisioning of domain certificates into nodes. Unless there
are equivalent integration of Netconf connections across the ACP as
there is in BRSKI, this combination would not support zero-touch
bootstrap across a not configured network though.
10.2. ACP (and BRSKI) Diagnostics 10.1. ACP (and BRSKI) Diagnostics
Even though ACP and ANI in general are taking out many manual Even though ACP and ANI in general are taking out many manual
configuration mistakes through their automation, it is important to configuration mistakes through their automation, it is important to
provide good diagnostics for them. provide good diagnostics for them.
The basic diagnostics is support of (yang) data models representing The basic diagnostics is support of (yang) data models representing
the complete (auto-)configuration and operational state of all the complete (auto-)configuration and operational state of all
components: BRSKI, GRASP, ACP and the infrastructure used by them: components: BRSKI, GRASP, ACP and the infrastructure used by them:
TLS/DTLS, IPsec, certificates, trust anchors, time, VRF and so on. TLS/DTLS, IPsec, certificates, trust anchors, time, VRF and so on.
While necessary, this is not sufficient: While necessary, this is not sufficient:
skipping to change at page 76, line 46 skipping to change at page 77, line 8
The most simple form of diagnostics answering questions like the The most simple form of diagnostics answering questions like the
above is to represent the relevant information sequentially in above is to represent the relevant information sequentially in
dependency order, so that the first non-expected/non-operational item dependency order, so that the first non-expected/non-operational item
is the most likely root cause. Or just log/highlight that item. For is the most likely root cause. Or just log/highlight that item. For
example: example:
Q: Is ACP operational to accept neighbor connections: Q: Is ACP operational to accept neighbor connections:
o Check if any potentially necessary configuration to make ACP/ANI o Check if any potentially necessary configuration to make ACP/ANI
operational are correct (see Section 10.5 for a discussion of such operational are correct (see Section 10.3 for a discussion of such
commands). commands).
o Does the system time look reasonable, or could it be the default o Does the system time look reasonable, or could it be the default
system time after clock chip battery failure (certificate checks system time after clock chip battery failure (certificate checks
depend on reasonable notion of time). depend on reasonable notion of time).
o Does the node have keying material - domain certificate, trust o Does the node have keying material - domain certificate, trust
anchors. anchors.
o If no keying material and ANI is supported/enabled, check the o If no keying material and ANI is supported/enabled, check the
skipping to change at page 80, line 26 skipping to change at page 80, line 34
2. In alternative to LLDP, A DULL GRASP diagnostics objective could 2. In alternative to LLDP, A DULL GRASP diagnostics objective could
be defined to carry these information elements. be defined to carry these information elements.
3. The IDevID of BRSKI pledges should be included in the selected 3. The IDevID of BRSKI pledges should be included in the selected
insecure diagnostics option. insecure diagnostics option.
4. A richer set of diagnostics information should be made available 4. A richer set of diagnostics information should be made available
via the secured ACP channels, using either single-hop GRASP or via the secured ACP channels, using either single-hop GRASP or
network wide "topology discovery" mechanisms. network wide "topology discovery" mechanisms.
10.3. ACP Registrar Considerations 10.2. ACP Registrars
As described in Section 6.10.7, the ACP addressing mechanism is As described in Section 6.10.7, the ACP addressing mechanism is
designed to enable lightweight, distributed and uncoordinated ACP designed to enable lightweight, distributed and uncoordinated ACP
registrars that are providing ACP address prefixes to candidate ACP registrars that are providing ACP address prefixes to candidate ACP
nodes by enrolling them with an ACP domain certificate into an ACP nodes by enrolling them with an ACP domain certificate into an ACP
domain via any appropriate mechanism/protocol, automated or not. domain via any appropriate mechanism/protocol, automated or not.
This section discusses informatively more details and options for ACP This section discusses informatively more details and options for ACP
registrars. registrars.
10.3.1. Registrar interactions 10.2.1. Registrar interactions
This section summarizes and discusses the interactions with other This section summarizes and discusses the interactions with other
entities required by an ACP registrar. entities required by an ACP registrar.
In a simple instance of an ACP network, no central NOC component In a simple instance of an ACP network, no central NOC component
beside a trust anchor (root CA) is required. One or more beside a trust anchor (root CA) is required. 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
skipping to change at page 81, line 41 skipping to change at page 82, line 5
Netconf ZeroTouch are two protocols that include capabilities to Netconf ZeroTouch are two protocols that include capabilities to
present the voucher to the candidate ACP node. present the voucher to the candidate ACP 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 trust anchor via the ACP to ACP nodes and via the Data-Plane to the trust anchor
and other sources of CRL information. and other sources of CRL information.
10.3.2. Registrar Parameter 10.2.2. Registrar Parameter
The interactions of an ACP registrar outlined Section 6.10.7 and The interactions of an ACP registrar outlined Section 6.10.7 and
Section 10.3.1 above depend on the following parameters: Section 10.2.1 above depend on the following parameters:
A URL to the trust anchor (root CA) and credentials so that the A URL to the trust anchor (root CA) and credentials so that the
ACP registrar can let the trust anchor sign candidate ACP member ACP registrar can let the trust anchor sign candidate ACP member
certificates. certificates.
The ACP domain-name. The ACP domain-name.
The Registrar-ID to use. This could default to a MAC address of The Registrar-ID to use. This could default to a MAC address of
the ACP registrar. the ACP registrar.
skipping to change at page 82, line 29 skipping to change at page 82, line 40
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).
10.3.3. Certificate renewal and limitations 10.2.3. Certificate renewal and limitations
When an ACP node renews/rekeys its certificate, it may end up doing When an ACP node renews/rekeys its certificate, it may end up doing
so via a different registrar (e.g., EST server) than the one it so via a different registrar (e.g., EST server) than the one it
originally received its ACP domain certificate from, for example originally received its ACP domain certificate from, for example
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
skipping to change at page 83, line 12 skipping to change at page 83, line 23
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 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 - assuming one can
not retrieve this information from the . not retrieve this information from the .
10.3.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
skipping to change at page 83, line 45 skipping to change at page 84, line 7
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.3.5. Centralized Policy Control 10.2.5. Centralized Policy Control
When using multiple, uncoordinated ACP registrars, several advanced When using multiple, uncoordinated ACP registrars, several advanced
operations are potentially more complex than with a single, resilient operations are potentially more complex than with a single, resilient
policy control backend, for example including but not limited to: policy control backend, for example including but not limited to:
Which candidate ACP node is permitted or not permitted into an ACP Which candidate ACP node is permitted or not permitted into an ACP
domain. This may not be a decision to be taken upfront, so that a domain. This may not be a decision to be taken upfront, so that a
per-serialNumber policy can be loaded into ever ACP registrar. per-serialNumber policy can be loaded into ever ACP registrar.
Instead, it may better be decided in real-time including Instead, it may better be decided in real-time including
potentially a human decision in a NOC. potentially a human decision in a NOC.
skipping to change at page 84, line 26 skipping to change at page 84, line 37
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 occuring 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. Such an ACP registrar PMS interface onto a candidate ACP node. Such an ACP registrar PMS interface
definition is subject to future work. definition is subject to future work.
10.4. Address Space Considerations 10.3. Enabling and disabling ACP/ANI
This document defines the Zone, Vlong and Manual sub address schemes
primarily to support address prefix assignment via distributed,
potentially uncoordinated ACP registrars as defined in
Section 6.10.7. This costs 48/46 bit identifier so that these ACP
registrar can assign non-conflicting address prefixes. This design
does not leave enough bits to simultaneously support a large number
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
result, Zone, Vlong 8/16 attempt to support all features, but in via
separate prefixes.
In networks that always expect to rely on a centralized PMS as
described above (Section 10.3.5), the 48/46 bits for the Registrar-ID
could be saved. Such variations of the ACP addressing mecchanisms
could be introduct through future work in different ways. If the
prefix rfcSELF in the ACP information field was changed, incompatible
ACP variations could be created where every design aspect of the ACP
could be changed. Including all addressing choices. If instead a
new addressing sub-type would be defined, it could be a backward
compatible extension of this ACP specification. Information such as
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
ACP domain information.
Note that an explicitly defined "Manual" addressing sub-scheme is
always beneficial to provide an easy way for ACP nodes to prohibit
incorrect manual configuration of any non-"Manual" ACP address spaces
and therefore ensure hat "Manual" operations will never impact
correct routing for any non-"Manual" ACP addresses assigned via ACP
domain certificates.
10.5. 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
interfaces are by default (e.g., without operator configuration) interfaces are by default (e.g., without operator configuration)
enabled, such as most L2 switches, this would be less of a change in enabled, such as most L2 switches, this would be less of a change in
behavior than in most L3 devices (e.g.: routers), where interfaces behavior than in most L3 devices (e.g.: routers), where interfaces
are by default disabled. In almost all network devices it is common are by default disabled. In almost all network devices it is common
though for configuration to change interfaces to a physically though for configuration to change interfaces to a physically
disabled state and that would break the ACP. disabled state and that would break the ACP.
In this section, we discuss a suggested operational model to enable/ In this section, we discuss a suggested operational model to enable/
disable interfaces and nodes for ACP/ANI in a way that minimizes the disable interfaces and nodes for ACP/ANI in a way that minimizes the
risk of operator action to break the ACP in this way, and that also risk of operator action to break the ACP in this way, and that also
minimizes operator surprise when ACP/ANI becomes supported in node minimizes operator surprise when ACP/ANI becomes supported in node
software. software.
10.5.1. Filtering for non-ACP/ANI packets 10.3.1. Filtering for non-ACP/ANI packets
Whenever this document refers to enabling an interface for ACP (or Whenever this document refers to enabling an interface for ACP (or
BRSKI), it only requires to permit the interface to send/receive BRSKI), it only requires to permit the interface to send/receive
packets necessary to operate ACP (or BRSKI) - but not any other Data- packets necessary to operate ACP (or BRSKI) - but not any other Data-
Plane packets. Unless the Data-Plane is explicitly configured/ Plane packets. Unless the Data-Plane is explicitly configured/
enabled, all packets not required for ACP/BRSKI should be filtered on enabled, all packets not required for ACP/BRSKI should be filtered on
input and output: input and output:
Both BRSKI and ACP require link-local only IPv6 operations on Both BRSKI and ACP require link-local only IPv6 operations on
interfaces and DULL GRASP. IPv6 link-local operations means the interfaces and DULL GRASP. IPv6 link-local operations means the
skipping to change at page 86, line 5 skipping to change at page 85, line 30
Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery - Auto-Configuration - [RFC4862]) and ND (Neighbor Discovery -
[RFC4861]). When the device is a BRSKI pledge, it may also require [RFC4861]). When the device is a BRSKI pledge, it may also require
TCP/TLS connections to BRSKI proxies on the interface. When the TCP/TLS connections to BRSKI proxies on the interface. When the
device has keying material, and the ACP is running, it requires DULL device has keying material, and the ACP is running, it requires DULL
GRASP packets and packets necessary for the secure-channel mechanism GRASP packets and packets necessary for the secure-channel mechanism
it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the it supports, e.g., IKEv2 and IPsec ESP packets or DTLS packets to the
IPv6 link-local address of an ACP neighbor on the interface. It also IPv6 link-local address of an ACP neighbor on the interface. It also
requires TCP/TLS packets for its BRSKI proxy functionality, if it requires TCP/TLS packets for its BRSKI proxy functionality, if it
does support BRSKI. does support BRSKI.
10.5.2. Admin Down State 10.3.2. Admin Down State
Interfaces on most network equipment have at least two states: "up" Interfaces on most network equipment have at least two states: "up"
and "down". These may have product specific names. "down" for and "down". These may have product specific names. "down" for
example could be called "shutdown" and "up" could be called "no example could be called "shutdown" and "up" could be called "no
shutdown". The "down" state disables all interface operations down shutdown". The "down" state disables all interface operations down
to the physical level. The "up" state enables the interface enough to the physical level. The "up" state enables the interface enough
for all possible L2/L3 services to operate on top of it and it may for all possible L2/L3 services to operate on top of it and it may
also auto-enable some subset of them. More commonly, the operations also auto-enable some subset of them. More commonly, the operations
of various L2/L3 services is controlled via additional node-wide or of various L2/L3 services is controlled via additional node-wide or
interface level options, but they all become only active when the interface level options, but they all become only active when the
skipping to change at page 86, line 31 skipping to change at page 86, line 8
To provide ACP/ANI resilience against operators configuring To provide ACP/ANI resilience against operators configuring
interfaces to "down" state, this document recommends to separate the interfaces to "down" state, this document recommends to separate the
"down" state of interfaces into an "admin down" state where the "down" state of interfaces into an "admin down" state where the
physical layer is kept running and ACP/ANI can use the interface and physical layer is kept running and ACP/ANI can use the interface and
a "physical down" state. Any existing "down" configurations would a "physical down" state. Any existing "down" configurations would
map to "admin down". In "admin down", any existing L2/L3 services of map to "admin down". In "admin down", any existing L2/L3 services of
the Data-Plane should see no difference to "physical down" state. To the Data-Plane should see no difference to "physical down" state. To
ensure that no Data-Plane packets could be sent/received, packet ensure that no Data-Plane packets could be sent/received, packet
filtering could be established automatically as described above in filtering could be established automatically as described above in
Section 10.5.1. Section 10.3.1.
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.
10.5.2.1. Security 10.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
provides also a high level of security because it only permits ACP/ provides also a high level of security because it only permits ACP/
ANI operations which are both well secured. Ultimately, it is ANI operations which are both well secured. Ultimately, it is
subject to security review for the deployment whether "admin down" is subject to security review for the deployment whether "admin down" is
a feasible replacement for "physical down". a feasible replacement for "physical down".
The need to trust into the security of ACP/ANI operations need to be The need to trust into the security of ACP/ANI operations need to be
weighed against the operational benefits of permitting this: Consider weighed against the operational benefits of permitting this: Consider
skipping to change at page 87, line 20 skipping to change at page 86, line 46
the uplink connection is incorrectly plugged into such a user port. the uplink connection is incorrectly plugged into such a user port.
The device is disconnected from the network and therefore no The device is disconnected from the network and therefore no
diagnostics from the network side is possible anymore. diagnostics from the network side is possible anymore.
Alternatively, all ports default to "admin down". The ACP (but not Alternatively, all ports default to "admin down". The ACP (but not
the Data-Plane) would still automatically form. Diagnostics from the the Data-Plane) would still automatically form. Diagnostics from the
network side is possible and operator reaction could include to network side is possible and operator reaction could include to
either make this port the operational uplink port or to instruct re- either make this port the operational uplink port or to instruct re-
cabling. Security wise, only ACP/ANI could be attacked, all other cabling. Security wise, only ACP/ANI could be attacked, all other
functions are filtered on interfaces in "admin down" state. functions are filtered on interfaces in "admin down" state.
10.5.2.2. Fast state propagation and Diagnostics 10.3.2.2. Fast state propagation and Diagnostics
"Physical down" state propagates on many interface types (e.g., "Physical down" state propagates on many interface types (e.g.,
Ethernet) to the other side. This can trigger fast L2/L3 protocol Ethernet) to the other side. This can trigger fast L2/L3 protocol
reaction on the other side and "admin down" would not have the same reaction on the other side and "admin down" would not have the same
(fast) result. (fast) result.
Bringing interfaces to "physical down" state is to the best of our Bringing interfaces to "physical down" state is to the best of our
knowledge always a result of operator action, but today, never the knowledge always a result of operator action, but today, never the
result of (autonomic) L2/L3 services running on the nodes. Therefore result of (autonomic) L2/L3 services running on the nodes. Therefore
one option is to change the operator action to not rely on link-state one option is to change the operator action to not rely on link-state
skipping to change at page 87, line 49 skipping to change at page 87, line 27
Protocol (BFD, [RFC5880]) session between the two sides of the link Protocol (BFD, [RFC5880]) session between the two sides of the link
that would be used to propagate the "up" vs. admin down state. that would be used to propagate the "up" vs. admin down state.
Triggering physical down state may also be used as a mean of Triggering physical down state may also be used as a mean of
diagnosing cabling in the absence of easier methods. It is more diagnosing cabling in the absence of easier methods. It is more
complex than automated neighbor diagnostics because it requires complex than automated neighbor diagnostics because it requires
coordinated remote access to both (likely) sides of a link to coordinated remote access to both (likely) sides of a link to
determine whether up/down toggling will cause the same reaction on determine whether up/down toggling will cause the same reaction on
the remote side. the remote side.
See Section 10.2 for a discussion about how LLDP and/or diagnostics See Section 10.1 for a discussion about how LLDP and/or diagnostics
via GRASP could be used to provide neighbor diagnostics, and via GRASP could be used to provide neighbor diagnostics, and
therefore hopefully eliminating the need for "physical down" for therefore hopefully eliminating the need for "physical down" for
neighbor diagnostics - as long as both neighbors support ACP/ANI. neighbor diagnostics - as long as both neighbors support ACP/ANI.
10.5.2.3. Low Level Link Diagnostics 10.3.2.3. Low Level Link Diagnostics
"Physical down" is performed to diagnose low-level interface behavior "Physical down" is performed to diagnose low-level interface behavior
when higher layer services (e.g., IPv6) are not working. Especially when higher layer services (e.g., IPv6) are not working. Especially
Ethernet links are subject to a wide variety of possible wrong Ethernet links are subject to a wide variety of possible wrong
configuration/cablings if they do not support automatic selection of configuration/cablings if they do not support automatic selection of
variable parameters such as speed (10/100/1000 Mbps), crossover variable parameters such as speed (10/100/1000 Mbps), crossover
(Auto-MDIX) and connector (fiber, copper - when interfaces have (Auto-MDIX) and connector (fiber, copper - when interfaces have
multiple but can only enable one at a time). The need for low level multiple but can only enable one at a time). The need for low level
link diagnostic can therefore be minimized by using fully auto link diagnostic can therefore be minimized by using fully auto
configuring links. configuring links.
skipping to change at page 88, line 30 skipping to change at page 88, line 8
bringing down all packet transmissions for reflection/cable-length bringing down all packet transmissions for reflection/cable-length
measurements. Any of these options would disrupt ACP as well. measurements. Any of these options would disrupt ACP as well.
In cases where such low-level diagnostics of an operational link is In cases where such low-level diagnostics of an operational link is
desired but where the link could be a single point of failure for the desired but where the link could be a single point of failure for the
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.5.2.4. Power Consumption 10.3.2.4. Power Consumption
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. Assuming reasonable clocks on devices, mechanisms fiber interfaces. Assuming reasonable clocks on devices, mechanisms
for infrequent periodic probing could allow to automatically for infrequent periodic probing could allow to automatically
establish ACP connectivity across such links. Bring up interfaces establish ACP connectivity across such links. Bring up interfaces
for 5 seconds to probe if there is an ACP neighbor on the remote end for 5 seconds to probe if there is an ACP neighbor on the remote end
every 500 seconds = 1% power consumption. every 500 seconds = 1% power consumption.
10.5.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,
"ACP enable" may not need to be supported, but only "ANI enable". "ACP enable" may not need to be supported, but only "ANI enable".
Unless overridden by global configuration options (see later), "ACP/ Unless overridden by global configuration options (see later), "ACP/
ANI enable" will result in "down" state on an interface to behave as ANI enable" will result in "down" state on an interface to behave as
"admin down". "admin down".
10.5.4. Which interfaces to auto-enable? 10.3.4. Which interfaces to auto-enable?
(Section 6.3) requires that "ACP enable" is automatically set on (Section 6.3) requires that "ACP enable" is automatically set on
native interfaces, but not on non-native interfaces (reminder: a native interfaces, but not on non-native interfaces (reminder: a
native interface is one that exists without operator configuration native interface is one that exists without operator configuration
action such as physical interfaces in physical devices). action such as physical interfaces in physical devices).
Ideally, ACP enable is set automatically on all interfaces that Ideally, ACP enable is set automatically on all interfaces that
provide access to additional connectivity that allows to reach more provide access to additional connectivity that allows to reach more
nodes of the ACP domain. The best set of interfaces necessary to nodes of the ACP domain. The best set of interfaces necessary to
achieve this is not possible to determine automatically. Native achieve this is not possible to determine automatically. Native
skipping to change at page 90, line 25 skipping to change at page 90, line 5
make its operation as much as possible "zero-touch" with respect to make its operation as much as possible "zero-touch" with respect to
ACP/ANI. If there are "unavoidable touches" such a creating/ ACP/ANI. If there are "unavoidable touches" such a creating/
configuring a non-native interface or provisioning credentials for a configuring a non-native interface or provisioning credentials for a
native interface, then "ACP/ANI enable" should be added as an option native interface, then "ACP/ANI enable" should be added as an option
to that "touch". If a wrong "touch" is easily fixed (not creating to that "touch". If a wrong "touch" is easily fixed (not creating
another high-cost touch), then the default should be not to enable another high-cost touch), then the default should be not to enable
ANI/ACP, and if it is potentially expensive or slow to fix (e.g., ANI/ACP, and if it is potentially expensive or slow to fix (e.g.,
parameters on SIM card shipped to remote location), then the default parameters on SIM card shipped to remote location), then the default
should be to enable ACP/ANI. should be to enable ACP/ANI.
10.5.5. Node Level ACP/ANI enable 10.3.5. Node Level ACP/ANI enable
A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI A node level command "ACP/ANI enable [up-if-only]" enables ACP or ANI
on the node (ANI = ACP + BRSKI). Without this command set, any on the node (ANI = ACP + BRSKI). Without this command set, any
interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will
operate interface where "ACP/ANI enable" is set. Setting of operate interface where "ACP/ANI enable" is set. Setting of
interface level "ACP/ANI enable" is either automatic (default) or interface level "ACP/ANI enable" is either automatic (default) or
explicit through operator action as described in the previous explicit through operator action as described in the previous
section. section.
If the option "up-if-only" is selected, the behavior of "down" If the option "up-if-only" is selected, the behavior of "down"
interfaces is unchanged, and ACP/ANI will only operate on interfaces interfaces is unchanged, and ACP/ANI will only operate on interfaces
where "ACP/ANI enable" is set and that are "up". When it is not set, where "ACP/ANI enable" is set and that are "up". When it is not set,
then "down" state of interfaces with "ACP/ANI enable" is modified to then "down" state of interfaces with "ACP/ANI enable" is modified to
behave as "admin down". behave as "admin down".
10.5.5.1. Brownfield nodes 10.3.5.1. Brownfield nodes
A "brownfield" node is one that already has a configured Data-Plane. A "brownfield" node is one that already has a configured Data-Plane.
Executing global "ACP/ANI enable [up-if-only]" on each node is the Executing global "ACP/ANI enable [up-if-only]" on each node is the
only command necessary to create an ACP across a network of only command necessary to create an ACP across a network of
brownfield nodes once all the nodes have a domain certificate. When brownfield nodes once all the nodes have a domain certificate. When
BRSKI is used ("ANI enable"), provisioning of the certificates only BRSKI is used ("ANI enable"), provisioning of the certificates only
requires set-up of a single BRSKI registrar node which could also requires set-up of a single BRSKI registrar node which could also
implement a CA for the network. This is the most simple way to implement a CA for the network. This is the most simple way to
introduce ACP/ANI into existing (== brownfield) networks. introduce ACP/ANI into existing (== brownfield) networks.
skipping to change at page 91, line 25 skipping to change at page 91, line 5
could claim to be the owner of these devices and create an ACP that could claim to be the owner of these devices and create an ACP that
the attacker has access/control over. In network where the operator the attacker has access/control over. In network where the operator
explicitly wants to enable the ANI this could not happen, because he explicitly wants to enable the ANI this could not happen, because he
would create a BRSKI registrar that would discover attack attempts. would create a BRSKI registrar that would discover attack attempts.
Nodes requiring "ownership vouchers" would not be subject to that Nodes requiring "ownership vouchers" would not be subject to that
attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more
details. Note that a global "ACP enable" alone is not subject to details. Note that a global "ACP enable" alone is not subject to
these type of attacks, because it always depends on some other these type of attacks, because it always depends on some other
mechanism first to provision domain certificates into the device. mechanism first to provision domain certificates into the device.
10.5.5.2. Greenfield nodes 10.3.5.2. Greenfield nodes
A "greenfield" node is one that did not have any prior configuration. A "greenfield" node is one that did not have any prior configuration.
For greenfield nodes, only "ANI enable" is relevant. If another For greenfield nodes, only "ANI enable" is relevant. If another
mechanism than BRSKI is used to (zero-touch) bootstrap a node, then mechanism than BRSKI is used to (zero-touch) bootstrap a node, then
it is up to that mechanism to provision domain certificates and to it is up to that mechanism to provision domain certificates and to
set global "ACP enable" as desired. set global "ACP enable" as desired.
Nodes supporting full ANI functionality set "ANI enable" Nodes supporting full ANI functionality set "ANI enable"
automatically when they decide that they are greenfield, e.g., that automatically when they decide that they are greenfield, e.g., that
skipping to change at page 92, line 5 skipping to change at page 91, line 34
the device such as configuration via the serial console could lead to the device such as configuration via the serial console could lead to
immediate termination of BRSKI, while other parallel auto immediate termination of BRSKI, while other parallel auto
configuration methods subject to remote attacks might lead to BRSKI configuration methods subject to remote attacks might lead to BRSKI
termination only after they were successful. Details of this may termination only after they were successful. Details of this may
vary widely over different type of nodes. When BRSKI pledge vary widely over different type of nodes. When BRSKI pledge
operation terminates, this will automatically unset "ANI enable" and operation terminates, this will automatically unset "ANI enable" and
should terminate any temporarily needed state on the device to should terminate any temporarily needed state on the device to
perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration
on interfaces. on interfaces.
10.5.6. Undoing ANI/ACP enable 10.3.6. Undoing ANI/ACP enable
Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the
reliable operations of the ACP if it can be executed by mistake or reliable operations of the ACP if it can be executed by mistake or
unauthorized. This behavior could be influenced through some unauthorized. This behavior could be influenced through some
additional property in the certificate (e.g., in the domain additional property in the certificate (e.g., in the domain
information extension field) subject to future work: In an ANI information extension field) subject to future work: In an ANI
deployment intended for convenience, disabling it could be allowed deployment intended for convenience, disabling it could be allowed
without further constraints. In an ANI deployment considered to be without further constraints. In an ANI deployment considered to be
critical more checks would be required. One very controlled option critical more checks would be required. One very controlled option
would be to not permit these commands unless the domain certificate would be to not permit these commands unless the domain certificate
has been revoked or is denied renewal. Configuring this option would has been revoked or is denied renewal. Configuring this option would
be a parameter on the BRSKI registrar(s). As long as the node did be a parameter on the BRSKI registrar(s). As long as the node did
not receive a domain certificate, undoing "ANI/ACP enable" should not not receive a domain certificate, undoing "ANI/ACP enable" should not
have any additional constraints. have any additional constraints.
10.5.7. Summary 10.3.7. Summary
Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation Node-wide "ACP/ANI enable [up-if-only]" commands enable the operation
of ACP/ANI. This is only auto-enabled on ANI greenfield devices, of ACP/ANI. This is only auto-enabled on ANI greenfield devices,
otherwise it must be configured explicitly. otherwise it must be configured explicitly.
If the option "up-if-only" is not selected, interfaces enabled for If the option "up-if-only" is not selected, interfaces enabled for
ACP/ANI interpret "down" state as "admin down" and not "physical ACP/ANI interpret "down" state as "admin down" and not "physical
down". In "admin-down" all non-ACP/ANI packets are filtered, but the down". In "admin-down" all non-ACP/ANI packets are filtered, but the
physical layer is kept running to permit ACP/ANI to operate. physical layer is kept running to permit ACP/ANI to operate.
skipping to change at page 92, line 45 skipping to change at page 92, line 29
Interface level "ACP/ANI enable" control per-interface operations. Interface level "ACP/ANI enable" control per-interface operations.
It is enabled by default on native interfaces and has to be It is enabled by default on native interfaces and has to be
configured explicitly on other interfaces. configured explicitly on other interfaces.
Disabling "ACP/ANI enable" global and per-interface should have Disabling "ACP/ANI enable" global and per-interface should have
additional checks to minimize undesired breakage of ACP. The degree additional checks to minimize undesired breakage of ACP. The degree
of control could be a domain wide parameter in the domain of control could be a domain wide parameter in the domain
certificates. certificates.
10.6. ACP Neighbor discovery protocol selection 11. Background and Futures (Informative)
The following sections discuss additional background information
about aspects of the normative parts of this document or associated
mechanisms such as BRSKI (such as why specific choices where made by
the ACP) and they provide discussion about possble future variations
of the ACP.
11.1. ACP Address Space Schemes
This document defines the Zone, Vlong and Manual sub address schemes
primarily to support address prefix assignment via distributed,
potentially uncoordinated ACP registrars as defined in
Section 6.10.7. This costs 48/46 bit identifier so that these ACP
registrar can assign non-conflicting address prefixes. This design
does not leave enough bits to simultaneously support a large number
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
result, Zone, Vlong 8/16 attempt to support all features, but in via
separate prefixes.
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
could be saved. Such variations of the ACP addressing mecchanisms
could be introduct through future work in different ways. If the
prefix rfcSELF in the ACP information field was changed, incompatible
ACP variations could be created where every design aspect of the ACP
could be changed. Including all addressing choices. If instead a
new addressing sub-type would be defined, it could be a backward
compatible extension of this ACP specification. Information such as
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
ACP domain information.
Note that an explicitly defined "Manual" addressing sub-scheme is
always beneficial to provide an easy way for ACP nodes to prohibit
incorrect manual configuration of any non-"Manual" ACP address spaces
and therefore ensure hat "Manual" operations will never impact
correct routing for any non-"Manual" ACP addresses assigned via ACP
domain certificates.
11.2. BRSKI Bootstrap (ANI)
[I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes
with an IDevID certificate can securely and zero-touch enroll with a
domain certificate (LDevID) to support the ACP. BRSKI also leverages
the ACP to enable zero-touch bootstrap of new nodes across networks
without any configuration requirements across the transit nodes
(e.g., no DHCP/DNS forwarding/server setup). This includes otherwise
not configured networks as described in Section 3.2. Therefore BRSKI
in conjunction with ACP provides for a secure and zero-touch
management solution for complete networks. Nodes supporting such an
infrastructure (BRSKI and ACP) are called ANI nodes (Autonomic
Networking Infrastructure), see [I-D.ietf-anima-reference-model].
Nodes that do not support an IDevID but only an (insecure) vendor
specific Unique Device Identifier (UDI) or nodes whose manufacturer
does not support a MASA could use some future security reduced
version of BRSKI.
When BRSKI is used to provision a domain certificate (which is called
enrollment), the BRSKI registrar (acting as an enhanced EST server)
must include the subjectAltName / rfc822Name encoded ACP address and
domain name to the enrolling node (called pledge) via its response to
the pledges EST CSR Attribute request that is mandatory in BRSKI.
The Certificate Authority in an ACP network must not change the
subjectAltName / rfc822Name in the certificate. The ACP nodes can
therefore find their ACP address and domain using this field in the
domain certificate, both for themselves, as well as for other nodes.
The use of BRSKI in conjunction with the ACP can also help to further
simplify maintenance and renewal of domain certificates. Instead of
relying on CRL, the lifetime of certificates can be made extremely
small, for example in the order of hours. When a node fails to
connect to the ACP within its certificate lifetime, it cannot connect
to the ACP to renew its certificate across it (using just EST), but
it can still renew its certificate as an "enrolled/expired pledge"
via the BRSKI bootstrap proxy. This requires only that the BRSKI
registrar honors expired domain certificates and that the pledge
first attempts to perform TLS authentication for BRSKI bootstrap with
its expired domain certificate - and only reverts to its IDevID when
this fails. This mechanism could also render CRLs unnecessary
because the BRSKI registrar in conjunction with the CA would not
renew revoked certificates - only a "Do-not-renew" list would be
necessary on BRSKI registrars/CA.
In the absence of BRSKI or less secure variants thereof, provisioning
of certificates may involve one or more touches or non-standardized
automation. Node vendors usually support provisioning of
certificates into nodes via PKCS#7 (see [RFC2315]) and may support
this provisioning through vendor specific models via Netconf
([RFC6241]). If such nodes also support Netconf Zero-Touch
([I-D.ietf-netconf-zerotouch]) then this can be combined to zero-
touch provisioning of domain certificates into nodes. Unless there
are equivalent integration of Netconf connections across the ACP as
there is in BRSKI, this combination would not support zero-touch
bootstrap across a not configured network though.
11.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.
10.6.1. LLDP 11.3.1. LLDP
LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example
of L2 discovery protocols that terminate their messages on L2 ports. of L2 discovery protocols that terminate their messages on L2 ports.
If those protocols would be chosen for ACP neighbor discovery, ACP If those protocols would be chosen for ACP neighbor discovery, ACP
neighbor discovery would therefore also terminate on L2 ports. This neighbor discovery would therefore also terminate on L2 ports. This
would prevent ACP construction over non-ACP capable but LLDP or CDP would prevent ACP construction over non-ACP capable but LLDP or CDP
enabled L2 switches. LLDP has extensions using different MAC enabled L2 switches. LLDP has extensions using different MAC
addresses and this could have been an option for ACP discovery as addresses and this could have been an option for ACP discovery as
well, but the additional required IEEE standardization and definition well, but the additional required IEEE standardization and definition
of a profile for such a modified instance of LLDP seemed to be more of a profile for such a modified instance of LLDP seemed to be more
work than the benefit of "reusing the existing protocol" LLDP for work than the benefit of "reusing the existing protocol" LLDP for
this very simple purpose. this very simple purpose.
10.6.2. mDNS and L2 support 11.3.2. mDNS and L2 support
Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD) Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD)
Resource Records (RRs) as defined in [RFC6763] is a key contender as Resource Records (RRs) as defined in [RFC6763] is a key contender as
an ACP discovery protocol. because it relies on link-local IP an ACP discovery protocol. because it relies on link-local IP
multicast, it does operates at the subnet level, and is also found in multicast, it does operates at the subnet level, and is also found in
L2 switches. The authors of this document are not aware of mDNS L2 switches. The authors of this document are not aware of mDNS
implementation that terminate their mDNS messages on L2 ports instead implementation that terminate their mDNS messages on L2 ports instead
of the subnet level. If mDNS was used as the ACP discovery mechanism of the subnet level. If mDNS was used as the ACP discovery mechanism
on an ACP capable (L3)/L2 switch as outlined in Section 7, then this on an ACP capable (L3)/L2 switch as outlined in Section 7, then this
would be necessary to implement. It is likely that termination of would be necessary to implement. It is likely that termination of
mDNS messages could only be applied to all mDNS messages from such a mDNS messages could only be applied to all mDNS messages from such a
port, which would then make it necessary to software forward any non- port, which would then make it necessary to software forward any non-
ACP related mDNS messages to maintain prior non-ACP mDNS ACP related mDNS messages to maintain prior non-ACP mDNS
functionality. Adding support for ACP into such L2 switches with functionality. Adding support for ACP into such L2 switches with
mDNS could therefore create regression problems for prior mDNS mDNS could therefore create regression problems for prior mDNS
functionality on those nodes. With low performance of software functionality on those nodes. With low performance of software
forwarding in many L2 switches, this could also make the ACP risky to forwarding in many L2 switches, this could also make the ACP risky to
support on such L2 switches. support on such L2 switches.
10.6.3. Why DULL GRASP 11.3.3. Why DULL GRASP
LLDP was not considered because of the above mentioned issues. mDNS LLDP was not considered because of the above mentioned issues. mDNS
was not selected because of the above L2 mDNS considerations and was not selected because of the above L2 mDNS considerations and
because of the following additional points: because of the following additional points:
If mDNS was not already existing in a node, it would be more work to If mDNS was not already existing in a node, it would be more work to
implement than DULL GRASP, and if an existing implementation of mDNS implement than DULL GRASP, and if an existing implementation of mDNS
was used, it would likely be more code space than a separate was used, it would likely be more code space than a separate
implementation of DULL GRASP or a shared implementation of DULL GRASP implementation of DULL GRASP or a shared implementation of DULL GRASP
and GRASP in the ACP. and GRASP in the ACP.
10.7. Choice of routing protocol (RPL) 11.4. Choice of routing protocol (RPL)
This section motivates why RPL - "IPv6 Routing Protocol for Low-Power This section motivates why RPL - "IPv6 Routing Protocol for Low-Power
and Lossy Networks ([RFC6550] was chosen as the default (and in this and Lossy Networks ([RFC6550] was chosen as the default (and in this
specification only) routing protocol for the ACP. The choice and specification only) routing protocol for the ACP. The choice and
above explained profile was derived from a pre-standard above explained profile was derived from a pre-standard
implementation of ACP that was successfully deployed in operational implementation of ACP that was successfully deployed in operational
networks. networks.
Requirements for routing in the ACP are: Requirements for routing in the ACP are:
skipping to change at page 95, line 31 skipping to change at page 97, line 14
several parallel DODAGs, should this be required. This could be several parallel DODAGs, should this be required. This could be
used to create different topologies to reach different roots. used to create different topologies to reach different roots.
o No need for path optimization: RPL does not necessarily compute o No need for path optimization: RPL does not necessarily compute
the optimal path between any two nodes. However, the ACP does not the optimal path between any two nodes. However, the ACP does not
require this today, since it carries mainly non-delay-sensitive require this today, since it carries mainly non-delay-sensitive
feedback loops. It is possible that different optimization feedback loops. It is possible that different optimization
schemes become necessary in the future, but RPL can be expanded schemes become necessary in the future, but RPL can be expanded
(see point "Extensibility" above). (see point "Extensibility" above).
10.8. ACP Information Distribution and multicast 11.5. ACP Information Distribution and multicast
IP multicast is not used by the ACP because the ANI (Autonomic IP multicast is not used by the ACP because the ANI (Autonomic
Networking Infrastructure) itself does not require IP multicast but Networking Infrastructure) itself does not require IP multicast but
only service announcement/discovery. Using IP multicast for that only service announcement/discovery. Using IP multicast for that
would have made it necessary to develop a zero-touch auto configuring would have made it necessary to develop a zero-touch auto configuring
solution for ASM (Any Source Multicast - the original form of IP solution for ASM (Any Source Multicast - the original form of IP
multicast defined in [RFC1112]), which would be quite complex and multicast defined in [RFC1112]), which would be quite complex and
difficult to justify. One aspect of complexity where no attempt at a difficult to justify. One aspect of complexity where no attempt at a
solution has been described in IETF documents is the automatic- solution has been described in IETF documents is the automatic-
selection of routers that should be PIM Sparse Mode (PIM-SM) selection of routers that should be PIM Sparse Mode (PIM-SM)
skipping to change at page 96, line 31 skipping to change at page 98, line 15
Because the ACP uses RPL, one desirable future extension is to use Because the ACP uses RPL, one desirable future extension is to use
RPLs existing notion of loop-free distribution trees (DODAG) to make RPLs existing notion of loop-free distribution trees (DODAG) to make
GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See
Section 6.12.5 how this will be specifically beneficial when using Section 6.12.5 how this will be specifically beneficial when using
NBMA interfaces. This is not currently specified in this document NBMA interfaces. This is not currently specified in this document
because it is not quite clear yet what exactly the implications are because it is not quite clear yet what exactly the implications are
to make GRASP flooding depend on RPL DODAG convergence and how to make GRASP flooding depend on RPL DODAG convergence and how
difficult it would be to let GRASP flooding access the DODAG difficult it would be to let GRASP flooding access the DODAG
information. information.
10.9. Extending ACP channel negotiation (via GRASP) 11.6. Extending ACP channel negotiation (via GRASP)
The mechanism described in the normative part of this document to The mechanism described in the normative part of this document to
support multiple different ACP secure channel protocols without a support multiple different ACP secure channel protocols without a
single network wide MTI protocol is important to allow extending single network wide MTI protocol is important to allow extending
secure ACP channel protocols beyond what is specified in this secure ACP channel protocols beyond what is specified in this
document, but it will run into problem if it would be used for document, but it will run into problem if it would be used for
multiple protocols: multiple protocols:
The need to potentially have multiple of these security associations The need to potentially have multiple of these security associations
even temporarily run in parallel to determine which of them works even temporarily run in parallel to determine which of them works
skipping to change at page 98, line 18 skipping to change at page 100, line 5
o TLS is subject to reset attacks, which IKEv2 is not. Normally, o TLS is subject to reset attacks, which IKEv2 is not. Normally,
ACP connections (as specified in this document) will be over link- ACP connections (as specified in this document) will be over link-
local addresses so the attack surface for this one issue in TCP local addresses so the attack surface for this one issue in TCP
should be reduced (note that this may not be true when ACP is should be reduced (note that this may not be true when ACP is
tunneled as described in Section 8.2.2. tunneled as described in Section 8.2.2.
o GRASP packets received inside a TLS connection established for o GRASP packets received inside a TLS connection established for
GRASP/TLS ACP negotiation are assigned to a separate GRASP domain GRASP/TLS ACP negotiation are assigned to a separate GRASP domain
unique to that TLS connection. unique to that TLS connection.
10.10. CAs, domains and routing subdomains 11.7. CAs, domains and routing subdomains
There is a wide range of setting up different ACP solution by There is a wide range of setting up different ACP solution by
appropriately using CAs and the domain and rsub elements in the appropriately using CAs and the domain and rsub elements in the
domain information field of the domain certificate. We summarize domain information field of the domain certificate. We summarize
these options here as they have been explained in different parts of these options here as they have been explained in different parts of
the document in before and discuss possible and desirable extensions: the document in before and discuss possible and desirable extensions:
An ACP domain is the set of all ACP nodes using certificates from the An ACP domain is the set of all ACP nodes using certificates from the
same CA using the same domain field. GRASP inside the ACP is run same CA using the same domain field. GRASP inside the ACP is run
across all transitively connected ACP nodes in a domain. across all transitively connected ACP nodes in a domain.
skipping to change at page 99, line 46 skipping to change at page 101, line 33
could also allow for Intent to only be injected into the network from could also allow for Intent to only be injected into the network from
one side and propagate via this GRASP connection. one side and propagate via this GRASP connection.
If different domains have different CAs, they should start to trust If different domains have different CAs, they should start to trust
each other by intent injected into both domains that would add the each other by intent injected into both domains that would add the
other domains CA as a trust point during the ACP connection setup - other domains CA as a trust point during the ACP connection setup -
and then following up with the previous point of inter-domain and then following up with the previous point of inter-domain
connections across domains with the same CA (e.g., GRASP connections across domains with the same CA (e.g., GRASP
negotiation). negotiation).
10.11. Adopting ACP concepts for other environments 11.8. 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:
The ACP specifies the use of ULA and deriving its prefix from the The ACP specifies the use of ULA and deriving its prefix from the
domain name so that no address allocation is required to deploy the domain name so that no address allocation is required to deploy the
ACP. The ACP will equally work not using ULA but any other /50 IPv6 ACP. The ACP will equally work not using ULA but any other /50 IPv6
prefix. This prefix could simply be a configuration of the ACP prefix. This prefix could simply be a configuration of the ACP
skipping to change at page 101, line 36 skipping to change at page 103, line 23
encapsulation are easily added to ACP solutions. Secure channels may encapsulation are easily added to ACP solutions. Secure channels may
even be replaced by simple neighbor authentication to create even be replaced by simple neighbor authentication to create
simplified ACP variations for environments where no real security is simplified ACP variations for environments where no real security is
required but just protection against non-malicious misconfiguration. required but just protection against non-malicious misconfiguration.
Or for environments where all traffic is known or forced to be end- Or for environments where all traffic is known or forced to be end-
to-end protected and other means for infrastructure protection are to-end protected and other means for infrastructure protection are
used. Any future network OAM should always use end-to-end security used. Any future network OAM should always use end-to-end security
anyhow and can leverage the domain certificates and is therefore not anyhow and can leverage the domain certificates and is therefore not
dependent on security to be provided for by ACP secure channels. dependent on security to be provided for by ACP secure channels.
11. Security Considerations 12. Security Considerations
An ACP is self-protecting and there is no need to apply configuration An ACP is self-protecting and there is no need to apply configuration
to make it secure. Its security therefore does not depend on to make it secure. Its security therefore does not depend on
configuration. configuration.
However, the security of the ACP depends on a number of other However, the security of the ACP depends on a number of other
factors: factors:
o The usage of domain certificates depends on a valid supporting PKI o The usage of domain certificates depends on a valid supporting PKI
infrastructure. If the chain of trust of this PKI infrastructure infrastructure. If the chain of trust of this PKI infrastructure
skipping to change at page 102, line 36 skipping to change at page 104, line 25
outside, but also by attacks from compromised inside attackers - by outside, but also by attacks from compromised inside attackers - by
relying not only on hop-by-hop security of ACP secure channels, but relying not only on hop-by-hop security of ACP secure channels, but
adding end-to-end security for those GRASP messages. See adding end-to-end security for those GRASP messages. See
Section 6.8.2. Section 6.8.2.
ACP provides for secure, resilient zero-touch discovery of EST ACP provides for secure, resilient zero-touch discovery of EST
servers for certificate renewal. See Section 6.1.3. servers for certificate renewal. See Section 6.1.3.
ACP provides extensible, auto-configuring hop-by-hop protection of ACP provides extensible, auto-configuring hop-by-hop protection of
the ACP infrastructure via the negotiation of hop-by-hop secure the ACP infrastructure via the negotiation of hop-by-hop secure
channel protocols. See Section 6.5 and Section 10.9. channel protocols. See Section 6.5 and Section 11.6.
The ACP is designed to minimize attacks from the outside by The ACP is designed to minimize attacks from the outside by
minimizing its dependency against any non-ACP operations on a node. minimizing its dependency against any non-ACP operations on a node.
The only dependency in the specification in this document is the need The only dependency in the specification in this document is the need
to share link-local addresses for the ACP secure channel to share link-local addresses for the ACP secure channel
encapsulation with the Data-Plane. See Section 6.12.2. encapsulation with the Data-Plane. See Section 6.12.2.
In combination with BRSKI, ACP enables a resilient, fully zero-touch In combination with BRSKI, ACP enables a resilient, fully zero-touch
network solution for short-lived certificates that can be renewed or network solution for short-lived certificates that can be renewed or
re-enrolled even after unintentional expiry (e.g., because of re-enrolled even after unintentional expiry (e.g., because of
interrupted connectivity). See Section 10.1. interrupted connectivity). See Section 11.2.
12. IANA Considerations 13. IANA Considerations
This document defines the "Autonomic Control Plane". This document defines the "Autonomic Control Plane".
The IANA is requested to register the value "AN_ACP" (without quotes) The IANA is requested to register the value "AN_ACP" (without quotes)
to the GRASP Objectives Names Table in the GRASP Parameter Registry. to the GRASP Objectives Names Table in the GRASP Parameter Registry.
The specification for this value is this document, Section 6.3. The specification for this value is this document, Section 6.3.
The IANA is requested to register the value "SRV.est" (without The IANA is requested to register the value "SRV.est" (without
quotes) to the GRASP Objectives Names Table in the GRASP Parameter quotes) to the GRASP Objectives Names Table in the GRASP Parameter
Registry. The specification for this value is this document, Registry. The specification for this value is this document,
skipping to change at page 103, line 36 skipping to change at page 105, line 20
"ACP Address Type" Table. The value in this table are numeric values "ACP Address Type" Table. The value in this table are numeric values
0...3 paired with a name (string). Future values MUST be assigned 0...3 paired with a name (string). Future values MUST be assigned
using the Standards Action policy defined by [RFC8126]. The using the Standards Action policy defined by [RFC8126]. The
following initial values are assigned by this document: following initial values are assigned by this document:
0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 9) / ACP Manual 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 9) / ACP Manual
Addressing Sub-Scheme (ACP RFC Section 6.10.4) Addressing Sub-Scheme (ACP RFC Section 6.10.4)
1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5)
13. Acknowledgements 14. Acknowledgements
This work originated from an Autonomic Networking project at Cisco This work originated from an Autonomic Networking project at Cisco
Systems, which started in early 2010. Many people contributed to Systems, which started in early 2010. Many people contributed to
this project and the idea of the Autonomic Control Plane, amongst this project and the idea of the Autonomic Control Plane, amongst
which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji
BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael
Richardson, Ravi Kumar Vadapalli. Richardson, Ravi Kumar Vadapalli.
Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and
Sheng Jiang for their thorough reviews and to Pascal Thubert and Sheng Jiang for their thorough reviews and to Pascal Thubert and
Michael Richardson to provide the details for the recommendations of Michael Richardson to provide the details for the recommendations of
the use of RPL in the ACP. the use of RPL in the ACP.
Further input, review or suggestions were received from: Rene Struik, Further input, review or suggestions were received from: Rene Struik,
Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang.
14. Change log [RFC Editor: Please remove] 15. Change log [RFC Editor: Please remove]
14.1. Initial version 15.1. Initial version
First version of this document: draft-behringer-autonomic-control- First version of this document: draft-behringer-autonomic-control-
plane plane
14.2. draft-behringer-anima-autonomic-control-plane-00 15.2. draft-behringer-anima-autonomic-control-plane-00
Initial version of the anima document; only minor edits. Initial version of the anima document; only minor edits.
14.3. draft-behringer-anima-autonomic-control-plane-01 15.3. draft-behringer-anima-autonomic-control-plane-01
o Clarified that the ACP should be based on, and support only IPv6. o Clarified that the ACP should be based on, and support only IPv6.
o Clarified in intro that ACP is for both, between devices, as well o Clarified in intro that ACP is for both, between devices, as well
as for access from a central entity, such as an NMS. as for access from a central entity, such as an NMS.
o Added a section on how to connect an NMS system. o Added a section on how to connect an NMS system.
o Clarified the hop-by-hop crypto nature of the ACP. o Clarified the hop-by-hop crypto nature of the ACP.
o Added several references to GDNP as a candidate protocol. o Added several references to GDNP as a candidate protocol.
o Added a discussion on network split and merge. Although, this o Added a discussion on network split and merge. Although, this
should probably go into the certificate management story longer should probably go into the certificate management story longer
term. term.
14.4. draft-behringer-anima-autonomic-control-plane-02 15.4. draft-behringer-anima-autonomic-control-plane-02
Addresses (numerous) comments from Brian Carpenter. See mailing list Addresses (numerous) comments from Brian Carpenter. See mailing list
for details. The most important changes are: for details. The most important changes are:
o Introduced a new section "overview", to ease the understanding of o Introduced a new section "overview", to ease the understanding of
the approach. the approach.
o Merged the previous "problem statement" and "use case" sections o Merged the previous "problem statement" and "use case" sections
into a mostly re-written "use cases" section, since they were into a mostly re-written "use cases" section, since they were
overlapping. overlapping.
o Clarified the relationship with draft-ietf-anima-stable- o Clarified the relationship with draft-ietf-anima-stable-
connectivity connectivity
14.5. draft-behringer-anima-autonomic-control-plane-03 15.5. draft-behringer-anima-autonomic-control-plane-03
o Took out requirement for IPv6 --> that's in the reference doc. o Took out requirement for IPv6 --> that's in the reference doc.
o Added requirement section. o Added requirement section.
o Changed focus: more focus on autonomic functions, not only virtual o Changed focus: more focus on autonomic functions, not only virtual
out-of-band. This goes a bit throughout the document, starting out-of-band. This goes a bit throughout the document, starting
with a changed abstract and intro. with a changed abstract and intro.
14.6. draft-ietf-anima-autonomic-control-plane-00 15.6. draft-ietf-anima-autonomic-control-plane-00
No changes; re-submitted as WG document. No changes; re-submitted as WG document.
14.7. draft-ietf-anima-autonomic-control-plane-01 15.7. draft-ietf-anima-autonomic-control-plane-01
o Added some paragraphs in addressing section on "why IPv6 only", to o Added some paragraphs in addressing section on "why IPv6 only", to
reflect the discussion on the list. reflect the discussion on the list.
o Moved the Data-Plane ACP out of the main document, into an o Moved the Data-Plane ACP out of the main document, into an
appendix. The focus is now the virtually separated ACP, since it appendix. The focus is now the virtually separated ACP, since it
has significant advantages, and isn't much harder to do. has significant advantages, and isn't much harder to do.
o Changed the self-creation algorithm: Part of the initial steps go o Changed the self-creation algorithm: Part of the initial steps go
into the reference document. This document now assumes an into the reference document. This document now assumes an
skipping to change at page 106, line 5 skipping to change at page 107, line 42
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
transport mode as the default tunnel type. transport mode as the default tunnel type.
o Updated links, lots of small edits. o Updated links, lots of small edits.
14.8. draft-ietf-anima-autonomic-control-plane-02 15.8. draft-ietf-anima-autonomic-control-plane-02
o Added explicitly text for the ACP channel negotiation. o Added explicitly text for the ACP channel negotiation.
o Merged draft-behringer-anima-autonomic-addressing-02 into this o Merged draft-behringer-anima-autonomic-addressing-02 into this
document, as suggested by WG chairs. document, as suggested by WG chairs.
14.9. draft-ietf-anima-autonomic-control-plane-03 15.9. draft-ietf-anima-autonomic-control-plane-03
o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap
protocol team decided to go with mDNS to discover bootstrap proxy, protocol team decided to go with mDNS to discover bootstrap proxy,
and ACP should be consistent with this. Reasons to go with mDNS and ACP should be consistent with this. Reasons to go with mDNS
in bootstrap were a) Bootstrap should be reuseable also outside of in bootstrap were a) Bootstrap should be reuseable also outside of
full anima solutions and introduce as few as possible new full anima solutions and introduce as few as possible new
elements. mDNS was considered well-known and very-likely even pre- elements. mDNS was considered well-known and very-likely even pre-
existing in low-end devices (IoT). b) Using GRASP both for the existing in low-end devices (IoT). b) Using GRASP both for the
insecure neighbor discovery and secure ACP operatations raises the insecure neighbor discovery and secure ACP operatations raises the
risk of introducing security issues through implementation issues/ risk of introducing security issues through implementation issues/
skipping to change at page 106, line 44 skipping to change at page 108, line 37
planned, and the paragraph in the main text referring to it. planned, and the paragraph in the main text referring to it.
o Deleted one sub-addressing scheme, focusing on a single scheme o Deleted one sub-addressing scheme, focusing on a single scheme
now. now.
o Included information on how ANIMA information must be encoded in o Included information on how ANIMA information must be encoded in
the domain certificate in section "preconditions". the domain certificate in section "preconditions".
o Editorial changes, updated draft references, etc. o Editorial changes, updated draft references, etc.
14.10. draft-ietf-anima-autonomic-control-plane-04 15.10. draft-ietf-anima-autonomic-control-plane-04
Changed discovery of ACP neighbor back from mDNS to GRASP after Changed discovery of ACP neighbor back from mDNS to GRASP after
revisiting the L2 problem. Described problem in discovery section revisiting the L2 problem. Described problem in discovery section
itself to justify. Added text to explain how ACP discovery relates itself to justify. Added text to explain how ACP discovery relates
to BRSKY (bootstrap) discovery and pointed to Michael Richardsons to BRSKY (bootstrap) discovery and pointed to Michael Richardsons
draft detailing it. Removed appendix section that contained the draft detailing it. Removed appendix section that contained the
original explanations why GRASP would be useful (current text is original explanations why GRASP would be useful (current text is
meant to be better). meant to be better).
14.11. draft-ietf-anima-autonomic-control-plane-05 15.11. draft-ietf-anima-autonomic-control-plane-05
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)
skipping to change at page 107, line 38 skipping to change at page 109, line 33
cloud could be automated. cloud could be automated.
o Added a CRL check in Section 6.7. o Added a CRL check in Section 6.7.
o Added a note on the possibility of source-address spoofing into o Added a note on the possibility of source-address spoofing into
the security considerations section. the security considerations section.
o Other editoral changes, including those proposed by Michael o Other editoral changes, including those proposed by Michael
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 15.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 detailled 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 15.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.
o Moved ACP channel negotiation from normative section to appendix o Moved ACP channel negotiation from normative section to appendix
because it can in the timeline of this document not be fully because it can in the timeline of this document not be fully
specified to be implementable. Aka: work for future document. specified to be implementable. Aka: work for future document.
skipping to change at page 109, line 37 skipping to change at page 111, line 29
do not specify which one is to be used but that the ACP should be do not specify which one is to be used but that the ACP should be
used to reach the URL included in the certificate to get to the used to reach the URL included in the certificate to get to the
CRL storage or OCSP server. CRL storage or OCSP server.
o Changed ACP via IPsec to ACP via IKEv2 and restructured the o Changed ACP via IPsec to ACP via IKEv2 and restructured the
sections to make IPsec native and IPsec via GRE subsections. sections to make IPsec native and IPsec via GRE subsections.
o No need for any assigned DTLS port if ACP is run across DTLS o No need for any assigned DTLS port if ACP is run across DTLS
because it is signaled via GRASP. because it is signaled via GRASP.
14.14. draft-ietf-anima-autonomic-control-plane-08 15.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 decribe two options: one
skipping to change at page 111, line 12 skipping to change at page 113, line 5
domain" is. Scheme is called "routing subdomain" to have a unique domain" is. Scheme is called "routing subdomain" to have a unique
name. name.
Added V8 (now called Vlong) addressing sub-scheme according to Added V8 (now called Vlong) addressing sub-scheme according to
suggestion from mcr in his mail from 30 Nov 2016 suggestion from mcr in his mail from 30 Nov 2016
(https://mailarchive.ietf.org/arch/msg/anima/ (https://mailarchive.ietf.org/arch/msg/anima/
nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the
single V bit in the first sub-scheme now renamed to Zone sub-scheme single V bit in the first sub-scheme now renamed to Zone sub-scheme
to distinguish it. to distinguish it.
14.15. draft-ietf-anima-autonomic-control-plane-09 15.15. draft-ietf-anima-autonomic-control-plane-09
Added reference to RFC4191 and explained how it should be used on ACP Added reference to RFC4191 and explained how it should be used on ACP
edge routers to allow auto configuration of routing by NMS hosts. edge routers to allow auto configuration of routing by NMS hosts.
This came after review of stable connectivity draft where ACP connect This came after review of stable connectivity draft where ACP connect
is being referred to. is being referred to.
V8 addressing Sub-Scheme was modified to allow not only /8 device- V8 addressing Sub-Scheme was modified to allow not only /8 device-
local address space but also /16. This was in response to the local address space but also /16. This was in response to the
possible need to have maybe as much as 2^12 local addresses for possible need to have maybe as much as 2^12 local addresses for
future encaps in BRSKI like IPinIP. It also would allow fully future encaps in BRSKI like IPinIP. It also would allow fully
skipping to change at page 113, line 11 skipping to change at page 115, line 5
revocation. revocation.
Added fixes from 08-mcr-review-reply.txt (on github): Added fixes from 08-mcr-review-reply.txt (on github):
o AN Domain Names are FQDNs. o AN Domain Names are FQDNs.
o Fixed bit length of schemes, numerical writing of bits (00b/01b). o Fixed bit length of schemes, numerical writing of bits (00b/01b).
o Lets use US american english. o Lets use US american english.
14.16. draft-ietf-anima-autonomic-control-plane-10 15.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), explaned 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
skipping to change at page 115, line 5 skipping to change at page 116, line 44
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).
12. Added explanations and cross-references to various security 12. Added explanations and cross-references to various security
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 15.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 datatra cker 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 crea ted so that one can compare
changes from -09 and changes to the next version (-12). changes from -09 and changes to the next version (-12).
14.18. draft-ietf-anima-autonomic-control-plane-12 15.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 detailling 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.
skipping to change at page 116, line 41 skipping to change at page 118, line 33
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 never 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 15.19. draft-ietf-anima-autonomic-control-plane-13
Swap author list (with permission). Swap author list (with permission).
6.1.1. Eliminate blank lines in definition by making it a picture 6.1.1. Eliminate blank lines in definition by making it a picture
(reformatting only). (reformatting only).
6.10.3.1 New paragraph: Explained how nodes using Zone-ID != 0 need 6.10.3.1 New paragraph: Explained how nodes using Zone-ID != 0 need
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.
skipping to change at page 118, line 36 skipping to change at page 120, line 29
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 15.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 beavior 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::
skipping to change at page 119, line 36 skipping to change at page 121, line 28
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:
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 exiry/failure in a way that allows to maintain as much
as possible ACP address information. as possible ACP address information.
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.
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 ueful (sub-CA and/
or centralized policy manaement). or centralized policy manaement).
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
some small text fixups/remove of duplicate text. some small text fixups/remove of duplicate text.
skipping to change at page 122, line 35 skipping to change at page 124, line 28
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.
14.21. wish-list 15.21. draft-ietf-anima-autonomic-control-plane-15
Only reshuffling and formatting changes, but wanted to allow
reviewers later to easily compare -13 with -14, and these changes in
-15 mess that up too much.
increased TOC depth to 4.
Separated and reordered section 10 into an operational and a
background and futures section. The background and futures could
also become appendices if the layout of appendices in RFC format
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
from proceeding any further).
15.22. wish-list
From -13 review from Pascal Thubert: Picture to show dual-NOC routing From -13 review from Pascal Thubert: Picture to show dual-NOC routing
limitation. limitation.
[RFC Editor: Question: Is it possible to change the first occurences [RFC Editor: Question: Is it possible to change the first occurences
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 to be duplicate - one reference for
title mentioning and one for RFC number.] title mentioning and one for RFC number.]
15. References 16. References
15.1. Normative References 16.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]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR data structures", draft-ietf-cbor-cddl-02 express CBOR data structures", draft-ietf-cbor-cddl-02
skipping to change at page 125, line 19 skipping to change at page 127, line 24
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676, for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015, DOI 10.17487/RFC7676, October 2015,
<https://www.rfc-editor.org/info/rfc7676>. <https://www.rfc-editor.org/info/rfc7676>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
15.2. Informative References 16.2. Informative References
[AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and [AR8021] IEEE SA-Standards Board, "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>.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
 End of changes. 96 change blocks. 
302 lines changed or deleted 385 lines changed or added

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