< draft-ietf-anima-autonomic-control-plane-27.txt   draft-ietf-anima-autonomic-control-plane-28.txt >
ANIMA WG T. Eckert, Ed. ANIMA WG T. Eckert, Ed.
Internet-Draft Futurewei USA Internet-Draft Futurewei USA
Intended status: Standards Track M. Behringer, Ed. Intended status: Standards Track M. Behringer, Ed.
Expires: January 3, 2021 Expires: January 29, 2021
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
July 2, 2020 July 28, 2020
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-27 draft-ietf-anima-autonomic-control-plane-28
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 Control Plane depends on some addressing and routing. This Autonomic Control Plane
should ideally be self-managing, and as independent as possible of should ideally be self-managing, and as independent as possible of
configuration. This document defines such a plane and calls it the configuration. This document defines such a plane and calls it the
"Autonomic Control Plane", with the primary use as a control plane "Autonomic Control Plane", with the primary use as a control plane
for autonomic functions. It also serves as a "virtual out-of-band for autonomic functions. It also serves as a "virtual out-of-band
channel" for Operations, Administration and Management (OAM) channel" for Operations, Administration and Management (OAM)
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2021. This Internet-Draft will expire on January 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 (Informative) . . . . . . . . . . . . . . . . . 5 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 6
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 9 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 9
2. Acronyms and Terminology (Informative) . . . . . . . . . . . 10 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 10
3. Use Cases for an Autonomic Control Plane (Informative) . . . 17 3. Use Cases for an Autonomic Control Plane (Informative) . . . 17
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 17 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 17
3.2. Secure Bootstrap over a not configured Network . . . . . 17 3.2. Secure Bootstrap over a not configured Network . . . . . 17
3.3. Data-Plane Independent Permanent Reachability . . . . . . 18 3.3. Data-Plane Independent Permanent Reachability . . . . . . 18
4. Requirements (Informative) . . . . . . . . . . . . . . . . . 19 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 19
5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 20 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 20
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 22 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 22
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 22 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 23
6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 24 6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 24
6.1.2. ACP Certificate AcpNodeName . . . . . . . . . . . . . 26 6.1.2. ACP Certificate AcpNodeName . . . . . . . . . . . . . 26
6.1.2.1. AcpNodeName ASN.1 Module . . . . . . . . . . . . 29 6.1.2.1. AcpNodeName ASN.1 Module . . . . . . . . . . . . 29
6.1.3. ACP domain membership check . . . . . . . . . . . . . 30 6.1.3. ACP domain membership check . . . . . . . . . . . . . 30
6.1.3.1. Realtime clock and Time Validation . . . . . . . 32 6.1.3.1. Realtime clock and Time Validation . . . . . . . 32
6.1.4. Trust Anchors (TA) . . . . . . . . . . . . . . . . . 32 6.1.4. Trust Anchors (TA) . . . . . . . . . . . . . . . . . 33
6.1.5. Certificate and Trust Anchor Maintenance . . . . . . 33 6.1.5. Certificate and Trust Anchor Maintenance . . . . . . 34
6.1.5.1. GRASP objective for EST server . . . . . . . . . 34 6.1.5.1. GRASP objective for EST server . . . . . . . . . 35
6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 35 6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 36
6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 36 6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 37
6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 36 6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 37
6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 37 6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 38
6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 38 6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 39
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 39 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 40
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 39 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 40
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 43 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 44
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 43 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 44
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 47 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 48
6.7. Security Association (Secure Channel) protocols . . . . . 47 6.7. Security Association (Secure Channel) protocols . . . . . 48
6.7.1. General considerations . . . . . . . . . . . . . . . 48 6.7.1. General considerations . . . . . . . . . . . . . . . 49
6.7.2. Common requirements . . . . . . . . . . . . . . . . . 48 6.7.2. Common requirements . . . . . . . . . . . . . . . . . 49
6.7.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 50 6.7.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 51
6.7.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 50 6.7.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 51
6.7.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 50 6.7.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 51
6.7.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 52 6.7.3.1.2. RFC8247 (IKEv2) . . . . . . . . . . . . . . . 53
6.7.3.2. IPsec with GRE encapsulation . . . . . . . . . . 53 6.7.3.2. IPsec with GRE encapsulation . . . . . . . . . . 54
6.7.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 54 6.7.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 55
6.7.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 55 6.7.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 56
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 56 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 57
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 56 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 57
6.8.2. ACP as the Security and Transport substrate for GRASP 57 6.8.2. ACP as the Security and Transport substrate for GRASP 58
6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 60 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 61
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 61 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 62
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 61 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 62
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 61 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 62
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 63 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 64
6.10.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 64 6.10.3. ACP Zone Addressing Sub-Scheme (ACP-Zone) . . . . . 65
6.10.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 66 6.10.4. ACP Manual Addressing Sub-Scheme (ACP-Manual) . . . 67
6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP- 6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-
VLong-16 . . . . . . . . . . . . . . . . . . . . . . 67 VLong-16 . . . . . . . . . . . . . . . . . . . . . . 68
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 68 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 69
6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 69 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 70
6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 69 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 70
6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 70 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 71
6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 71 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 72
6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 72 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 73
6.10.7.5. Further Details . . . . . . . . . . . . . . . . 72 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 73
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 72 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 73
6.11.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 73 6.11.1. ACP RPL Profile . . . . . . . . . . . . . . . . . . 74
6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 73 6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 74
6.11.1.1.1. Single Instance . . . . . . . . . . . . . . 73 6.11.1.1.1. Single Instance . . . . . . . . . . . . . . 74
6.11.1.1.2. Reconvergence . . . . . . . . . . . . . . . 74 6.11.1.1.2. Reconvergence . . . . . . . . . . . . . . . 75
6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 74 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 76
6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 74 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 76
6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 75 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 76
6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 75 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 76
6.11.1.6. Objective Function . . . . . . . . . . . . . . . 75 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 76
6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 75 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 76
6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 76 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 77
6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 76 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 77
6.11.1.10. P2P communications . . . . . . . . . . . . . . . 76 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 77
6.11.1.11. IPv6 address configuration . . . . . . . . . . . 76 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 77
6.11.1.12. Administrative parameters . . . . . . . . . . . 76 6.11.1.12. Administrative parameters . . . . . . . . . . . 78
6.11.1.13. RPL Packet Information . . . . . . . . . . . . . 76 6.11.1.13. RPL Packet Information . . . . . . . . . . . . . 78
6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 77 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 78
6.12. General ACP Considerations . . . . . . . . . . . . . . . 77 6.12. General ACP Considerations . . . . . . . . . . . . . . . 79
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 77 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 79
6.12.2. Addressing of Secure Channels . . . . . . . . . . . 78 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 79
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 78 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 80
6.12.4. Multiple links between nodes . . . . . . . . . . . . 79 6.12.4. Multiple links between nodes . . . . . . . . . . . . 80
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 79 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 80
6.12.5.1. ACP loopback interfaces . . . . . . . . . . . . 79 6.12.5.1. ACP loopback interfaces . . . . . . . . . . . . 80
6.12.5.2. ACP virtual interfaces . . . . . . . . . . . . . 81 6.12.5.2. ACP virtual interfaces . . . . . . . . . . . . . 83
6.12.5.2.1. ACP point-to-point virtual interfaces . . . 81 6.12.5.2.1. ACP point-to-point virtual interfaces . . . 83
6.12.5.2.2. ACP multi-access virtual interfaces . . . . 82 6.12.5.2.2. ACP multi-access virtual interfaces . . . . 83
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 84 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 85
7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 84 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 86
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 85 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 87
8. Support for Non-ACP Components (Normative) . . . . . . . . . 87 8. Support for Non-ACP Components (Normative) . . . . . . . . . 88
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 87 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 88
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 87 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 88
8.1.2. Software Components . . . . . . . . . . . . . . . . . 89 8.1.2. Software Components . . . . . . . . . . . . . . . . . 91
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 90 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 92
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 91 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 93
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 93 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 94
8.2. Connecting ACP islands over Non-ACP L3 networks (Remote 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote
ACP neighbors) . . . . . . . . . . . . . . . . . . . . . 93 ACP neighbors) . . . . . . . . . . . . . . . . . . . . . 95
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 94 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 95
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 95 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 96
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 95 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 97
9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 95 9. ACP Operations (Informative) . . . . . . . . . . . . . . . . 97
9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 96 9.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . . 98
9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 100 9.1.1. Secure Channel Peer diagnostics . . . . . . . . . . . 102
9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 101 9.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 103
9.2.1. Registrar interactions . . . . . . . . . . . . . . . 102 9.2.1. Registrar interactions . . . . . . . . . . . . . . . 103
9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 103 9.2.2. Registrar Parameter . . . . . . . . . . . . . . . . . 104
9.2.3. Certificate renewal and limitations . . . . . . . . . 103 9.2.3. Certificate renewal and limitations . . . . . . . . . 105
9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 104 9.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 106
9.2.5. Centralized Policy Control . . . . . . . . . . . . . 105 9.2.5. Centralized Policy Control . . . . . . . . . . . . . 106
9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 105 9.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 107
9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 106 9.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . . 107
9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 106 9.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 108
9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 107 9.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 109
9.3.2.2. Fast state propagation and Diagnostics . . . . . 107 9.3.2.2. Fast state propagation and Diagnostics . . . . . 109
9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 108 9.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 110
9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 109 9.3.2.4. Power Consumption Issues . . . . . . . . . . . . 111
9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 109 9.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 111
9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 109 9.3.4. Which interfaces to auto-enable? . . . . . . . . . . 111
9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 111 9.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . . 113
9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 111 9.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 113
9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 112 9.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 114
9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 112 9.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 114
9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 113 9.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 115
9.4. Partial or Incremental adoption . . . . . . . . . . . . . 113 9.4. Partial or Incremental adoption . . . . . . . . . . . . . 115
9.5. Configuration and the ACP (summary) . . . . . . . . . . . 114 9.5. Configuration and the ACP (summary) . . . . . . . . . . . 116
10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 115 10. Summary: Benefits (Informative) . . . . . . . . . . . . . . . 117
10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 116 10.1. Self-Healing Properties . . . . . . . . . . . . . . . . 118
10.2. Self-Protection Properties . . . . . . . . . . . . . . . 117 10.2. Self-Protection Properties . . . . . . . . . . . . . . . 119
10.2.1. From the outside . . . . . . . . . . . . . . . . . . 117 10.2.1. From the outside . . . . . . . . . . . . . . . . . . 119
10.2.2. From the inside . . . . . . . . . . . . . . . . . . 118 10.2.2. From the inside . . . . . . . . . . . . . . . . . . 120
10.3. The Administrator View . . . . . . . . . . . . . . . . . 119 10.3. The Administrator View . . . . . . . . . . . . . . . . . 121
11. Security Considerations . . . . . . . . . . . . . . . . . . . 119 11. Security Considerations . . . . . . . . . . . . . . . . . . . 122
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 123 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 125
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 124 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 126
14.1. Summary of changes since entering IESG review . . . . . 124 14.1. Summary of changes since entering IESG review . . . . . 126
14.1.1. Reviews (while in IESG review status) / status . . . 124 14.1.1. Reviews (while in IESG review status) / status . . . 126
14.1.2. BRSKI / ACP registrar related enhancements . . . . . 124 14.1.2. BRSKI / ACP registrar related enhancements . . . . . 127
14.1.3. Normative enhancements since start of IESG review . 125 14.1.3. Normative enhancements since start of IESG review . 127
14.1.4. Explanatory enhancements since start of IESG review 126 14.1.4. Explanatory enhancements since start of IESG review 128
14.2. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 127 14.2. draft-ietf-anima-autonomic-control-plane-28 . . . . . . 129
14.3. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 127 14.3. draft-ietf-anima-autonomic-control-plane-27 . . . . . . 130
14.4. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 128 14.4. draft-ietf-anima-autonomic-control-plane-26 . . . . . . 130
14.5. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 131 14.5. draft-ietf-anima-autonomic-control-plane-25 . . . . . . 131
14.6. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 131 14.6. draft-ietf-anima-autonomic-control-plane-24 . . . . . . 135
14.7. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 133 14.7. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 135
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 14.8. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 136
15.1. Normative References . . . . . . . . . . . . . . . . . . 135 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 138
15.2. Informative References . . . . . . . . . . . . . . . . . 138 15.1. Normative References . . . . . . . . . . . . . . . . . . 138
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 146 15.2. Informative References . . . . . . . . . . . . . . . . . 142
Appendix A. Background and Futures (Informative) . . . . . . . . 146 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 149
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 146 Appendix A. Background and Futures (Informative) . . . . . . . . 150
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 147 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 150
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 148 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 150
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 148 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 152
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 148 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 152
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 149 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 152
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 149 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 152
A.5. ACP Information Distribution and multicast . . . . . . . 151 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 153
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 152 A.5. ACP Information Distribution and multicast . . . . . . . 154
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 153 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 155
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 155 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 157
A.9. Adopting ACP concepts for other environments . . . . . . 156 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 158
A.10. Further (future) options . . . . . . . . . . . . . . . . 157 A.9. Adopting ACP concepts for other environments . . . . . . 159
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 157 A.10. Further (future) options . . . . . . . . . . . . . . . . 161
A.10.2. More options for avoiding IPv6 Data-Plane dependency 158 A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 161
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 158 A.10.2. More options for avoiding IPv6 Data-Plane dependency 161
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 159 A.10.3. ACP APIs and operational models (YANG) . . . . . . . 162
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 159 A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 162
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 160 A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 163
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 160 A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 163
A.10.8. Avoiding and dealing with compromised ACP nodes . . 161 A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 164
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162 A.10.8. Avoiding and dealing with compromised ACP nodes . . 164
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 165
1. Introduction (Informative) 1. Introduction (Informative)
Autonomic Networking is a concept of self-management: Autonomic Autonomic Networking is a concept of self-management: Autonomic
functions self-configure, and negotiate parameters and settings functions self-configure, and negotiate parameters and settings
across the network. [RFC7575] defines the fundamental ideas and across the network. [RFC7575] defines the fundamental ideas and
design goals of Autonomic Networking. A gap analysis of Autonomic design goals of Autonomic Networking. A gap analysis of Autonomic
Networking is given in [RFC7576]. The reference architecture for Networking is given in [RFC7576]. The reference architecture for
Autonomic Networking in the IETF is specified in the document Autonomic Networking in the IETF is specified in the document
[I-D.ietf-anima-reference-model]. [I-D.ietf-anima-reference-model].
skipping to change at page 6, line 27 skipping to change at page 6, line 33
Today, the OAM and control plane of IP networks is what is typically Today, the OAM and control plane of IP networks is what is typically
called in-band management/signaling: Its management and control called in-band management/signaling: Its management and control
protocol traffic depends on the routing and forwarding tables, protocol traffic depends on the routing and forwarding tables,
security, policy, QoS and potentially other configuration that first security, policy, QoS and potentially other configuration that first
has to be established through the very same management and control has to be established through the very same management and control
protocols. Misconfigurations including unexpected side effects or protocols. Misconfigurations including unexpected side effects or
mutual dependences can disrupt OAM and control operations and mutual dependences can disrupt OAM and control operations and
especially disrupt remote management access to the affected node especially disrupt remote management access to the affected node
itself and potentially a much larger number of nodes for whom the itself and potentially a much larger number of nodes for whom the
affected node is on the network parth. Traditionally, physically affected node is on the network path. Traditionally, physically
separate, so-called out-of-band (management) networks have been used separate, so-called out-of-band (management) networks have been used
to avoid these problems or at least to allow recovery from such to avoid these problems or at least to allow recovery from such
problems. Worst case, personnel are sent on site to access devices problems. Worst case, personnel are sent on site to access devices
through out-of-band management ports (also called craft ports, serial through out-of-band management ports (also called craft ports, serial
console, management ethernet port). However, both options are console, management ethernet port). However, both options are
expensive. expensive.
In increasingly automated networks either centralized management In increasingly automated networks either centralized management
systems or distributed autonomic service agents in the network systems or distributed autonomic service agents in the network
require a control plane which is independent of the configuration of require a control plane which is independent of the configuration of
skipping to change at page 7, line 15 skipping to change at page 7, line 19
In a fully autonomic network node without legacy control or In a fully autonomic network node without legacy control or
management functions/protocols, the Data-Plane would be for example management functions/protocols, the Data-Plane would be for example
just a forwarding plane for "Data" IPv6 packets, aka: packets that just a forwarding plane for "Data" IPv6 packets, aka: packets that
are not forwarded by the ACP itself such as control or management are not forwarded by the ACP itself such as control or management
plane packets. In such networks/nodes, there would be no non- plane packets. In such networks/nodes, there would be no non-
autonomous control or non-autonomous management plane. autonomous control or non-autonomous management plane.
Routing protocols for example would be built inside the ACP as so- Routing protocols for example would be built inside the ACP as so-
called autonomous functions via autonomous service agents, leveraging called autonomous functions via autonomous service agents, leveraging
the ACPs functions instead of implementing them seperately for each the ACPs functions instead of implementing them seperately for each
protocol: discovery, automaticically established authenticated and protocol: discovery, automatically established authenticated and
encrypted local and distant peer connectivity for control and encrypted local and distant peer connectivity for control and
managemenet traffic and common control/management protocol session management traffic and common control/management protocol session and
and presentation functions. presentation functions.
When ACP functionality is added to nodes that have non-autonomous When ACP functionality is added to nodes that have non-autonomous
management plane and/or control plane functions (henceforth called management plane and/or control plane functions (henceforth called
non-autonomous nodes), the ACP instead is best abstracted as a non-autonomous nodes), the ACP instead is best abstracted as a
special Virtual Routing and Forwarding (VRF) instance (or virtual special Virtual Routing and Forwarding (VRF) instance (or virtual
router) and the complete pre-existing non-autonomous management and/ router) and the complete pre-existing non-autonomous management and/
or control plane is considered to be part of the Data-Plane to avoid or control plane is considered to be part of the Data-Plane to avoid
introduction of more complex, new terminology only for this case. introduction of more complex, new terminology only for this case.
Like the forwarding plane for "Data" packets, the non-autonomous Like the forwarding plane for "Data" packets, the non-autonomous
control and management plane functions can then be managed/used via control and management plane functions can then be managed/used via
the ACP. This terminology is consistent with pre-existing documents the ACP. This terminology is consistent with pre-existing documents
such as [RFC8368]. such as [RFC8368].
In both instances (autonomous and non-autonomous nodes), the ACP is In both instances (autonomous and non-autonomous nodes), the ACP is
built such that it is operating in the absene of the Data-Plane, and built such that it is operating in the absence of the Data-Plane, and
in the case of existing non-autonomous (management, control) in the case of existing non-autonomous (management, control)
components in the Data-Plane also in the presence of any components in the Data-Plane also in the presence of any
(mis-)configuration thereof. (mis-)configuration thereof.
The Autonomic Control Plane serves several purposes at the same time: The Autonomic Control Plane serves several purposes at the same time:
1. Autonomic functions communicate over the ACP. The ACP therefore 1. Autonomic functions communicate over the ACP. The ACP therefore
directly supports Autonomic Networking functions, as described in directly supports Autonomic Networking functions, as described in
[I-D.ietf-anima-reference-model]. For example, Generic Autonomic [I-D.ietf-anima-reference-model]. For example, Generic Autonomic
Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely
skipping to change at page 8, line 17 skipping to change at page 8, line 22
3. An operator can use it to access remote devices using protocols 3. An operator can use it to access remote devices using protocols
such as Secure SHell (SSH) or Network Configuration Protocol such as Secure SHell (SSH) or Network Configuration Protocol
(NETCONF) running across the ACP, even if the network is (NETCONF) running across the ACP, even if the network is
misconfigured or not configured. misconfigured or not configured.
This document describes these purposes as use cases for the ACP in This document describes these purposes as use cases for the ACP in
Section 3, it defines the requirements in Section 4. Section 5 gives Section 3, it defines the requirements in Section 4. Section 5 gives
an overview how the ACP is constructed. an overview how the ACP is constructed.
The normative part of this document starts with Section 6, where the The normative part of this document starts with Section 6, where the
ACP is specified. Section 7 defines normative how to support ACP on ACP is specified. Section 7 explains how to support ACP on L2
L2 switches. Section 8 explains normative how non-ACP nodes and switches (normative). Section 8 explains how non-ACP nodes and
networks can be integrated. networks can be integrated (normative).
The remaining sections are non-normative: Section 10 reviews benefits The remaining sections are non-normative: Section 10 reviews benefits
of the ACP (after all the details have been defined), Section 9 of the ACP (after all the details have been defined), Section 9
provides operational recommendations, Appendix A provides additional provides operational recommendations, Appendix A provides additional
explanations and describes additional details or future standard or explanations and describes additional details or future standard or
propriety extensions that were considered not to be appropriate for propriety extensions that were considered not to be appropriate for
standardization in this document but were considered important to standardization in this document but were considered important to
document. There are no dependencies against Appendix A to build a document. There are no dependencies against Appendix A to build a
complete working and interoperable ACP according to this document. complete working and interoperable ACP according to this document.
skipping to change at page 10, line 9 skipping to change at page 10, line 12
operations (IPv6/IPv4). Nevertheless, it can without any changes be operations (IPv6/IPv4). Nevertheless, it can without any changes be
integrated into even otherwise IPv4-only network devices. The Data- integrated into even otherwise IPv4-only network devices. The Data-
Plane itself would not need to change, it could continue to be IPv4 Plane itself would not need to change, it could continue to be IPv4
only. For such IPv4 only devices, the IPv6 protocol itself would be only. For such IPv4 only devices, the IPv6 protocol itself would be
additional implementation footprint only used for the ACP. additional implementation footprint only used for the ACP.
The protocol choices of the ACP are primarily based on wide use and The protocol choices of the ACP are primarily based on wide use and
support in networks and devices, well understood security properties support in networks and devices, well understood security properties
and required scalability. The ACP design is an attempt to produce and required scalability. The ACP design is an attempt to produce
the lowest risk combination of existing technologies and protocols to the lowest risk combination of existing technologies and protocols to
build a widely applicable operational network management solution: build a widely applicable operational network management solution.
RPL was chosen because it requires a smaller routing table footprint RPL was chosen because it requires a smaller routing table footprint
in large networks compared to other routing protocols with an in large networks compared to other routing protocols with an
autonomically configured single area. The deployment experience of autonomically configured single area. The deployment experience of
large scale Internet of Things (IoT) networks serves as the basis for large scale Internet of Things (IoT) networks serves as the basis for
wide deployment experience with RPL. The profile chosen for RPL in wide deployment experience with RPL. The profile chosen for RPL in
the ACP does not leverage any RPL specific forwarding plane features the ACP does not leverage any RPL specific forwarding plane features
(IPv6 extension headers), making its implementation a pure control (IPv6 extension headers), making its implementation a pure control
plane software requirement. plane software requirement.
skipping to change at page 10, line 48 skipping to change at page 10, line 51
2. Acronyms and Terminology (Informative) 2. Acronyms and Terminology (Informative)
[RFC Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc- [RFC Editor: Please add ACP, BRSKI, GRASP, MASA to https://www.rfc-
editor.org/materials/abbrev.expansion.txt.] editor.org/materials/abbrev.expansion.txt.]
[RFC Editor: WG/IETF/IESG review of the terms below asked for [RFC Editor: WG/IETF/IESG review of the terms below asked for
references between these terms when they refer to each other. The references between these terms when they refer to each other. The
only option I could find for RFC/XML to point to a hanging text only option I could find for RFC/XML to point to a hanging text
acronym definition that also displays the actual term is the acronym definition that also displays the actual term is the
format="title" version, which leads to references such as '->"ACP format="title" version, which leads to references such as '->"ACP
domain certificate" ()'. I found no reasonable way to eliminate the certificate" ()'. I found no reasonable way to eliminate the
trailing '()' generated by this type of cross references. Can you trailing '()' generated by this type of cross references. Can you
please take care of removing these artefacts during editing (after please take care of removing these artefacts during editing (after
conversion to nroff ?). I also created a ticket to ask for an conversion to nroff ?). I also created a ticket to ask for an
xml2rfc enhancement to avoid this in the future: xml2rfc enhancement to avoid this in the future:
https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.] https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.]
[RFC Editor: Question: Is it possible to change the first occurrences [RFC Editor: Question: Is it possible to change the first occurrences
of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC
format does not seem to offer such a format, but I did not want to format does not seem to offer such a format, but I did not want to
duplicate 50 first references - one reference for title mentioning duplicate 50 first references - one reference for title mentioning
skipping to change at page 11, line 40 skipping to change at page 11, line 43
ACP: "Autonomic Control Plane". The Autonomic Function as defined ACP: "Autonomic Control Plane". The Autonomic Function as defined
in this document. It provides secure zero-touch (automated) in this document. It provides secure zero-touch (automated)
transitive (network wide) IPv6 connectivity for all nodes in the transitive (network wide) IPv6 connectivity for all nodes in the
same ACP domain as well as a GRASP instance running across this same ACP domain as well as a GRASP instance running across this
ACP IPv6 connectivity. The ACP is primarily meant to be used as a ACP IPv6 connectivity. The ACP is primarily meant to be used as a
component of the ANI to enable Autonomic Networks but it can component of the ANI to enable Autonomic Networks but it can
equally be used in simple ANI networks (with no other Autonomic equally be used in simple ANI networks (with no other Autonomic
Functions) or completely by itself. Functions) or completely by itself.
ACP address: An IPv6 address assigned to the ACP node. It is stored ACP address: An IPv6 address assigned to the ACP node. It is stored
in the acp-node-name of the ->"ACP domain certificate" (). in the acp-node-name of the ->"ACP certificate" ().
ACP address range/set: The ACP address may imply a range or set of ACP address range/set: The ACP address may imply a range or set of
addresses that the node can assign for different purposes. This addresses that the node can assign for different purposes. This
address range/set is derived by the node from the format of the address range/set is derived by the node from the format of the
ACP address called the "addressing sub-scheme". ACP address called the "addressing sub-scheme".
ACP connect interface: An interface on an ACP node providing access ACP connect interface: An interface on an ACP node providing access
to the ACP for non ACP capable nodes without using an ACP secure to the ACP for non ACP capable nodes without using an ACP secure
channel. See Section 8.1.1. channel. See Section 8.1.1.
ACP domain: The ACP domain is the set of nodes with ->"ACP domain ACP domain: The ACP domain is the set of nodes with ->"ACP
certificates" that allow them to authenticate each other as certificates" that allow them to authenticate each other as
members of the ACP domain. See also Section 6.1.3. members of the ACP domain. See also Section 6.1.3.
ACP (ANI/AN) Domain Certificate: A [RFC5280] certificate (LDevID) ACP (ANI/AN) Domain Certificate: A [RFC5280] certificate (LDevID)
carrying the acp-node-name which is used by the ACP to learn its carrying the acp-node-name which is used by the ACP to learn its
address in the ACP and to derive and cryptographically assert its address in the ACP and to derive and cryptographically assert its
membership in the ACP domain. membership in the ACP domain.
ACP acp-node-name field: An information field in the ACP Domain ACP acp-node-name field: An information field in the ACP certificate
Certificate in which the ACP relevant information is encoded: the in which the ACP relevant information is encoded: the ACP domain
ACP domain name, the ACP IPv6 address of the node and optional name, the ACP IPv6 address of the node and optional additional
additional role attributes about the node. role attributes about the node.
ACP Loopback interface: The Loopback interface in the ACP Virtual ACP Loopback interface: The Loopback interface in the ACP Virtual
Routing and Forwarding (VRF) that has the ACP address assigned to Routing and Forwarding (VRF) that has the ACP address assigned to
it. See Section 6.12.5.1. it. See Section 6.12.5.1.
ACP network: The ACP network constitutes all the nodes that have ACP network: The ACP network constitutes all the nodes that have
access to the ACP. It is the set of active and transitively access to the ACP. It is the set of active and transitively
connected nodes of an ACP domain plus all nodes that get access to connected nodes of an ACP domain plus all nodes that get access to
the ACP of that domain via ACP edge nodes. the ACP of that domain via ACP edge nodes.
ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the
ACP. In the normal/simple case, the ACP has one ULA prefix, see ACP. In the normal/simple case, the ACP has one ULA prefix, see
Section 6.10. The ACP routing table may include multiple ULA Section 6.10. The ACP routing table may include multiple ULA
prefixes if the "rsub" option is used to create addresses from prefixes if the "rsub" option is used to create addresses from
more than one ULA prefix. See Section 6.1.2. The ACP may also more than one ULA prefix. See Section 6.1.2. The ACP may also
include non-ULA prefixes if those are configured on ACP connect include non-ULA prefixes if those are configured on ACP connect
interfaces. See Section 8.1.1. interfaces. See Section 8.1.1.
ACP secure channel: A channel authenticated via ->"ACP domain ACP secure channel: A channel authenticated via ->"ACP certificates"
certificates" () providing integrity protection and () providing integrity protection and confidentiality through
confidentiality through encryption. These are established between encryption. These are established between (normally) adjacent ACP
(normally) adjacent ACP nodes to carry traffic of the ACP VRF nodes to carry traffic of the ACP VRF securely and isolated from
securely and isolated from Data-Plane traffic in-band over the Data-Plane traffic in-band over the same link/path as the Data-
same link/path as the Data-Plane. Plane.
ACP secure channel protocol: The protocol used to build an ACP ACP secure channel protocol: The protocol used to build an ACP
secure channel, e.g., Internet Key Exchange Protocol version 2 secure channel, e.g., Internet Key Exchange Protocol version 2
(IKEv2) with IPsec or Datagram Transport Layer Security (DTLS). (IKEv2) with IPsec or Datagram Transport Layer Security (DTLS).
ACP virtual interface: An interface in the ACP VRF mapped to one or ACP virtual interface: An interface in the ACP VRF mapped to one or
more ACP secure channels. See Section 6.12.5. more ACP secure channels. See Section 6.12.5.
AN "Autonomic Network": A network according to AN "Autonomic Network": A network according to
[I-D.ietf-anima-reference-model]. Its main components are ANI, [I-D.ietf-anima-reference-model]. Its main components are ANI,
skipping to change at page 14, line 10 skipping to change at page 14, line 14
autonomically via Autonomic Functions and Intent. See Section 1 autonomically via Autonomic Functions and Intent. See Section 1
for more detailed explanations. for more detailed explanations.
device: A physical system, or physical node. device: A physical system, or physical node.
Enrollment: The process through which a node authenticates itself to Enrollment: The process through which a node authenticates itself to
a network with an initial identity, which is often called IDevID a network with an initial identity, which is often called IDevID
certificate, and acquires from the network a network specific certificate, and acquires from the network a network specific
identity, which is often called LDevID certificate, and identity, which is often called LDevID certificate, and
certificates of one or more Trust Anchor(s). In the ACP, the certificates of one or more Trust Anchor(s). In the ACP, the
LDevID certificate is called the ACP Domain Certificate. LDevID certificate is called the ACP certificate.
EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard- EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard-
track protocol for enrollment of a node with an LDevID track protocol for enrollment of a node with an LDevID
certificate. BRSKI is based on EST. certificate. BRSKI is based on EST.
GRASP: "Generic Autonomic Signaling Protocol". An extensible GRASP: "Generic Autonomic Signaling Protocol". An extensible
signaling protocol required by the ACP for ACP neighbor discovery. signaling protocol required by the ACP for ACP neighbor discovery.
The ACP also provides the "security and transport substrate" for The ACP also provides the "security and transport substrate" for
the "ACP instance of GRASP". This instance of GRASP runs across the "ACP instance of GRASP". This instance of GRASP runs across
skipping to change at page 15, line 50 skipping to change at page 16, line 7
dedicated management ports on the primary network equipment. dedicated management ports on the primary network equipment.
Serial (console) management ports were historically most common, Serial (console) management ports were historically most common,
higher end network equipment now also has ethernet ports dedicated higher end network equipment now also has ethernet ports dedicated
only for management. An out-of-band network provides management only for management. An out-of-band network provides management
access to the primary network independent of the configuration access to the primary network independent of the configuration
state of the primary network. See ->"introduction" state of the primary network. See ->"introduction"
(Introduction (Informative)) (Introduction (Informative))
(virtual) out-of-band network: The ACP can be called a virtual out- (virtual) out-of-band network: The ACP can be called a virtual out-
of-band network for management and control because it attempts to of-band network for management and control because it attempts to
provide the benefits of a (physical) ->"out-of-band netork" () provide the benefits of a (physical) ->"out-of-band network" ()
even though it is physcially carried ->"in-band" (). See even though it is physically carried ->"in-band" (). See
->"introduction" (Introduction (Informative)). ->"introduction" (Introduction (Informative)).
root CA: "root Certification Authority". A ->"CA" () for which the root CA: "root Certification Authority". A ->"CA" () for which the
root CA Key update procedures of [RFC7030], Section 4.4 can be root CA Key update procedures of [RFC7030], Section 4.4 can be
applied. applied.
RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The
routing protocol used in the ACP. See [RFC6550]. routing protocol used in the ACP. See [RFC6550].
(ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software
and/or person) that is orchestrating the enrollment of ACP nodes and/or person) that is orchestrating the enrollment of ACP nodes
with the ACP domain certificate. ANI nodes use BRSKI, so ANI with the ACP certificate. ANI nodes use BRSKI, so ANI registrars
registrars are also called BRSKI registrars. For non-ANI ACP are also called BRSKI registrars. For non-ANI ACP nodes, the
nodes, the registrar mechanisms are undefined by this document. registrar mechanisms are undefined by this document. See
See Section 6.10.7. Renewal and other maintenance (such as Section 6.10.7. Renewal and other maintenance (such as
revocation) of ACP domain certificates may be performed by other revocation) of ACP certificates may be performed by other entities
entities than registrars. EST must be supported for ACP domain than registrars. EST must be supported for ACP certificate
certificate renewal (see Section 6.1.5). BRSKI is an extension of renewal (see Section 6.1.5). BRSKI is an extension of EST, so
EST, so ANI/BRSKI registrars can easily support ACP domain ANI/BRSKI registrars can easily support ACP domain certificate
certificate renewal in addition to initial enrollment. renewal in addition to initial enrollment.
RPI: "RPL Packet Information". Network extension headers for use RPI: "RPL Packet Information". Network extension headers for use
with the ->"RPL" () routing protocols. Not used with RPL in the with the ->"RPL" () routing protocols. Not used with RPL in the
ACP. See Section 6.11.1.13. ACP. See Section 6.11.1.13.
RPL: "Routing Protocol for Low-Power and Lossy Networks". The RPL: "Routing Protocol for Low-Power and Lossy Networks". The
routing protocol used in the ACP. See Section 6.11. routing protocol used in the ACP. See Section 6.11.
sUDI: "secured Unique Device Identifier". This is another word to sUDI: "secured Unique Device Identifier". This is another word to
describe an IDevID in referenced material. This term is not used describe an IDevID in referenced material. This term is not used
skipping to change at page 18, line 19 skipping to change at page 18, line 24
devices along the path: As long as all devices along the path support devices along the path: As long as all devices along the path support
ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP
across a whole network of unconfigured devices can be brought up across a whole network of unconfigured devices can be brought up
without operator/provisioning intervention. The ACP also provides without operator/provisioning intervention. The ACP also provides
additional security for any bootstrap mechanism, because it can additional security for any bootstrap mechanism, because it can
provide encrypted discovery (via ACP GRASP) of registrars or other provide encrypted discovery (via ACP GRASP) of registrars or other
bootstrap servers by bootstrap proxies connecting to nodes that are bootstrap servers by bootstrap proxies connecting to nodes that are
to be bootstrapped and the ACP encryption hides the identities of the to be bootstrapped and the ACP encryption hides the identities of the
communicating entities (pledge and registrar), making it more communicating entities (pledge and registrar), making it more
difficult to learn which network node might be attackable. The ACP difficult to learn which network node might be attackable. The ACP
domain certificate can also be used to end-to-end encrypt the certificate can also be used to end-to-end encrypt the bootstrap
bootstrap communication between such proxies and server. Note that communication between such proxies and server. Note that
bootstrapping here includes not only the first step that can be bootstrapping here includes not only the first step that can be
provided by BRSKI (secure keys), but also later stages where provided by BRSKI (secure keys), but also later stages where
configuration is bootstrapped. configuration is bootstrapped.
3.3. Data-Plane Independent Permanent Reachability 3.3. Data-Plane Independent Permanent Reachability
Today, most critical control plane protocols and OAM protocols are Today, most critical control plane protocols and OAM protocols are
using the Data-Plane of the network. This leads to often undesirable using the Data-Plane of the network. This leads to often undesirable
dependencies between control and OAM plane on one side and the Data- dependencies between control and OAM plane on one side and the Data-
Plane on the other: Only if the forwarding and control plane of the Plane on the other: Only if the forwarding and control plane of the
skipping to change at page 20, line 34 skipping to change at page 20, line 39
The ACP operates hop-by-hop, because this interaction can be built on The ACP operates hop-by-hop, because this interaction can be built on
IPv6 link local addressing, which is autonomic, and has no dependency IPv6 link local addressing, which is autonomic, and has no dependency
on configuration (requirement 1). It may be necessary to have ACP on configuration (requirement 1). It may be necessary to have ACP
connectivity across non-ACP nodes, for example to link ACP nodes over connectivity across non-ACP nodes, for example to link ACP nodes over
the general Internet. This is possible, but introduces a dependency the general Internet. This is possible, but introduces a dependency
against stable/resilient routing over the non-ACP hops (see against stable/resilient routing over the non-ACP hops (see
Section 8.2). Section 8.2).
5. Overview (Informative) 5. Overview (Informative)
When a node has an ACP domain certificate (see Section 6.1.1) and is When a node has an ACP certificate (see Section 6.1.1) and is enabled
enabled to bring up the ACP (see Section 9.3.5), it will create its to bring up the ACP (see Section 9.3.5), it will create its ACP
ACP without any configuration as follows. For details, see Section 6 without any configuration as follows. For details, see Section 6 and
and further sections: further sections:
1. The node creates a VRF instance, or a similar virtual context for 1. The node creates a VRF instance, or a similar virtual context for
the ACP. the ACP.
2. The node assigns its ULA IPv6 address (prefix) (see Section 6.10 2. The node assigns its ULA IPv6 address (prefix) (see Section 6.10
which is learned from the acp-node-name (see (see Section 6.1.2) which is learned from the acp-node-name (see Section 6.1.2) of
of its ACP domain certificate (see Section 6.1.1) to an ACP its ACP certificate (see Section 6.1.1) to an ACP loopback
loopback interface (see Section 6.10) and connects this interface interface (see Section 6.10) and connects this interface into the
into the ACP VRF. ACP VRF.
3. The node establishes a list of candidate peer adjacencies and 3. The node establishes a list of candidate peer adjacencies and
candidate channel types to try for the adjacency. This is candidate channel types to try for the adjacency. This is
automatic for all candidate link-local adjacencies, see automatic for all candidate link-local adjacencies, see
Section 6.3 across all native interfaces (see Section 9.3.4). If Section 6.3 across all native interfaces (see Section 9.3.4). If
a candidate peer is discovered via multiple interfaces, this will a candidate peer is discovered via multiple interfaces, this will
result in one adjacency per interface. If the ACP node has result in one adjacency per interface. If the ACP node has
multiple interfaces connecting to the same subnet across which it multiple interfaces connecting to the same subnet across which it
is also operating as an L2 switch in the Data-Plane, it employs is also operating as an L2 switch in the Data-Plane, it employs
methods for ACP with L2 switching, see Section 7. methods for ACP with L2 switching, see Section 7.
skipping to change at page 21, line 23 skipping to change at page 21, line 28
5. The node authenticates the peer node during secure channel setup 5. The node authenticates the peer node during secure channel setup
and authorizes it to become part of the ACP according to and authorizes it to become part of the ACP according to
Section 6.1.3. Section 6.1.3.
6. Each successfully established secure channel is mapped into an 6. Each successfully established secure channel is mapped into an
ACP virtual interface, which is placed into the ACP VRF. See ACP virtual interface, which is placed into the ACP VRF. See
Section 6.12.5.2. Section 6.12.5.2.
7. Each node runs a lightweight routing protocol, see Section 6.11, 7. Each node runs a lightweight routing protocol, see Section 6.11,
to announce reachability of the ACP loopack address (or prefix) to announce reachability of the ACP loopback address (or prefix)
across the ACP. across the ACP.
8. This completes the creation of the ACP with hop-by-hop secure 8. This completes the creation of the ACP with hop-by-hop secure
tunnels, auto-addressing and auto-routing. The node is now an tunnels, auto-addressing and auto-routing. The node is now an
ACP node with a running ACP. ACP node with a running ACP.
Note: Note:
o None of the above operations (except the following explicit o None of the above operations (except the following explicit
configured ones) are reflected in the configuration of the node. configured ones) are reflected in the configuration of the node.
skipping to change at page 22, line 31 skipping to change at page 22, line 31
The resulting overlay network is normally based exclusively on hop- The resulting overlay network is normally based exclusively on hop-
by-hop tunnels. This is because addressing used on links is IPv6 by-hop tunnels. This is because addressing used on links is IPv6
link local addressing, which does not require any prior set-up. In link local addressing, which does not require any prior set-up. In
this way the ACP can be built even if there is no configuration on this way the ACP can be built even if there is no configuration on
the node, or if the Data-Plane has issues such as addressing or the node, or if the Data-Plane has issues such as addressing or
routing problems. routing problems.
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative)
This section describes the components and steps to set up an ACP and This section specifies the components and steps to set up an ACP.
highlights the key properties which make it "indestructible" against The ACP is automatically "self-creating", which makes it
many inadvertent changes to the Data-Plane, for example caused by "indestructible" against most changes to the Data-Plane, including
misconfigurations. misconfigurations of routing, addressing, NAT, firewall or any other
traffic policy filters that inadvertently or otherwise unavoidably
would also impact the management plane traffic, such as the actual
operator CLI session or controller NetConf session through which the
configuration changes to the Data-Plane are executed.
Physical misconfiguration of wiring between ACP nodes will also not
break the ACP: As long as there is a transitive physical path between
ACP nodes, the ACP should be able to recover given that it
automatically operates across all interfaces of the ACP nodes and
automatically determines paths between them.
Attacks against the network via incorrect routing or addressing
information for the Data-Plane will not impact the ACP. Even
impaired ACP nodes will have a significantly reduced attack surface
against malicious misconfiguration because only very limited ACP or
interface up/down configuration can affect the ACP, and pending on
their specific designs these type of attacks could also be
eliminated. See more in Section 9.3 and Section 11.
An ACP node can be a router, switch, controller, NMS host, or any An ACP node can be a router, switch, controller, NMS host, or any
other IP capable node. Initially, it MUST have its ACP domain other IPv6 capable node. Initially, it MUST have its ACP
certificate, as well as an (empty) ACP Adjacency Table (described in certificate, as well as an (empty) ACP Adjacency Table (described in
Section 6.2). It then can start to discover ACP neighbors and build Section 6.2). It then can start to discover ACP neighbors and build
the ACP. This is described step by step in the following sections: the ACP. This is described step by step in the following sections:
6.1. ACP Domain, Certificate and Network 6.1. ACP Domain, Certificate and Network
The ACP relies on group security. An ACP domain is a group of nodes The ACP relies on group security. An ACP domain is a group of nodes
that trust each other to participate in ACP operations such as that trust each other to participate in ACP operations such as
creating ACP secure channels in an autonomous peer-to-peer fashion creating ACP secure channels in an autonomous peer-to-peer fashion
between ACP domain members via protocols such as IPsec. To between ACP domain members via protocols such as IPsec. To
authenticate and authorize another ACP member node with access to the authenticate and authorize another ACP member node with access to the
ACP Domain, each ACP member requires keying material: An ACP node ACP Domain, each ACP member requires keying material: An ACP node
MUST have a Local Device IDentity (LDevID) certificate, henceforth MUST have a Local Device IDentity (LDevID) certificate, henceforth
called the ACP Domain Certificate and information about one or more called the ACP certificate and information about one or more Trust
Trust Anchor (TA) as required for the ACP domain membership check Anchor (TA) as required for the ACP domain membership check
(Section 6.1.3). (Section 6.1.3).
Manual keying via shared secrets is not usable for an ACP domain Manual keying via shared secrets is not usable for an ACP domain
because it would require a single shared secret across all current because it would require a single shared secret across all current
and future ACP domain members to meet the expectation of autonomous, and future ACP domain members to meet the expectation of autonomous,
peer-to-peer establishment of ACP secure channels between any ACP peer-to-peer establishment of ACP secure channels between any ACP
domain members. Such a single shared secret would be an inacceptable domain members. Such a single shared secret would be an inacceptable
security weakness. Asymmetric keying material (public keys) without security weakness. Asymmetric keying material (public keys) without
certificates does not provide the mechanisms to authenticate ACP certificates does not provide the mechanisms to authenticate ACP
domain membership in an autonomous, peer-to-peer fashion for current domain membership in an autonomous, peer-to-peer fashion for current
and future ACP domain members. and future ACP domain members.
The LDevID certificate is called the ACP domain certificate, the TA The LDevID certificate is called the ACP certificate, the TA is the
is the Certification Authority (CA) root certificate of the ACP Certification Authority (CA) root certificate of the ACP domain.
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
certificate to comply with Section 6.1.1, specifically to have the certificate to comply with Section 6.1.1, specifically to have the
acp-node-name as specified in Section 6.1.2 in its domain certificate acp-node-name as specified in Section 6.1.2 in its domain certificate
as well as those of candidate ACP peers. See Appendix A.2 for more as well as those of candidate ACP peers. See Appendix A.2 for more
information about enrollment or provisioning options. information about enrollment or provisioning 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
skipping to change at page 23, line 43 skipping to change at page 24, line 10
support for other components of autonomic networks except for relying support for other components of autonomic networks except for relying
on GRASP and providing security and transport for GRASP. Therefore on GRASP and providing security and transport for GRASP. Therefore
the word autonomic might be misleading to operators interested in the word autonomic might be misleading to operators interested in
only the ACP. only the ACP.
[RFC7575] defines the term "Autonomic Domain" as a collection of [RFC7575] defines the term "Autonomic Domain" as a collection of
autonomic nodes. ACP nodes do not need to be fully autonomic, but autonomic nodes. ACP nodes do not need to be fully autonomic, but
when they are, then the ACP domain is an autonomic domain. Likewise, when they are, then the ACP domain is an autonomic domain. Likewise,
[I-D.ietf-anima-reference-model] defines the term "Domain [I-D.ietf-anima-reference-model] defines the term "Domain
Certificate" as the certificate used in an autonomic domain. The ACP Certificate" as the certificate used in an autonomic domain. The ACP
domain certificate is that domain certificate when ACP nodes are certificate is that domain certificate when ACP nodes are (fully)
(fully) autonomic nodes. Finally, this document uses the term ACP autonomic nodes. Finally, this document uses the term ACP network to
network to refer to the network created by active ACP nodes in an ACP refer to the network created by active ACP nodes in an ACP domain.
domain. The ACP network itself can extend beyond ACP nodes through The ACP network itself can extend beyond ACP nodes through the
the mechanisms described in Section 8.1. mechanisms described in Section 8.1.
6.1.1. ACP Certificates 6.1.1. ACP Certificates
ACP domain certificates MUST be [RFC5280] compliant X.509v3 ACP certificates MUST be [RFC5280] compliant X.509 v3 ([X.509])
certificates. certificates.
ACP nodes MUST support handling ACP certificates, TA certificates and ACP nodes MUST support handling ACP certificates, TA certificates and
certificate chain certificates (henceforth just called certificates certificate chain certificates (henceforth just called certificates
in this section) with RSA public keys and certificates with Elliptic in this section) with RSA public keys and certificates with Elliptic
Curve (ECC) public keys. Curve (ECC) public keys.
ACP nodes MUST NOT support certificates with RSA public keys of less ACP nodes MUST NOT support certificates with RSA public keys of less
than 2048 bit modulus or curves with group order of less than 256 than 2048 bit modulus or curves with group order of less than 256
bit. They MUST support certificates with RSA public keys with 2048 bit. They MUST support certificates with RSA public keys with 2048
skipping to change at page 24, line 42 skipping to change at page 25, line 4
Any secure channel protocols used for the ACP as specified in this Any secure channel protocols used for the ACP as specified in this
document or extensions of this document MUST therefore support document or extensions of this document MUST therefore support
authentication (e.g.:signing) starting with these type of authentication (e.g.:signing) starting with these type of
certificates. See [RFC4492] for more information. certificates. See [RFC4492] for more information.
The reason for these choices are as follows: As of 2020, RSA is still The reason for these choices are as follows: As of 2020, RSA is still
more widely used than ECC, therefore the MUST for RSA. ECC offers more widely used than ECC, therefore the MUST for RSA. ECC offers
equivalent security at (logarithmically) shorter key lengths (see equivalent security at (logarithmically) shorter key lengths (see
[RFC4492]). This can be beneficial especially in the presence of [RFC4492]). This can be beneficial especially in the presence of
constrained bandwidth or constrained nodes in an ACP/ANI network. constrained bandwidth or constrained nodes in an ACP/ANI network.
Some ACP functions such as GRASP peer-2-peer across the ACP require Some ACP functions such as GRASP peer-2-peer across the ACP require
end-to-end/any-to-any authentication/authorization, therefore ECC can end-to-end/any-to-any authentication/authorization, therefore ECC can
only reliably be used in the ACP when it MUST be supported on all ACP only reliably be used in the ACP when it MUST be supported on all ACP
nodes. RSA signatures are mandatory to be supported also for ECC nodes. RSA signatures are mandatory to be supported also for ECC
certificates because CAs themselves may not support ECC yet. certificates because CAs themselves may not support ECC yet.
The ACP domain certificate SHOULD be used for any authentication The ACP certificate SHOULD be used for any authentication between
between nodes with ACP domain certificates (ACP nodes and NOC nodes) nodes with ACP domain certificates (ACP nodes and NOC nodes) where
where the required authorization condition is ACP domain membership, the required authorization condition is ACP domain membership, such
such as ACP node to NOC/OAM end-to-end security and ASA to ASA end- as ACP node to NOC/OAM end-to-end security and ASA to ASA end-to-end
to-end security. Section 6.1.3 defines this "ACP domain membership security. Section 6.1.3 defines this "ACP domain membership check".
check". The uses of this check that are standardized in this The uses of this check that are standardized in this document are for
document are for the establishment of hop-by-hop ACP secure channels the establishment of hop-by-hop ACP secure channels (Section 6.6) and
(Section 6.6) and for ACP GRASP (Section 6.8.2) end-to-end via TLS for ACP GRASP (Section 6.8.2) end-to-end via TLS 1.2 ([RFC5246]).
1.2 ([RFC5246]).
The ACP domain membership check requires a minimum amount of elements The ACP domain membership check requires a minimum amount of elements
in a certificate as described in Section 6.1.3. The identity of a in a certificate as described in Section 6.1.3. The identity of a
node in the ACP is carried via the acp-node-name as defined in node in the ACP is carried via the acp-node-name as defined in
Section 6.1.2. Section 6.1.2.
In support of ECDH key establishment, ACP certificates with ECC keys In support of ECDH key establishment, ACP certificates with ECC keys
MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH) if MUST indicate to be Elliptic Curve Diffie-Hellman capable (ECDH) if
X.509 v3 keyUsage and extendedKeyUsage are included in the X.509 v3 keyUsage and extendedKeyUsage are included in the
certificate. certificate.
Any other field of the ACP domain certificate is to be populated as Any other field of the ACP certificate is to be populated as required
required by [RFC5280] or desired by the operator of the ACP domain by [RFC5280] or desired by the operator of the ACP domain ACP
ACP registrars/CA and required by other purposes that the ACP domain registrars/CA and required by other purposes that the ACP certificate
certificate is intended to be used for. is intended to be used for.
For further certificate details, ACP certificates may follow the For further certificate details, ACP certificates may follow the
recommendations from [CABFORUM]. recommendations from [CABFORUM].
For diagnostic and other operational purposes, it is beneficial to For diagnostic and other operational purposes, it is beneficial to
copy the device identifying fields of the node's IDevID certificate copy the device identifying fields of the node's IDevID certificate
into the ACP domain certificate, such as the "serialNumber" (see into the ACP certificate, such as the "serialNumber" (see
[I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). This can be [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). This can be
done for example if it would be acceptable for the devices done for example if it would be acceptable for the devices
"serialNumber" to be signalled via the Link Layer Discovery Protocol "serialNumber" to be signalled via the Link Layer Discovery Protocol
(LLDP, [LLDP]) because like LLDP signalled information, the ACP (LLDP, [LLDP]) because like LLDP signalled information, the ACP
certificate information can be retrieved bei neighboring nodes certificate information can be retrieved by neighboring nodes without
without further authentication and be used either for beneficial further authentication and be used either for beneficial diagnostics
diagnostics or for malicious attacks. Retrieval of the ACP or for malicious attacks. Retrieval of the ACP certificate is
certificate is possible via a (failing) attempt to set up an ACP possible via a (failing) attempt to set up an ACP secure channel, and
secure channel, and the "serialNumber" contains usually device type the "serialNumber" contains usually device type information that may
information that may help to faster determine working exploits/ help to faster determine working exploits/attacks against the device.
attacks against the device.
Note that there is no intention to constrain authorization within the Note that there is no intention to constrain authorization within the
ACP or autonomic networks using the ACP to just the ACP domain ACP or autonomic networks using the ACP to just the ACP domain
membership check as defined in this document. It can be extended or membership check as defined in this document. It can be extended or
modified with future requirements. Such future authorizations can modified with future requirements. Such future authorizations can
use and require additional elements in certificates or policies or use and require additional elements in certificates or policies or
even additional certificates. For an example, see Appendix A.10.5. even additional certificates. For an example, see Appendix A.10.5.
6.1.2. ACP Certificate AcpNodeName 6.1.2. ACP Certificate AcpNodeName
skipping to change at page 26, line 34 skipping to change at page 26, line 41
then this results in: then this results in:
acp-node-name = fd89b714F3db00000200000064000000 acp-node-name = fd89b714F3db00000200000064000000
+area51.research@acp.example.com +area51.research@acp.example.com
acp-domain-name = acp.example.com acp-domain-name = acp.example.com
routing-subdomain = area51.research.acp.example.com routing-subdomain = area51.research.acp.example.com
Figure 2: ACP Node Name ABNF Figure 2: ACP Node Name ABNF
acp-node-name in above Figure 2 is the ABNF ([RFC5234]) definition of acp-node-name in above Figure 2 is the ABNF ([RFC5234]) definition of
the ACP Node Name. An ACP domain certificate MUST carry this the ACP Node Name. An ACP certificate MUST carry this information.
information. It MUST be encoded as a subjectAltName / otherName / It MUST be encoded as a subjectAltName / otherName / AcpNodeName as
AcpNodeName as described in Section 6.1.2.1. described in Section 6.1.2.1.
Nodes complying with this specification MUST be able to receive their Nodes complying with this specification MUST be able to receive their
ACP address through the domain certificate, in which case their own ACP address through the domain certificate, in which case their own
ACP domain certificate MUST have the 32HEXDIG "acp-address" field. ACP certificate MUST have a 32HEXLC "acp-address" field. Nodes
Nodes complying with this specification MUST also be able to complying with this specification MUST also be able to authenticate
authenticate nodes as ACP domain members or ACP secure channel peers nodes as ACP domain members or ACP secure channel peers when they
when they have a 0-value acp-address field and as ACP domain members have a 0-value acp-address field and as ACP domain members (but not
(but not as ACP secure channel peers) when they have an empty acp- as ACP secure channel peers) when they have an empty acp-address
address field. See Section 6.1.3. field. See Section 6.1.3.
acp-domain-name is used to indicate the ACP Domain across which ACP acp-domain-name is used to indicate the ACP Domain across which ACP
nodes authenticate and authorize each other, for example to build ACP nodes authenticate and authorize each other, for example to build ACP
secure channels to each other, see Section 6.1.3. acp-domain-name secure channels to each other, see Section 6.1.3. acp-domain-name
SHOULD be the FQDN of an Internet domain owned by the network SHOULD be the FQDN of an Internet domain owned by the network
administration of the ACP and ideally reserved to only be used for administration of the ACP and ideally reserved to only be used for
the ACP. In this specification it serves to be a name for the ACP the ACP. In this specification it serves to be a name for the ACP
that ideally is globally unique. When acp-domain-name is a globally that ideally is globally unique. When acp-domain-name is a globally
unique name, collision of ACP addresses across different ACP domains unique name, collision of ACP addresses across different ACP domains
can only happen due to ULA hash collisions (see Section 6.10.2). can only happen due to ULA hash collisions (see Section 6.10.2).
Using different acp-domain-names, operators can distinguish multiple Using different acp-domain-names, operators can distinguish multiple
ACP even when using the same TA. ACP even when using the same TA.
To keep the encoding simple, there is no consideration for To keep the encoding simple, there is no consideration for
internationalized acp-domain-names. The acp-node-name is not internationalized acp-domain-names. The acp-node-name is not
intended for end user consumption, and there is no protection against intended for end user consumption, and there is no protection against
someone not owning a domain name to simpy choose it. Instead, it someone not owning a domain name to simply choose it. Instead, it
serves as a hash seed for the ULA and for diagnostics to the serves as a hash seed for the ULA and for diagnostics to the
operator. Therefore, any operator owning only an internationalized operator. Therefore, any operator owning only an internationalized
domain name should be able to pick an equivalently unique 7-bit ASCII domain name should be able to pick an equivalently unique 7-bit ASCII
acp-domain-name string representing the internationalized domain acp-domain-name string representing the internationalized domain
name. name.
"routing-subdomain" is a string that can be constructed from the acp- "routing-subdomain" is a string that can be constructed from the acp-
node-name, and it is used in the hash-creation of the ULA (see node-name, and it is used in the hash-creation of the ULA (see
below). The presence of the "rsub" component allows a single ACP below). The presence of the "rsub" component allows a single ACP
domain to employ multiple /48 ULA prefixes. See Appendix A.7 for domain to employ multiple /48 ULA prefixes. See Appendix A.7 for
skipping to change at page 28, line 12 skipping to change at page 28, line 17
2. The encoding of the ACP domain name and ACP address as described 2. The encoding of the ACP domain name and ACP address as described
in this section is used for the following reasons: in this section is used for the following reasons:
2.1 The acp-node-name is the identifier of a node's ACP. It 2.1 The acp-node-name is the identifier of a node's ACP. It
includes the necessary components to identify a nodes ACP includes the necessary components to identify a nodes ACP
both from within the ACP as well as from the outside of the both from within the ACP as well as from the outside of the
ACP. ACP.
2.2 For manual and/or automated diagnostics and backend 2.2 For manual and/or automated diagnostics and backend
management of devices and ACPs, it is necessary to have an management of devices and ACPs, it is necessary to have an
easily human readible and software parsed standard, single easily human readable and software parsed standard, single
string representation of the information in the acp-node- string representation of the information in the acp-node-
name. For example, inventory or other backend systems can name. For example, inventory or other backend systems can
always identify an entity by one unique string field but not always identify an entity by one unique string field but not
by a combination of multiple fields, which would be by a combination of multiple fields, which would be
necessary if there was no single string representation. necessary if there was no single string representation.
2.3 If the encoding was not that of such a string, it would be 2.3 If the encoding was not that of such a string, it would be
necessary to define a second standard encoding to provide necessary to define a second standard encoding to provide
this format (standard string encoding) for operator this format (standard string encoding) for operator
consumption. consumption.
2.4 Adresses of the form <local><@domain> have become the 2.4 Addresses of the form <local><@domain> have become the
preferred format for identifiers of entities in many preferred format for identifiers of entities in many
systems, including the majority of user identification in systems, including the majority of user identification in
web or mobile applications such as multi-domain single-sign- web or mobile applications such as multi-domain single-sign-
on systems. on systems.
3. Compatibilities: 3. Compatibilities:
3.1 It should be possible to use the ACP domain certificate as 3.1 It should be possible to use the ACP certificate as an
an LDevID certificate on the system for other uses beside LDevID certificate on the system for other uses beside the
the ACP. Therefore, the information element required for ACP. Therefore, the information element required for the
the ACP should be encoded so that it minimizes the ACP should be encoded so that it minimizes the possibility
possibility of creating incompatibilities with such other of creating incompatibilities with such other uses. The
uses. The subjectName is for example often used as an subjectName is for example often used as an entity
entity identifier in non-ACP uses of a the ACP Domain identifier in non-ACP uses of a the ACP certificate.
certificate.
3.2 The element should not require additional ASN.1 en/decoding, 3.2 The element should not require additional ASN.1 en/decoding,
because libraries to access certificate information because libraries to access certificate information
especially for embedded devices may not support extended especially for embedded devices may not support extended
ASN.1 decoding beyond predefined, manadatory fields. ASN.1 decoding beyond predefined, mandatory fields.
subjectAltName / otherName is already used with a single subjectAltName / otherName is already used with a single
string parameter for several otherNames (see [RFC3920], string parameter for several otherNames (see [RFC3920],
[RFC7585], [RFC4985], [RFC8398]). [RFC7585], [RFC4985], [RFC8398]).
3.3 The element required for the ACP should minimize the risk of 3.3 The element required for the ACP should minimize the risk of
being misinterpreted by other uses of the LDevID being misinterpreted by other uses of the LDevID
certificate. It also must not be misinterpreted to actually certificate. It also must not be misinterpreted to actually
be an email address, hence the use of the otherName / be an email address, hence the use of the otherName /
rfc822Name option in the certificate would be inapproprite. rfc822Name option in the certificate would be inappropriate.
See section 4.2.1.6 of [RFC5280] for details on the subjectAltName See section 4.2.1.6 of [RFC5280] for details on the subjectAltName
field. field.
6.1.2.1. AcpNodeName ASN.1 Module 6.1.2.1. AcpNodeName ASN.1 Module
The following ASN.1 module normatively specifies the AcpNodeName The following ASN.1 module normatively specifies the AcpNodeName
structure. This specification uses the ASN.1 definitions from structure. This specification uses the ASN.1 definitions from
[RFC5912] with the 2002 ASN.1 notation used in that document. [RFC5912] with the 2002 ASN.1 notation used in that document.
[RFC5912] updates normative documents using older ASN.1 notation. [RFC5912] updates normative documents using older ASN.1 notation.
skipping to change at page 30, line 17 skipping to change at page 30, line 52
The following points constitute the ACP domain membership check of a The following points constitute the ACP domain membership check of a
candidate peer via its certificate: candidate peer via its certificate:
1: The peer has proved ownership of the private key associated with 1: The peer has proved ownership of the private key associated with
the certificate's public key. This check is performed by the the certificate's public key. This check is performed by the
security association protocol used, for example [RFC7296], section security association protocol used, for example [RFC7296], section
2.15. 2.15.
2: The peer's certificate passes certificate path validation as 2: The peer's certificate passes certificate path validation as
defined in [RFC5280], section 6 against one of the TA associated defined in [RFC5280], section 6 against one of the TA associated
with the ACP node's ACP domain certificate (see Section 6.1.4 with the ACP node's ACP certificate (see Section 6.1.4 below).
below). This includes verification of the validity (lifetime) of
the certificates in the path. This includes verification of the validity (lifetime) of the
certificates in the path.
3: If the node certificate indicates a Certificate Revocation List 3: If the node certificate indicates a Certificate Revocation List
(CRL) Distribution Point (CRLDP) ([RFC5280], section 4.2.1.13) or (CRL) Distribution Point (CRLDP) ([RFC5280], section 4.2.1.13) or
Online Certificate Status Protocol (OCSP) responder ([RFC5280], Online Certificate Status Protocol (OCSP) responder ([RFC5280],
section 4.2.2.1), then the peer's certificate MUST be valid section 4.2.2.1), then the peer's certificate MUST be valid
according to those mechanisms when they are available: An OCSP according to those mechanisms when they are available: An OCSP
check for the peer's certificate across the ACP must succeed or check for the peer's certificate across the ACP must succeed or
the peer certificate must not be listed in the CRL retrieved from the peer certificate must not be listed in the CRL retrieved from
the CRLDP. These mechanisms are not available when the node has the CRLDP. These mechanisms are not available when the node has
no ACP or non-ACP connectivity to retrieve a current CRL or access no ACP or non-ACP connectivity to retrieve a current CRL or access
skipping to change at page 31, line 6 skipping to change at page 31, line 40
4: The peer's certificate has a syntactically valid acp-node-name 4: The peer's certificate has a syntactically valid acp-node-name
field and the acp-domain-name in that peer's acp-node-name is the field and the acp-domain-name in that peer's acp-node-name is the
same as in this ACP node's certificate (lowercase normalized). same as in this ACP node's certificate (lowercase normalized).
When checking a candidate peer's certificate for the purpose of When checking a candidate peer's certificate for the purpose of
establishing an ACP secure channel, one additional check is establishing an ACP secure channel, one additional check is
performed: performed:
5: The candidate peer certificate's acp-node-name has a non-empty 5: The candidate peer certificate's acp-node-name has a non-empty
acp-address field (either 32HEXDIG or 0, according to Figure 2). acp-address field (either 32HEXLC or 0, according to Figure 2).
Technically, ACP secure channels can only be built with nodes that Technically, ACP secure channels can only be built with nodes that
have an acp-address. Rule 5 ensures that this is taken into account have an acp-address. Rule 5 ensures that this is taken into account
during ACP domain membership check. during ACP domain membership check.
Nodes with an empty acp-address field can only use their ACP domain Nodes with an empty acp-address field can only use their ACP domain
certificate for non-ACP-secure channel authentication purposes. This certificate for non-ACP-secure channel authentication purposes. This
includes for example NMS type nodes permitted to communicate into the includes for example NMS type nodes permitted to communicate into the
ACP via ACP connect (Section 8.1) ACP via ACP connect (Section 8.1)
The special value 0 in an ACP certificates acp-address field is used The special value 0 in an ACP certificates acp-address field is used
for nodes that can and should determine their ACP address through for nodes that can and should determine their ACP address through
other mechanisms than learning it through the acp-address field in other mechanisms than learning it through the acp-address field in
their ACP domain certificate. These ACP nodes are permitted to their ACP certificate. These ACP nodes are permitted to establish
establish ACP secure channels. Mechanisms for those nodes to ACP secure channels. Mechanisms for those nodes to determine their
determine their ACP address are outside the scope of this ACP address are outside the scope of this specification, but this
specification, but this option is defined here so that any ACP nodes option is defined here so that any ACP nodes can build ACP secure
can build ACP secure channels to them according to Rule 5. channels to them according to Rule 5.
In summary: In summary:
Steps 1...4 constitute standard certificate validity verification Steps 1...4 constitute standard certificate validity verification
and private key authentication as defined by [RFC5280] and and private key authentication as defined by [RFC5280] and
security association protocols (such as Internet Key Exchange security association protocols (such as Internet Key Exchange
Protocol version 2 IKEv2 [RFC7296] when leveraging certificates. Protocol version 2 IKEv2 [RFC7296] when leveraging certificates.
Steps 1...4 do not include verification of any pre-existing form Steps 1...4 do not include verification of any pre-existing form
of non-public-key-only based identity elements of a certificate of non-public-key-only based identity elements of a certificate
skipping to change at page 32, line 14 skipping to change at page 32, line 46
For brevity, the remainder of this document refers to this process For brevity, the remainder of this document refers to this process
only as authentication instead of as authentication and only as authentication instead of as authentication and
authorization. authorization.
6.1.3.1. Realtime clock and Time Validation 6.1.3.1. Realtime clock and Time Validation
An ACP node with a realtime clock in which it has confidence, MUST An ACP node with a realtime clock in which it has confidence, MUST
check the time stamps when performing ACP domain membership check check the time stamps when performing ACP domain membership check
such as as the certificate validity period in step 1. and the such as as the certificate validity period in step 1. and the
respective times in step 4 for revocation information (e.g.: respective times in step 4 for revocation information (e.g.,
signingTimes in CMS signatures). signingTimes in CMS signatures).
An ACP node without such a realtime clock MAY ignore those time stamp An ACP node without such a realtime clock MAY ignore those time stamp
validation steps if it does not know the current time. Such an ACP validation steps if it does not know the current time. Such an ACP
node SHOULD obtain the current time in a secured fashion, such as via node SHOULD obtain the current time in a secured fashion, such as via
a Network Time Protocol signalled through the ACP. It then ignores a Network Time Protocol signaled through the ACP. It then ignores
time stamp validation only until the current time is known. In the time stamp validation only until the current time is known. In the
absence of implementing a secured mechanism, such an ACP node MAY use absence of implementing a secured mechanism, such an ACP node MAY use
a current time learned in an insecured fashion in the ACP domain a current time learned in an insecure fashion in the ACP domain
membership check. membership check.
Current time MAY for example be learned unsecured via NTP ([RFC5905])
over the same link-local IPv6 addresses used for the ACP from
neighboring ACP nodes. ACP nodes that do provide NTP insecure over
their link-local addresses SHOULD primarily run NTP across the ACP
and provide NTP time across the ACP only when they have a trusted
time source. Details for such NTP procedures are beyond the scope of
this specification.
Beside ACP domain membership check, the ACP itself has no dependency Beside ACP domain membership check, the ACP itself has no dependency
against knowledge of the current time, but protocols and services against knowledge of the current time, but protocols and services
using the ACP will likley have the need to know the current time. using the ACP will likeley have the need to know the current time.
For example event logging. For example event logging.
6.1.4. Trust Anchors (TA) 6.1.4. Trust Anchors (TA)
ACP nodes need TA information according to [RFC5280], section 6.1.1 ACP nodes need TA information according to [RFC5280], section 6.1.1
(d), typically in the form of one or more certificate of the TA to (d), typically in the form of one or more certificate of the TA to
perform certificate path validation as required by Section 6.1.3, perform certificate path validation as required by Section 6.1.3,
rule 2. TA information MUST be provisioned to an ACP node (together rule 2. TA information MUST be provisioned to an ACP node (together
with its ACP domain certificate) by an ACP Registrar during initial with its ACP domain certificate) by an ACP Registrar during initial
enrolment of a candidate ACP node. ACP nodes MUST also support enrolment of a candidate ACP node. ACP nodes MUST also support
skipping to change at page 33, line 26 skipping to change at page 34, line 19
certificate path validation with 0 or 1 intermediate CA. They SHOULD certificate path validation with 0 or 1 intermediate CA. They SHOULD
support 2 intermediate CA and two TA (to permit migration to from one support 2 intermediate CA and two TA (to permit migration to from one
TA to another TA). TA to another TA).
Certificates for an ACP MUST only be given to nodes that are allowed Certificates for an ACP MUST only be given to nodes that are allowed
to be members of that ACP. When the signing CA relies on an ACP to be members of that ACP. When the signing CA relies on an ACP
Registrar, the CA MUST only sign certificates with acp-node-name Registrar, the CA MUST only sign certificates with acp-node-name
through trusted ACP Registrars. In this setup, any existing CA, through trusted ACP Registrars. In this setup, any existing CA,
unaware of the formatting of acp-node-name, can be used. unaware of the formatting of acp-node-name, can be used.
These requirements can be achieved by using TA private to the owner These requirements can be achieved by using a TA private to the owner
of the ACP domain or potentially through appropriate contractual of the ACP domain or potentially through appropriate contractual
agreements between the involved parties (Registrar and CA). These agreements between the involved parties (Registrar and CA). These
requirements typically exclude public CA, because they in general do requirements typically exclude public CA, because they in general do
not support the notion of trusted registrars vouching for the not support the notion of trusted registrars vouching for the
correctness of the fields of a requested certificate or would by correctness of the fields of a requested certificate or would by
themselves not be capable to validate the correctness of otherName / themselves not be capable to validate the correctness of otherName /
AcpNodeName. AcpNodeName.
A single owner can operate multiple independent ACP domains from the A single owner can operate multiple independent ACP domains from the
same set of TA. Registrars must then know which ACP a node needs to same set of TA. Registrars must then know which ACP a node needs to
skipping to change at page 33, line 49 skipping to change at page 34, line 42
6.1.5. Certificate and Trust Anchor Maintenance 6.1.5. Certificate and Trust Anchor Maintenance
ACP nodes MUST support renewal of their Certificate and TA ACP nodes MUST support renewal of their Certificate and TA
information via EST ("Enrollment over Secure Transport", see information via EST ("Enrollment over Secure Transport", see
[RFC7030]) and MAY support other mechanisms. An ACP network MUST [RFC7030]) and MAY support other mechanisms. An ACP network MUST
have at least one ACP node supporting EST server functionality across have at least one ACP node supporting EST server functionality across
the ACP so that EST renewal is useable. the ACP so that EST renewal is useable.
ACP nodes SHOULD be able to remember the IPv6 locator parameters of ACP nodes SHOULD be able to remember the IPv6 locator parameters of
the O_IPv6_LOCATOR in GRASP of the EST server from which they last the O_IPv6_LOCATOR in GRASP of the EST server from which they last
renewed their ACP domain certificate. They SHOULD provide the renewed their ACP certificate. They SHOULD provide the ability for
ability for these EST server parameters to also be set by the ACP these EST server parameters to also be set by the ACP Registrar (see
Registrar (see Section 6.10.7) that initially enrolled the ACP device Section 6.10.7) that initially enrolled the ACP device with its ACP
with its ACP domain certificate. When BRSKI (see certificate. When BRSKI (see
[I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the IPv6 locator of
the BRSKI registrar from the BRSKI TLS connection SHOULD be the BRSKI registrar from the BRSKI TLS connection SHOULD be
remembered and used for the next renewal via EST if that registrar remembered and used for the next renewal via EST if that registrar
also announces itself as an EST server via GRASP (see next section) also announces itself as an EST server via GRASP (see next section)
on its ACP address. on its ACP address.
The EST server MUST present a certificate that is passing ACP domain The EST server MUST present a certificate that is passing ACP domain
membership check in its TLS connection setup (Section 6.1.3, rules membership check in its TLS connection setup (Section 6.1.3, rules
1..4, not rule 5 as this is not for an ACP secure channel setup). 1..4, not rule 5 as this is not for an ACP secure channel setup).
The EST server certificate MUST also contain the id-kp-cmcRA The EST server certificate MUST also contain the id-kp-cmcRA
skipping to change at page 36, line 38 skipping to change at page 37, line 38
It is common to use domain names for CRLDP(s), but there is no It is common to use domain names for CRLDP(s), but there is no
requirement for the ACP to support DNS. Any DNS lookup in the Data- requirement for the ACP to support DNS. Any DNS lookup in the Data-
Plane is not only a possible security issue, but it would also not Plane is not only a possible security issue, but it would also not
indicate whether the resolved address is meant to be reachable across indicate whether the resolved address is meant to be reachable across
the ACP. Therefore, the use of an IPv6 address versus the use of a the ACP. Therefore, the use of an IPv6 address versus the use of a
DNS name doubles as an indicator whether or not to reach the CRLDP DNS name doubles as an indicator whether or not to reach the CRLDP
via the ACP. via the ACP.
A CRLDP can be reachable across the ACP either by running it on a A CRLDP can be reachable across the ACP either by running it on a
node with ACP or by connecting its node via an ACP connect interface node with ACP or by connecting its node via an ACP connect interface
(see Section 8.1). The CRLDP SHOULD use an ACP domain certificate (see Section 8.1). The CRLDP SHOULD use an ACP certificate for its
for its HTTPs connections. The connecting ACP node SHOULD verify HTTPs connections. The connecting ACP node SHOULD verify that the
that the CRLDP certificate used during the HTTPs connection has the CRLDP certificate used during the HTTPs connection has the same ACP
same ACP address as indicated in the CRLDP URL of the node's ACP address as indicated in the CRLDP URL of the node's ACP certificate
domain certificate if the CRLDP URL uses an IPv6 address. if the CRLDP URL uses an IPv6 address.
6.1.5.4. Lifetimes 6.1.5.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 certificates are managed via a CA chain where the assigning
assigning CA has enough performance to manage short lived CA has enough performance to manage short lived certificates. See
certificates. See also Section 9.2.4 for discussion about an example also Section 9.2.4 for discussion about an example setup achieving
setup achieving this. See also [I-D.ietf-acme-star]. this. See also [I-D.ietf-acme-star].
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 Appendix A.2 for further optimizations of certificate maintenance See Appendix A.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.5.5. Re-enrollment 6.1.5.5. Re-enrollment
An ACP node may determine that its ACP domain certificate has An ACP node may determine that its ACP certificate has expired, for
expired, for example because the ACP node was powered down or example because the ACP node was powered down or disconnected longer
disconnected longer than its certificate lifetime. In this case, the than its certificate lifetime. In this case, the ACP node SHOULD
ACP node SHOULD convert to a role of a re-enrolling candidate ACP convert to a role of a re-enrolling candidate ACP node.
node.
In this role, the node does maintain the TA and certificate chain In this role, the node does maintain the TA and certificate chain
associated with its ACP domain certificate exclusively for the associated with its ACP certificate exclusively for the purpose of
purpose of re-enrollment, and attempts (or waits) to get re-enrolled re-enrollment, and attempts (or waits) to get re-enrolled with a new
with a new ACP certificate. The details depend on the mechanisms/ ACP certificate. The details depend on the mechanisms/protocols used
protocols used by the ACP Registrars. by the ACP Registrars.
Please refer to Section 6.10.7 and Please refer to Section 6.10.7 and
[I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP
Registrars and vouchers as used in the following text. When ACP is Registrars and vouchers as used in the following text. When ACP is
intended to be used without BRSKI, the details about BRSKI and intended to be used without BRSKI, the details about BRSKI and
vouchers in the following text can be skipped. vouchers in the following text can be skipped.
When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re- When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re-
enrolling candidate ACP node would attempt to enroll like a candidate enrolling candidate ACP node would attempt to enroll like a candidate
ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID
certificate, it SHOULD first attempt to use its ACP domain certificate, it SHOULD first attempt to use its ACP domain
certificate in the BRSKI TLS authentication. The BRSKI registrar MAY certificate in the BRSKI TLS authentication. The BRSKI registrar MAY
honor this certificate beyond its expiration date purely for the honor this certificate beyond its expiration date purely for the
purpose of re-enrollment. Using the ACP node's domain certificate purpose of re-enrollment. Using the ACP node's domain certificate
allows the BRSKI registrar to learn that node's acp-node-name, so allows the BRSKI registrar to learn that node's acp-node-name, so
that the BRSKI registrar can re-assign the same ACP address that the BRSKI registrar can re-assign the same ACP address
information to the ACP node in the new ACP domain certificate. information to the ACP node in the new ACP certificate.
If the BRSKI registrar denies the use of the old ACP domain If the BRSKI registrar denies the use of the old ACP certificate, the
certificate, the re-enrolling candidate ACP node MUST re-attempt re- re-enrolling candidate ACP node MUST re-attempt re-enrollment using
enrollment using its IDevID certificate as defined in BRSKI during its IDevID certificate as defined in BRSKI during the TLS connection
the TLS connection setup. setup.
Both when the BRSKI connection is attempted with the old ACP domain Both when the BRSKI connection is attempted with the old ACP
certificate or the IDevID certificate, the re-enrolling candidate ACP certificate or the IDevID certificate, the re-enrolling candidate ACP
node SHOULD authenticate the BRSKI registrar during TLS connection node SHOULD authenticate the BRSKI registrar during TLS connection
setup based on its existing TA certificate chain information setup based on its existing TA certificate chain information
associated with its old ACP certificate. The re-enrolling candidate associated with its old ACP certificate. The re-enrolling candidate
ACP node SHOULD only fall back to requesting a voucher from the BRSKI ACP node SHOULD only fall back to requesting a voucher from the BRSKI
registrar when this authentication fails during TLS connection setup. registrar when this authentication fails during TLS connection setup.
When other mechanisms than BRSKI are used for ACP domain certificate When other mechanisms than BRSKI are used for ACP certificate
enrollment, the principles of the re-enrolling candidate ACP node are enrollment, the principles of the re-enrolling candidate ACP node are
the same. The re-enrolling candidate ACP node attempts to the same. The re-enrolling candidate ACP node attempts to
authenticate any ACP Registrar peers during re-enrollment protocol/ authenticate any ACP Registrar peers during re-enrollment protocol/
mechanisms via its existing certificate chain/TA information and mechanisms via its existing certificate chain/TA information and
provides its existing ACP domain certificate and other identification provides its existing ACP certificate and other identification (such
(such as the IDevID certificate) as necessary to the registrar. as the IDevID certificate) as necessary to the registrar.
Maintaining existing TA information is especially important when Maintaining existing TA information is especially important when
enrollment mechanisms are used that unlike BRSKI do not leverage a enrollment mechanisms are used that unlike BRSKI do not leverage a
voucher mechanism to authenticate the ACP registrar and where voucher mechanism to authenticate the ACP registrar and where
therefore the injection of certificate failures could otherwise make therefore the injection of certificate failures could otherwise make
the ACP node easily attackable remotely. the ACP node easily attackable remotely.
When using BRSKI or other protocol/mechanisms supporting vouchers, When using BRSKI or other protocol/mechanisms supporting vouchers,
maintaining existing TA information allows for re-enrollment of maintaining existing TA information allows for re-enrollment of
expired ACP certificates to be more lightweight, especially in expired ACP certificates to be more lightweight, especially in
environments where repeated acquisition of vouchers during the environments where repeated acquisition of vouchers during the
lifetime of ACP nodes may be operationally expensive or otherwise lifetime of ACP nodes may be operationally expensive or otherwise
undesirable. undesirable.
6.1.5.6. Failing Certificates 6.1.5.6. Failing Certificates
An ACP domain certificate is called failing in this document, if/when An ACP certificate is called failing in this document, if/when the
the ACP node to which the certificate was issued can determine that ACP node to which the certificate was issued can determine that it
it was revoked (or explicitly not renewed), or in the absence of such was revoked (or explicitly not renewed), or in the absence of such
explicit local diagnostics, when the ACP node fails to connect to explicit local diagnostics, when the ACP node fails to connect to
other ACP nodes in the same ACP domain using its ACP certificate. other ACP nodes in the same ACP domain using its ACP certificate.
For connection failures to determine the ACP domain certificate as For connection failures to determine the ACP certificate as the
the culprit, the peer should pass the domain membership check culprit, the peer should pass the domain membership check
(Section 6.1.3) and other reasons for the connection failure can be (Section 6.1.3) and other reasons for the connection failure can be
excluded because of the connection error diagnostics. excluded because of the connection error diagnostics.
This type of failure can happen during setup/refresh of a secure ACP This type of failure can happen during setup/refresh of a secure ACP
channel connections or any other use of the ACP domain certificate, channel connections or any other use of the ACP certificate, such as
such as for the TLS connection to an EST server for the renewal of for the TLS connection to an EST server for the renewal of the ACP
the ACP domain certificate. domain certificate.
Example reasons for failing certificates that the ACP node can only Example reasons for failing certificates that the ACP node can only
discover through connection failure are that the domain certificate discover through connection failure are that the domain certificate
or any of its signing certificates could have been revoked or may or any of its signing certificates could have been revoked or may
have expired, but the ACP node cannot self-diagnose this condition have expired, but the ACP node cannot self-diagnose this condition
directly. Revocation information or clock synchronization may only directly. Revocation information or clock synchronization may only
be available across the ACP, but the ACP node cannot build ACP secure be available across the ACP, but the ACP node cannot build ACP secure
channels because ACP peers reject the ACP node's domain certificate. channels because ACP peers reject the ACP node's domain certificate.
ACP nodes SHOULD support the option to determines whether its ACP ACP nodes SHOULD support the option to determines whether its ACP
skipping to change at page 40, line 36 skipping to change at page 41, line 34
as pure L2 bridges for IPv6 multicast packets for DULL GRASP to work. as pure 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 9.3 for further, non- across ACP virtual interfaces. See Section 9.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
certificate (see Appendix A.2 for a summary), then the above certificate (see Appendix A.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
skipping to change at page 42, line 12 skipping to change at page 43, line 12
supported by the node to negotiate a secure channel. IKEv2 as shown supported by the node to negotiate a secure channel. IKEv2 as shown
above is the protocol used to negotiate an IPsec secure channel. above is the protocol used to negotiate an IPsec secure channel.
The locator-option is optional and only required when the secure The locator-option is optional and only required when the secure
channel protocol is not offered at a well-defined port number, or if channel protocol is not offered at a well-defined port number, or if
there is no well-defined port number. there is no well-defined port number.
IKEv2 is the actual protocol used to negotiate an Internet Protocol IKEv2 is the actual protocol used to negotiate an Internet Protocol
security architecture (IPsec) connection. GRASP therefore indicates security architecture (IPsec) connection. GRASP therefore indicates
"IKEv2" and not "IPsec". If "IPsec" was used, this too could mean "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean
use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has am use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has an
IANA assigned port number 500, but in the above example, the IANA assigned port number 500, but in the above example, the
candidate ACP neighbor is offering ACP secure channel negotiation via candidate ACP neighbor is offering ACP secure channel negotiation via
IKEv2 on port 15000 (purely to show through the example that GRASP IKEv2 on port 15000 (purely to show through the example that GRASP
allows to indicate the port number and it does not have to be the allows to indicate the port number and it does not have to be the
IANA assigned one). IANA assigned one).
"DTLS" indicates DTLS 1.2. This can also be a newer version of the "DTLS" indicates DTLS 1.2. This can also be a newer version of the
protocol as long as it can negotiate down to version 1.2 in the protocol as long as it can negotiate down to version 1.2 in the
presence of a peer only speaking DTLS 1.2. There is no default UDP presence of a peer only speaking DTLS 1.2. There is no default UDP
port for DTLS, it is always locally assigned by the node. For port for DTLS, it is always locally assigned by the node. For
skipping to change at page 42, line 51 skipping to change at page 43, line 51
in the same M_FLOOD message, since GRASP allows multiple objectives in the same M_FLOOD message, since GRASP allows multiple objectives
in one message. This may be impractical though if ACP and BRSKI in one message. This may be impractical though if ACP and BRSKI
operations are implemented via separate software modules / ASAs. operations are implemented via separate software modules / ASAs.
The result of the discovery is the IPv6 link-local address of the The result of the discovery is the IPv6 link-local address of the
neighbor as well as its supported secure channel protocols (and non- neighbor as well as its supported secure channel protocols (and non-
standard port they are running on). It is stored in the ACP standard port they are running on). It is stored in the ACP
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.
Note that the DULL GRASP objective described does intentionally not Note that the DULL GRASP objective described intentionally does not
include ACP nodes ACP domain certificate even though this would be include ACP nodes ACP certificate even though this would be useful
useful for diagnostics and to simplify the security exchange in ACP for diagnostics and to simplify the security exchange in ACP secure
secure channel security association protocols (see Section 6.7). The channel security association protocols (see Section 6.7). The reason
reason is that DULL GRASP messages are periodically multicasted is that DULL GRASP messages are periodically multicasted across IPv6
across IPv6 subnets and full certificates could easily lead to subnets and full certificates could easily lead to fragmented IPv6
fragmented IPv6 DULL GRASP multicast packets due to the size of a DULL GRASP multicast packets due to the size of a certificate. This
certificate. This would be highly undesirable. would be highly undesirable.
6.4. Candidate ACP Neighbor Selection 6.4. Candidate ACP Neighbor Selection
An ACP node determines to which other ACP nodes in the adjacency An ACP node determines to which other ACP nodes in the adjacency
table it should attempt to build an ACP connection. This is based on table it should attempt to build an ACP connection. This is based on
the information in the ACP Adjacency table. the information in the ACP Adjacency table.
The ACP is established exclusively between nodes in the same domain. The ACP is established exclusively between nodes in the same domain.
This includes all routing subdomains. Appendix A.7 explains how ACP This includes all routing subdomains. Appendix A.7 explains how ACP
connections across multiple routing subdomains are special. connections across multiple routing subdomains are special.
skipping to change at page 43, line 44 skipping to change at page 44, line 44
From the use-cases it seems clear that not all type of ACP nodes can From the use-cases it seems clear that not all type of ACP nodes can
or need to connect directly to each other or are able to support or or need to connect directly to each other or are able to support or
prefer all possible mechanisms. For example, code space limited IoT prefer all possible mechanisms. For example, code space limited IoT
devices may only support DTLS because that code exists already on devices may only support DTLS because that code exists already on
them for end-to-end security, but low-end in-ceiling L2 switches may them for end-to-end security, but low-end in-ceiling L2 switches may
only want to support Media Access Control Security (MacSec, see only want to support Media Access Control Security (MacSec, see
802.1AE ([MACSEC]) because that is also supported in their chips. 802.1AE ([MACSEC]) because that is also supported in their chips.
Only a flexible gateway device may need to support both of these Only a flexible gateway device may need to support both of these
mechanisms and potentially more. Note that MacSec is not required by mechanisms and potentially more. Note that MacSec is not required by
any profiles of the ACP in this specification but just mentioned as a any profiles of the ACP in this specification. Instead, MacSec is
likely next interesting secure channel protocol. Note also that the mentioned as a likely next interesting secure channel protocol. Note
security model allows and requires for any-to-any authentication and also that the security model allows and requires for any-to-any
authorization between all ACP nodes because there is also end-to-end authentication and authorization between all ACP nodes because there
and not only hop-by-hop authentication for secure channels. is also end-to-end and not only hop-by-hop authentication for secure
channels.
To support extensible secure channel protocol selection without a To support extensible secure channel protocol selection without a
single common mandatory to implement (MTI) protocol, ACP nodes MUST single common mandatory to implement (MTI) protocol, ACP nodes MUST
try all the ACP secure channel protocols it supports and that are try all the ACP secure channel protocols it supports and that are
feasible because the candidate ACP neighbor also announced them via feasible because the candidate ACP neighbor also announced them via
its AN_ACP GRASP parameters (these are called the "feasible" ACP its AN_ACP GRASP parameters (these are called the "feasible" ACP
secure channel protocols). secure channel protocols).
To ensure that the selection of the secure channel protocols always To ensure that the selection of the secure channel protocols always
succeeds in a predictable fashion without blocking, the following succeeds in a predictable fashion without blocking, the following
rules apply: rules apply:
o An ACP node may choose to attempt to initiate the different o An ACP node may choose to attempt to initiate the different
feasible ACP secure channel protocols it supports according to its feasible ACP secure channel protocols it supports according to its
local policies sequentially or in parallel, but it MUST support local policies sequentially or in parallel, but it MUST support
acting as a responder to all of them in parallel. acting as a responder to all of them in parallel.
o Once the first secure channel protocol succeeds, the two peers o Once the first secure channel protocol succeeds, the two peers
know each other's certificates because they are used by all secure know each other's certificates because they are used by all secure
channel protocols for mutual authentication. The node with the channel protocols for mutual authentication. The node with the
lower Node-ID in the ACP address of its ACP domain certificate lower Node-ID in the ACP address of its ACP certificate becomes
becomes Bob, the one with the higher Node-ID in the certificate Bob, the one with the higher Node-ID in the certificate Alice. A
Alice. A peer with an empty ACP address field in its ACP domain peer with an empty ACP address field in its ACP certificate
certificate becomes Bob (this specification does not define such becomes Bob (this specification does not define such peers, only
peers, only the interoperability with them). the interoperability with them).
o Bob becomes passive, he does not attempt to further initiate ACP o Bob becomes passive, he does not attempt to further initiate ACP
secure channel protocols with Alice and does not consider it to be secure channel protocols with Alice and does not consider it to be
an error when Alice closes secure channels. Alice becomes the an error when Alice closes secure channels. Alice becomes the
active party, continues to attempt setting up secure channel active party, continues to attempt setting up secure channel
protocols with Bob until she arrives at the best one from her view protocols with Bob until she arrives at the best one from her view
that also works with Bob. that also works with Bob.
For example, originally Bob could have been the initiator of one ACP For example, originally Bob could have been the initiator of one ACP
secure channel protocol that Bob prefers and the security association secure channel protocol that Bob prefers and the security association
skipping to change at page 48, line 42 skipping to change at page 49, line 42
of a peer and/or derive a key for the L2 mechanism. Mechanisms to of a peer and/or derive a key for the L2 mechanism. Mechanisms to
auto-discover and associate ACP peers leveraging such underlying L2 auto-discover and associate ACP peers leveraging such underlying L2
security are possible and desirable to avoid duplication of security are possible and desirable to avoid duplication of
encryption, but none are specified in this document. encryption, but none are specified in this document.
Strong physical security of a link may stand in where cryptographic Strong physical security of a link may stand in where cryptographic
security is infeasible. As there is no secure mechanism to security is infeasible. As there is no secure mechanism to
automatically discover strong physical security solely between two automatically discover strong physical security solely between two
peers, it can only be used with explicit configuration and that peers, it can only be used with explicit configuration and that
configuration too could become an attack vector. This document configuration too could become an attack vector. This document
therefore only specifies with ACP connect (Figure 15) one explicitly therefore only specifies with ACP connect (Section 8.1) one
configured mechanism without any secure channel association protocol explicitly configured mechanism without any secure channel
- for the case where both the link and the nodes attached to it have association protocol - for the case where both the link and the nodes
strong physical security. attached to it have strong physical security.
6.7.2. Common requirements 6.7.2. Common requirements
The authentication of peers in any security association protocol MUST The authentication of peers in any security association protocol MUST
use the ACP domain certificate according to Section 6.1.3. Because use the ACP certificate according to Section 6.1.3. Because auto-
auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3) discovery of candidate ACP neighbors via GRASP (see Section 6.3) as
as specified in this document does not communicate the neighbors ACP specified in this document does not communicate the neighbors ACP
domain certificate, and ACP nodes may not (yet) have any other certificate, and ACP nodes may not (yet) have any other network
network connectivity to retrieve certificates, any security connectivity to retrieve certificates, any security association
association protocol MUST use a mechanism to communicate the protocol MUST use a mechanism to communicate the certificate directly
certificate directly instead of relying on a referential mechanism instead of relying on a referential mechanism such as communicating
such as communicating only a hash and/or URL for the certificate. only a hash and/or URL for the certificate.
A security association protocol MUST use Forward Secrecy (whether A security association protocol MUST use Forward Secrecy (whether
inherently or as part of a profile of the security association inherently or as part of a profile of the security association
protocol). protocol).
Because the ACP payload of legacy protocol payloads inside the ACP Because the ACP payload of legacy protocol payloads inside the ACP
and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP
secure channel protocol requires confidentiality. Symmetric secure channel protocol requires confidentiality. Symmetric
encryption for the transmission of secure channel data MUST use encryption for the transmission of secure channel data MUST use
encryption schemes considered to be security wise equal to or better encryption schemes considered to be security wise equal to or better
than AES256. There MUST NOT be support for NULL encryption. than 256 bit key strength, such as AES256. There MUST NOT be support
for NULL encryption.
Security association protocols typically only signal the End Entity Security association protocols typically only signal the End Entity
certificate (e.g.: the ACP domain certificate) and any possible certificate (e.g.: the ACP certificate) and any possible intermediate
intermediate CA certificates for successfull mutual authentication. CA certificates for successful mutual authentication. The TA has to
The TA has to be mutually known and trusted and therefore its be mutually known and trusted and therefore its certificate does not
certificate does not need to be signalled for successful mutual need to be signalled for successful mutual authentication.
authentication. Nevertheless, for use with ACP secure channel setup, Nevertheless, for use with ACP secure channel setup, there SHOULD be
there SHOULD be the option to include the TA certificate in the the option to include the TA certificate in the signaling to aid
signaling to aid troubleshooting, see Section 9.1.1. troubleshooting, see Section 9.1.1.
Signalling of TA certificates may not be appropriate when the Signalling of TA certificates may not be appropriate when the
deployment is relying on a security model where the TA certificate deployment is relying on a security model where the TA certificate
content is considered confidential and only its hash is appropriate content is considered confidential and only its hash is appropriate
for signalling. ACP nodes SHOULD have a mechanism to select whether for signalling. ACP nodes SHOULD have a mechanism to select whether
the TA certificate is signalled or not. Assuming that both options the TA certificate is signalled or not. Assuming that both options
are possible with a specific secure channel protocol. are possible with a specific secure channel protocol.
An ACP secure channel MUST immediately be terminated when the An ACP secure channel MUST immediately be terminated when the
lifetime of any certificate in the chain used to authenticate the lifetime of any certificate in the chain used to authenticate the
neighbor expires or becomes revoked. This may not be standard neighbor expires or becomes revoked. This may not be standard
behavior in secure channel protocols because the certificate behavior in secure channel protocols because the certificate
authentication may only influences the setup of the secure channel in authentication may only influences the setup of the secure channel in
these protocols, but may not be re-validated during the lifetime of these protocols, but may not be re-validated during the lifetime of
the secure connection in the absence of this requirement. the secure connection in the absence of this requirement.
When introducing the profile for a security association protocol in When specifying an additional security association protocol for ACP
support of the ACP, protocol options SHOULD be eliminated that do not secure channels beyond those covered in this document, protocol
provide benefits for devices that should be able to support the ACP. options SHOULD be eliminated that are not necessary to support
For example, definitions for security protocols often include old/ devices that are expected to be able to support the ACP to minimize
inferior security options required only to interoperate with existing implementation complexity. For example, definitions for security
devices that will not be a able to update to the currently preferred protocols often include old/inferior security options required only
security options. Such old/inferior security options do not need to to interoperate with existing devices that will not be a able to
be supported when a security association protocol is first specified update to the currently preferred security options. Such old/
for the ACP, strengthening the "weakest link" and simplifying ACP inferior security options do not need to be supported when a security
implementation overhead. association protocol is first specified for the ACP, strengthening
the "weakest link" and simplifying ACP implementation overhead.
6.7.3. ACP via IPsec 6.7.3. ACP via IPsec
An ACP node announces its ability to support IPsec, negotiated via An ACP node announces its ability to support IPsec, negotiated via
IKEv2, as the ACP secure channel protocol using the "IKEv2" IKEv2, as the ACP secure channel protocol using the "IKEv2"
objective-value in the "AN_ACP" GRASP objective. objective-value in the "AN_ACP" GRASP objective.
The ACP usage of IPsec and IKEv2 mandates a profile with a narrow set The ACP usage of IPsec and IKEv2 mandates a profile with a narrow set
of options of the current standards-track usage guidance for IPsec of options of the current standards-track usage guidance for IPsec
[RFC8221] and IKEv2 [RFC8247]. These option result in stringent [RFC8221] and IKEv2 [RFC8247]. These option result in stringent
skipping to change at page 50, line 47 skipping to change at page 51, line 49
channels, and not only its own generated ACP packets. With IPsec channels, and not only its own generated ACP packets. With IPsec
transport mode (and no additional encapsulation header in the ESP transport mode (and no additional encapsulation header in the ESP
payload), it would only be possible to send packets originated by the payload), it would only be possible to send packets originated by the
ACP node itself because the IPv6 addresses of the ESP must be the ACP node itself because the IPv6 addresses of the ESP must be the
same as that of the outer IPv6 header. same as that of the outer IPv6 header.
6.7.3.1.1. RFC8221 (IPsec/ESP) 6.7.3.1.1. RFC8221 (IPsec/ESP)
ACP IPsec implementations MUST comply with [RFC8221] (and its ACP IPsec implementations MUST comply with [RFC8221] (and its
updates). The requirements from above and this section amend and updates). The requirements from above and this section amend and
superceed its requirements. superseded its requirements.
AH MUST NOT be used (because it does not provide confidentiality). AH MUST NOT be used (because it does not provide confidentiality).
For the required ESP encryption algorithms in section 5 of [RFC8221] For the required ESP encryption algorithms in section 5 of [RFC8221]
the following guidance applies: the following guidance applies:
o ENCR_NULL AH MUST NOT be used (because it does not provide o ENCR_NULL AH MUST NOT be used (because it does not provide
confidentiality). confidentiality).
o ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP o ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP
skipping to change at page 52, line 27 skipping to change at page 53, line 27
implement ciphers, integrity checks, pseudo-random-functions and implement ciphers, integrity checks, pseudo-random-functions and
Diffie-Hellman mechanisms. Those recommendations, and the Diffie-Hellman mechanisms. Those recommendations, and the
recommendations of subsequent documents apply well to the ACP. recommendations of subsequent documents apply well to the ACP.
Because IKEv2 for ACP secure channels is sufficient to be implemented Because IKEv2 for ACP secure channels is sufficient to be implemented
in control plane software, rather than in ASIC hardware, and ACP in control plane software, rather than in ASIC hardware, and ACP
nodes supporting IKEv2 are not assumed to be code-space constrained, nodes supporting IKEv2 are not assumed to be code-space constrained,
and because existing IKEv2 implementations are expected to support and because existing IKEv2 implementations are expected to support
[RFC8247] recommendations, this documents makes no attempt to [RFC8247] recommendations, this documents makes no attempt to
simplify its recommendations for use with the ACP. simplify its recommendations for use with the ACP.
This document does establish a policy statement as permitted by
[RFC8247] for the specific case of ACP traffic.
See [IKEV2IANA] for IANA IKEv2 parameter names used in this text. See [IKEV2IANA] for IANA IKEv2 parameter names used in this text.
To signal the ACP domain certificate chain (including TA) as required ACP Nodes supporting IKEv2 MUST comply with [RFC8247] amended by the
by Section 6.7.2, "X.509 Certificate - Signature" payload in IKEv2 following requirements which constitute a policy statement as
can be used. It is mandatory according to [RFC7296] section 3.6. permitted by [RFC8247].
To signal the ACP certificate chain (including TA) as required by
Section 6.7.2, "X.509 Certificate - Signature" payload in IKEv2 can
be used. It is mandatory according to [RFC7296] section 3.6.
ACP nodes SHOULD set up IKEv2 to only use the ACP certificate and TA ACP nodes SHOULD set up IKEv2 to only use the ACP certificate and TA
when acting as an IKEv2 responder on the IPv6 link local address and when acting as an IKEv2 responder on the IPv6 link local address and
port number indicated in the AN_ACP DULL GRASP announcements (see port number indicated in the AN_ACP DULL GRASP announcements (see
Section 6.3). Section 6.3).
When CERTREQ is received from a peer, and does not indicate any of When CERTREQ is received from a peer, and does not indicate any of
this ACP nodes TA certificates, the ACP node SHOULD ignore the this ACP nodes TA certificates, the ACP node SHOULD ignore the
CERTREQ and continue sending its certificate chain including its TA CERTREQ and continue sending its certificate chain including its TA
as subject to the requirements and explanations in Section 6.7.2. as subject to the requirements and explanations in Section 6.7.2.
This will not result in successfull mutual authentication but assists This will not result in successful mutual authentication but assists
diagnostics. diagnostics.
Note that with IKEv2, failing authentication will only result in the Note that with IKEv2, failing authentication will only result in the
responder receiving the certificate chain from the initiator, but not responder receiving the certificate chain from the initiator, but not
vice versa. Because ACP secure channel setup is symmetric (see vice versa. Because ACP secure channel setup is symmetric (see
Section 6.6), every non-malicious ACP neighbor will attempt to Section 6.6), every non-malicious ACP neighbor will attempt to
connect as an initiator though, allowing to obtain the diagnostic connect as an initiator though, allowing to obtain the diagnostic
information about the neighbors certificate. information about the neighbors certificate.
In IKEv2, ACP nodes are identified by their ACP address. The In IKEv2, ACP nodes are identified by their ACP address. The
ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST
convey the ACP address. If the peer's ACP domain certificate convey the ACP address. If the peer's ACP certificate includes a
includes an ACP address in the acp-node-name (not "0" or empty), the 32HEXLC ACP address in the acp-node-name (not "0" or empty), the
address in the IKEv2 identification payload MUST match it. See address in the IKEv2 identification payload MUST match it. See
Section 6.1.3 for more information about "0" or empty ACP address Section 6.1.3 for more information about "0" or empty ACP address
fields in the acp-node-name. fields in the acp-node-name.
IKEv2 authentication MUST use authentication method 14 ("Digital IKEv2 authentication MUST use authentication method 14 ("Digital
Signature") for ACP certificates; this authentication method can be Signature") for ACP certificates; this authentication method can be
used with both RSA and ECDSA certificates, indicated by an ASN.1 used with both RSA and ECDSA certificates, indicated by an ASN.1
object AlgorithmIdentifier. object AlgorithmIdentifier.
The Digital Signature hash SHA2-512 MUST be supported (in addition to The Digital Signature hash SHA2-512 MUST be supported (in addition to
skipping to change at page 58, line 7 skipping to change at page 59, line 7
GRASP link-local multicast messages are targeted for a specific ACP GRASP link-local multicast messages are targeted for a specific ACP
virtual interface (as defined Section 6.12.5) but are sent by the ACP virtual interface (as defined Section 6.12.5) but are sent by the ACP
into an ACP GRASP virtual interface that is constructed from the TCP into an ACP GRASP virtual interface that is constructed from the TCP
connection(s) to the IPv6 link-local neighbor address(es) on the connection(s) to the IPv6 link-local neighbor address(es) on the
underlying ACP virtual interface. If the ACP GRASP virtual interface underlying ACP virtual interface. If the ACP GRASP virtual interface
has two or more neighbors, the GRASP link-local multicast messages has two or more neighbors, the GRASP link-local multicast messages
are replicated to all neighbor TCP connections. are replicated to all neighbor TCP connections.
TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options
with less than 256bit AES or less than SHA384. TLS for GRASP MUST with less than 256 bit symmetric key strength or hash strength of
also include the "Supported Elliptic Curves" extension, it MUST less han SHA384. TLS for GRASP MUST also include the "Supported
support support the NIST P-256 (secp256r1) and P-384 (secp384r1(24)) Elliptic Curves" extension, it MUST support support the NIST P-256
curves [RFC4492]. In addition, GRASP TLS clients SHOULD send an (secp256r1) and P-384 (secp384r1(24)) curves [RFC4492]. In addition,
ec_point_formats extension with a single element, "uncompressed". GRASP TLS clients SHOULD send an ec_point_formats extension with a
For further interoperability recommendations, GRASP TLS single element, "uncompressed". For further interoperability
implementations SHOULD follow [RFC7525]. recommendations, GRASP TLS implementations SHOULD follow [RFC7525].
TCP and TLS connections for GRASP in the ACP use the IANA assigned TCP and TLS connections for GRASP in the ACP use the IANA assigned
TCP port for GRASP (7107). Effectively the transport stack is TCP port for GRASP (7107). Effectively the transport stack is
expected to be TLS for connections from/to the ACP address (e.g., expected to be TLS for connections from/to the ACP address (e.g.,
global scope address(es)) and TCP for connections from/to link-local global scope address(es)) and TCP for connections from/to link-local
addresses on the ACP virtual interfaces. The latter ones are only addresses on the ACP virtual interfaces. The latter ones are only
used for flooding of GRASP messages. used for flooding of GRASP messages.
..............................ACP.............................. ..............................ACP..............................
. . . .
skipping to change at page 63, line 34 skipping to change at page 64, line 34
+--+-------------------------+------+------------------------------+ +--+-------------------------+------+------------------------------+
Figure 9: ACP Addressing Base Scheme Figure 9: ACP Addressing Base Scheme
The first 48-bits follow the ULA scheme, as defined in [RFC4193], to The first 48-bits follow the ULA scheme, as defined in [RFC4193], to
which a type field is added: which a type field is added:
o "fd" identifies a locally defined ULA address. o "fd" identifies a locally defined ULA address.
o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP
addresses carried in the acp-node-name in the ACP domain addresses carried in the acp-node-name in the ACP certificates are
certificates are the first 40-bits of the SHA256 hash of the the first 40-bits of the SHA256 hash of the routing subdomain from
routing subdomain from the same acp-node-name. In the example of the same acp-node-name. In the example of Section 6.1.2, the
Section 6.1.2, the routing subdomain is routing subdomain is "area51.research.acp.example.com" and the
"area51.research.acp.example.com" and the 40-bits ULA "global ID" 40-bits ULA "global ID" 89b714f3db.
89b714f3db.
o When creating a new routing-subdomain for an existing autonomic o When creating a new routing-subdomain for an existing autonomic
network, it MUST be ensured, that rsub is selected so the network, it MUST be ensured, that rsub is selected so the
resulting hash of the routing-subdomain does not collide with the resulting hash of the routing-subdomain does not collide with the
hash of any pre-existing routing-subdomains of the autonomic hash of any pre-existing routing-subdomains of the autonomic
network. This ensures that ACP addresses created by registrars network. This ensures that ACP addresses created by registrars
for different routing subdomains do not collide with each others. for different routing subdomains do not collide with each others.
o To allow for extensibility, the fact that the ULA "global ID" is a o To allow for extensibility, the fact that the ULA "global ID" is a
hash of the routing subdomain SHOULD NOT be assumed by any ACP hash of the routing subdomain SHOULD NOT be assumed by any ACP
skipping to change at page 67, line 20 skipping to change at page 68, line 20
today with pre-existing, non-autonomic mechanisms. Every subnet that today with pre-existing, non-autonomic mechanisms. Every subnet that
uses this addressing sub-scheme needs to use a unique Subnet-ID uses this addressing sub-scheme needs to use a unique Subnet-ID
(unless some anycast setup is done). (unless some anycast setup is done).
The Z bit field was added to distinguish Zone addressing and manual The Z bit field was added to distinguish Zone addressing and manual
addressing sub-schemes without requiring one more bit in the base addressing sub-schemes without requiring one more bit in the base
scheme and therefore allowing for the Vlong scheme (described below) scheme and therefore allowing for the Vlong scheme (described below)
to have one more bit available. to have one more bit available.
Manual addressing sub-scheme addresses SHOULD NOT be used in ACP Manual addressing sub-scheme addresses SHOULD NOT be used in ACP
domain certificates. Any node capable to build ACP secure channels certificates. Any node capable to build ACP secure channels and
and permitted by Registrar policy to participate in building ACP permitted by Registrar policy to participate in building ACP secure
secure channels SHOULD receive an ACP address (prefix) from one of channels SHOULD receive an ACP address (prefix) from one of the other
the other ACP addressing sub-schemes. Nodes not capable (or ACP addressing sub-schemes. Nodes not capable (or permitted) to
permitted) to participate in ACP secure channels can connect to the participate in ACP secure channels can connect to the ACP via ACP
ACP via ACP connect interfaces of ACP edge nodes (see Section 8.1), connect interfaces of ACP edge nodes (see Section 8.1), without
without setting up an ACP secure channel. Their ACP domain setting up an ACP secure channel. Their ACP certificate MUST include
certificate MUST include an empty acp-address to indicate that their an empty acp-address to indicate that their ACP certificate is only
ACP domain certificate is only usable for non- ACP secure channel usable for non- ACP secure channel authentication, such as end-to-end
authentication, such as end-to-end transport connections across the transport connections across the ACP or Data-Plane.
ACP or Data-Plane.
Address management of ACP connect subnets is done using traditional Address management of ACP connect subnets is done using traditional
assignment methods and existing IPv6 protocols. See Section 8.1.3 assignment methods and existing IPv6 protocols. See Section 8.1.3
for details. for details.
6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16 6.10.5. ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16
This sub-scheme is used when the Type field of the base scheme is This sub-scheme is used when the Type field of the base scheme is
0x01. 0x01.
skipping to change at page 69, line 18 skipping to change at page 70, line 17
registrar-ID field in the address. registrar-ID field in the address.
IANA is asked need to assign a new "type" for each new addressing IANA is asked need to assign a new "type" for each new addressing
sub-scheme. With the current allocations, only 2 more schemes are sub-scheme. With the current allocations, only 2 more schemes are
possible, so the last addressing scheme MUST provide further possible, so the last addressing scheme MUST provide further
extensions (e.g., by reserving bits from it for further extensions). extensions (e.g., by reserving bits from it for further extensions).
6.10.7. ACP Registrars 6.10.7. ACP Registrars
ACP registrars are responsible to enroll candidate ACP nodes with ACP ACP registrars are responsible to enroll candidate ACP nodes with ACP
domain certificates and associated trust point(s). They are also certificates and associated trust anchor(s). They are also
responsible that an acp-node-name field is included in the ACP domain responsible that an acp-node-name field is included in the ACP
certificate carrying the ACP domain name and the ACP nodes ACP certificate carrying the ACP domain name and the ACP nodes ACP
address prefix. This address prefix is intended to persist unchanged address prefix. This address prefix is intended to persist unchanged
through the lifetime of the ACP node. through the lifetime of the ACP node.
Because of the ACP addressing sub-schemes, an ACP domain can have Because of the ACP addressing sub-schemes, an ACP domain can have
multiple distributed ACP registrars that do not need to coordinate multiple distributed ACP registrars that do not need to coordinate
for address assignment. ACP registrars can also be sub-CAs, in which for address assignment. ACP registrars can also be sub-CAs, in which
case they can also assign ACP domain certificates without case they can also assign ACP certificates without dependencies
dependencies against a (shared) TA (except during renewals of their against a (shared) TA (except during renewals of their own
own certificates). certificates).
ACP registrars are PKI registration authorities (RA) enhanced with ACP registrars are PKI registration authorities (RA) enhanced with
the handling of the ACP domain certificate specific fields. They the handling of the ACP certificate specific fields. They request
request certificates for ACP nodes from a Certification Authority certificates for ACP nodes from a Certification Authority through any
through any appropriate mechanism (out of scope in this document, but appropriate mechanism (out of scope in this document, but required to
required to be BRSKI for ANI registrars). Only nodes that are be BRSKI for ANI registrars). Only nodes that are trusted to be
trusted to be compliant with the requirements against registrar compliant with the requirements against registrar described in this
described in this section can be given the necessary credentials to section can be given the necessary credentials to perform this RA
perform this RA function, such as credentials for the BRSKI function, such as credentials for the BRSKI connection to the CA for
connection to the CA for ANI registrars. ANI registrars.
6.10.7.1. Use of BRSKI or other Mechanism/Protocols 6.10.7.1. Use of BRSKI or other Mechanism/Protocols
Any protocols or mechanisms may be used as ACP registrars, as long as Any protocols or mechanisms may be used as ACP registrars, as long as
the resulting ACP certificate and TA certificate(s) allow to perform the resulting ACP certificate and TA certificate(s) allow to perform
the ACP domain membership described in Section 6.1.3 with other ACP the ACP domain membership described in Section 6.1.3 with other ACP
domain members, and meet the ACP addressing requirements for its acp- domain members, and meet the ACP addressing requirements for its acp-
node-name as described further below in this section. node-name as described further below in this section.
An ACP registrar could be a person deciding whether to enroll a An ACP registrar could be a person deciding whether to enroll a
candidate ACP node and then orchestrating the enrollment of the ACP candidate ACP node and then orchestrating the enrollment of the ACP
certificate and associated TA, using command line or web based certificate and associated TA, using command line or web based
commands on the candidate ACP node and TA to generate and sign the commands on the candidate ACP node and TA to generate and sign the
ACP domain certificate and configure certificate and TA onto the ACP certificate and configure certificate and TA onto the node.
node.
The only currently defined protocol for ACP registrars is BRSKI The only currently defined protocol for ACP registrars is BRSKI
([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the ([I-D.ietf-anima-bootstrapping-keyinfra]). When BRSKI is used, the
ACP nodes are called ANI nodes, and the ACP registrars are called ACP nodes are called ANI nodes, and the ACP registrars are called
BRSKI or ANI registrars. The BRSKI specification does not define the BRSKI or ANI registrars. The BRSKI specification does not define the
handling of the acp-node-name field because the rules do not depend handling of the acp-node-name field because the rules do not depend
on BRSKI but apply equally to any protocols/mechanisms an ACP on BRSKI but apply equally to any protocols/mechanisms an ACP
registrar may use. registrar may use.
6.10.7.2. Unique Address/Prefix allocation 6.10.7.2. Unique Address/Prefix allocation
skipping to change at page 71, line 14 skipping to change at page 72, line 14
[RFC Editor: please update reference to section 5.9.2 accordingly [RFC Editor: please update reference to section 5.9.2 accordingly
with latest BRSKI draft at time of publishing, or RFC] with latest BRSKI draft at time of publishing, or RFC]
6.10.7.3. Addressing Sub-Scheme Policies 6.10.7.3. Addressing Sub-Scheme Policies
The ACP registrar selects for the candidate ACP node a unique address The ACP registrar selects for the candidate ACP node a unique address
prefix from an appropriate ACP addressing sub-scheme, either a zone prefix from an appropriate ACP addressing sub-scheme, either a zone
addressing sub-scheme prefix (see Section 6.10.3), or a Vlong addressing sub-scheme prefix (see Section 6.10.3), or a Vlong
addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP
address prefix encoded in the acp-node-name field of the ACP domain address prefix encoded in the acp-node-name field of the ACP
certificate indicates to the ACP node its ACP address information. certificate indicates to the ACP node its ACP address information.
The sub-addressing scheme indicates the prefix length: /127 for zone The sub-addressing scheme indicates the prefix length: /127 for zone
address sub-scheme, /120 or /112 for Vlong address sub-scheme. The address sub-scheme, /120 or /112 for Vlong address sub-scheme. The
first address of the prefix is the ACP address. All other addresses first address of the prefix is the ACP address. All other addresses
in the prefix are for other uses by the ACP node as described in the in the prefix are for other uses by the ACP node as described in the
zone and Vlong addressing sub scheme sections. The ACP address zone and Vlong addressing sub scheme sections. The ACP address
prefix itself is then signaled by the ACP node into the ACP routing prefix itself is then signaled by the ACP node into the ACP routing
protocol (see Section 6.11) to establish IPv6 reachability across the protocol (see Section 6.11) to establish IPv6 reachability across the
ACP. ACP.
skipping to change at page 71, line 37 skipping to change at page 72, line 37
an ACP domain wide policy, or a per ACP node or per ACP node type an ACP domain wide policy, or a per ACP node or per ACP node type
policy. For example, in BRSKI, the ACP registrar is aware of the policy. For example, in BRSKI, the ACP registrar is aware of the
IDevID certificate of the candidate ACP node, which contains a IDevID certificate of the candidate ACP node, which contains a
"serialNnumber" that is typically indicating the node's vendor and "serialNnumber" that is typically indicating the node's vendor and
device type and can be used to drive a policy selecting an device type and can be used to drive a policy selecting an
appropriate addressing sub-scheme for the (class of) node(s). appropriate addressing sub-scheme for the (class of) node(s).
ACP registrars SHOULD default to allocate ACP zone sub-address scheme ACP registrars SHOULD default to allocate ACP zone sub-address scheme
addresses with Zone-ID 0. addresses with Zone-ID 0.
ACP registrars that are aware of can use the IDevID certificate of a ACP registrars that are aware of the IDevID certificate of a
candidate ACP device SHOULD be able to choose the zone vs. Vlong sub- candidate ACP device SHOULD be able to choose the zone vs. Vlong sub-
address scheme for ACP nodes based on the "serialNumber" of the address scheme for ACP nodes based on the "serialNumber" of the
IDevID certificate, for example by the PID (Product Identifier) part IDevID certificate, for example by the PID (Product Identifier) part
which identifies the product type, or the complete "serialNumber". which identifies the product type, or the complete "serialNumber".
The PID for example could identify nodes that allow for specialized
ASA requiring multiple addresses or non-autonomic VMs for services
and those nodes could receive Vlong sub-address scheme ACP addresses.
In a simple allocation scheme, an ACP registrar remembers In a simple allocation scheme, an ACP registrar remembers
persistently across reboots its currently used Registrar-ID and for persistently across reboots its currently used Registrar-ID and for
each addressing scheme (Zone with Zone-ID 0, Vlong with /112, Vlong each addressing scheme (Zone with Zone-ID 0, Vlong with /112, Vlong
with /120), the next Node-Number available for allocation and with /120), the next Node-Number available for allocation and
increases it during successful enrollment to an ACP node. In this increases it during successful enrollment to an ACP node. In this
simple allocation scheme, the ACP registrar would not recycle ACP simple allocation scheme, the ACP registrar would not recycle ACP
address prefixes from no longer used ACP nodes. address prefixes from no longer used ACP nodes.
If allocated addresses can not be remembered by registrars, then it
is necessary to either use a new value for the Register-ID field in
the ACP addresses, or determine allocated ACP addresses from
determining the addresses of reachable ACP nodes, which is not
necessarily the set of all ACP nodes. Non-tracked ACP addresses can
be reclaimed by revoking or not renewing their certificates and
instead handing out new certificate with new addresses (for example
with a new Registrar-ID value). Note that such strategies may
require coordination amongst registrars.
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 certificate is renewed or rekeyed via EST or other
mechanisms, the ACP address/prefix in the acp-node-name field MUST be mechanisms, the ACP address/prefix in the acp-node-name field MUST be
maintained unless security issues or violations of the unique address maintained unless security issues or violations of the unique address
assignment requirements exist or are suspected by the ACP registrar. assignment requirements exist or are suspected by the ACP registrar.
ACP address information SHOULD be maintained even when the renewing/ ACP address information SHOULD be maintained even when the renewing/
rekeying ACP registrar is not the same as the one that enrolled the rekeying ACP registrar is not the same as the one that enrolled the
prior ACP certificate. See Section 9.2.4 for an example. prior ACP certificate. See Section 9.2.4 for an example.
ACP address information SHOULD also be maintained even after an ACP ACP address information SHOULD also be maintained even after an ACP
certificate did expire or failed. See Section 6.1.5.5 and certificate did expire or failed. See Section 6.1.5.5 and
skipping to change at page 73, line 9 skipping to change at page 74, line 20
Appendix A.4 for more details on the choice of RPL. Appendix A.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 Appendix A.7 for more including all its routing subdomains. See Appendix A.7 for more
details. details.
6.11.1. ACP RPL Profile 6.11.1. ACP 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. [I-D.ietf-roll-applicability-template].
6.11.1.1. Overview 6.11.1.1. Overview
RPL Packet Information (RPI) defined in [RFC6550], section 11.2 RPL Packet Information (RPI) defined in [RFC6550], section 11.2
defines the data packet artefacts required or beneficial in defines the data packet artefacts required or beneficial in
forwarding of packets routed by RPL. This profile does not use RPI forwarding of packets routed by RPL. This profile does not use RPI
for better compatibility with accelerated hardware forwarding planes for better compatibility with accelerated hardware forwarding planes
which most often does not support the Hop-by-Hop headers used for which most often does not support the Hop-by-Hop headers used for
RPI, but also to avoid the overhead of the RPI header on the wire and RPI, but also to avoid the overhead of the RPI header on the wire and
cost of adding/removing them. cost of adding/removing them.
skipping to change at page 74, line 24 skipping to change at page 75, line 36
The ACP RPL profile instead relies on quick reconverging the DODAG by The ACP RPL profile instead relies on quick reconverging the DODAG by
recognizing link state change (down/up) and triggering reconvergence recognizing link state change (down/up) and triggering reconvergence
signaling as described in Section 6.11.1.7. Since links in the ACP signaling as described in Section 6.11.1.7. Since links in the ACP
are assumed to be mostly reliable (or have link layer protection are assumed to be mostly reliable (or have link layer protection
against loss) and because there is no stretch according to against loss) and because there is no stretch according to
Section 6.11.1.7, loops caused by loss of RPL routing protocol Section 6.11.1.7, loops caused by loss of RPL routing protocol
signaling packets should be exceedingly rare. signaling packets should be exceedingly rare.
In addition, there are a variety of mechanisms possible in RPL to In addition, there are a variety of mechanisms possible in RPL to
further avoid temporary loops RECOMMENDED to be used for the ACPL RPL further avoid temporary loops RECOMMENDED to be used for the ACPL RPL
profile: DODAG Information Objects (DIOs) SHOULD be sent 2...3 times profile: DODAG Information Objects (DIOs) SHOULD be sent 2 or 3 times
to inform children when losing the last parent. The technique in to inform children when losing the last parent. The technique in
[RFC6550] section 8.2.2.6. (Detaching) SHOULD be favored over that [RFC6550] section 8.2.2.6. (Detaching) SHOULD be favored over that
in section 8.2.2.5., (Poisoning) because it allows local in section 8.2.2.5., (Poisoning) because it allows local
connectivity. Nodes SHOULD select more than one parent, at least 3 connectivity. Nodes SHOULD select more than one parent, at least 3
if possible, and send Destination Advertisement Objects (DAO)s to all if possible, and send Destination Advertisement Objects (DAO)s to all
of them in parallel. of them in parallel.
Additionally, failed ACP tunnels can be quickly discovered trough the Additionally, failed ACP tunnels can be quickly discovered trough the
secure channel protocol mechanisms such as IKEv2 Dead Peer Detection. secure channel protocol mechanisms such as IKEv2 Dead Peer Detection.
This can function as a replacement for a Low-power and Lossy This can function as a replacement for a Low-power and Lossy
skipping to change at page 75, line 17 skipping to change at page 76, line 28
Proactive, aggressive DAO state maintenance: Proactive, aggressive DAO state maintenance:
o Use K-flag in unsolicited DAO indicating change from previous o Use K-flag in unsolicited DAO indicating change from previous
information (to require DAO-ACK). information (to require DAO-ACK).
o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms) o Retry such DAO DAO-RETRIES(3) times with DAO- ACK_TIME_OUT(256ms)
in between. in between.
6.11.1.5. Path Metric 6.11.1.5. Path Metric
Hopcount. Use Hopcount according to [RFC6551]. Note that this is solely for
diagnostic purposes as it is not used by the objective function.
6.11.1.6. Objective Function 6.11.1.6. Objective Function
Objective Function (OF): Use OF0 [RFC6552]. No use of metric Objective Function (OF): Use OF0 [RFC6552]. No use of metric
containers. containers.
rank_factor: Derived from link speed: <= 100Mbps: rank_factor: Derived from link speed: <= 100Mbps:
LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1)
This is a simple rank differentiation between typical "low speed" or This is a simple rank differentiation between typical "low speed" or
skipping to change at page 75, line 47 skipping to change at page 77, line 12
to periodically rebuild DODAG. DODAG version only incremented under to periodically rebuild DODAG. DODAG version only incremented under
catastrophic events (e.g., administrative action). catastrophic events (e.g., administrative action).
Local Repair: As soon as link breakage is detected, send No-Path DAO Local Repair: As soon as link breakage is detected, send No-Path DAO
for all the targets that were reachable only via this link. As soon for all the targets that were reachable only via this link. As soon
as link repair is detected, validate if this link provides you a as link repair is detected, validate if this link provides you a
better parent. If so, compute your new rank, and send new DIO that better parent. If so, compute your new rank, and send new DIO that
advertises your new rank. Then send a DAO with a new path sequence advertises your new rank. Then send a DAO with a new path sequence
about yourself. about yourself.
When using ACP multi-access virtual interfaces, local repair can be
directly by peer breakage, see Section 6.12.5.2.2.
stretch_rank: none provided ("not stretched"). stretch_rank: none provided ("not stretched").
Data Path Validation: Not used. Data Path Validation: Not used.
Trickle: Not used. Trickle: Not used.
6.11.1.8. Multicast 6.11.1.8. Multicast
Not used yet but possible because of the selected mode of operations. Not used yet but possible because of the selected mode of operations.
skipping to change at page 82, line 7 skipping to change at page 83, line 25
easy to add). easy to add).
6.12.5.2.1. ACP point-to-point virtual interfaces 6.12.5.2.1. ACP point-to-point virtual interfaces
In this option, each ACP secure channel is mapped into a separate In this option, each ACP secure channel is mapped into a separate
point-to-point ACP virtual interface. If a physical subnet has more point-to-point ACP virtual interface. If a physical subnet has more
than two ACP capable nodes (in the same domain), this implementation than two ACP capable nodes (in the same domain), this implementation
approach will lead to a full mesh of ACP virtual interfaces between approach will lead to a full mesh of ACP virtual interfaces between
them. them.
When the secure channel protocol determines a peer to be dead, this
SHOULD result in indicating link breakage to trigger RPL DODAG
repair, see Section 6.11.1.7.
6.12.5.2.2. ACP multi-access virtual interfaces 6.12.5.2.2. ACP multi-access virtual interfaces
In a more advanced implementation approach, the ACP will construct a In a more advanced implementation approach, the ACP will construct a
single multi-access ACP virtual interface for all ACP secure channels single multi-access ACP virtual interface for all ACP secure channels
to ACP capable nodes reachable across the same underlying (physical) to ACP capable nodes reachable across the same underlying (physical)
subnet. IPv6 link-local multicast packets sent into an ACP multi- subnet. IPv6 link-local multicast packets sent into an ACP multi-
access virtual interface are replicated to every ACP secure channel access virtual interface are replicated to every ACP secure channel
mapped into the ACP multicast-access virtual interface. IPv6 unicast mapped into the ACP multicast-access virtual interface. IPv6 unicast
packets sent into an ACP multi-access virtual interface are sent to packets sent into an ACP multi-access virtual interface are sent to
the ACP secure channel that belongs to the ACP neighbor that is the the ACP secure channel that belongs to the ACP neighbor that is the
next-hop in the ACP forwarding table entry used to reach the packets next-hop in the ACP forwarding table entry used to reach the packets
destination address. destination address.
When the secure channel protocol determines a peer to be dead for a
secure channel mapped into an ACP multi-access virtual interface,
this SHOULD result in signaling breakage of that peer to RPL, so it
can trigger RPL DODAG repair, see Section 6.11.1.7.
There is no requirement for all ACP nodes on the same multi-access There is no requirement for all ACP nodes on the same multi-access
subnet to use the same type of ACP virtual interface. This is purely subnet to use the same type of ACP virtual interface. This is purely
a node local decision. a node local decision.
ACP nodes MUST perform standard IPv6 operations across ACP virtual ACP nodes MUST perform standard IPv6 operations across ACP virtual
interfaces including SLAAC (Stateless Address Auto-Configuration) - interfaces including SLAAC (Stateless Address Auto-Configuration) -
[RFC4862]) to assign their IPv6 link local address on the ACP virtual [RFC4862]) to assign their IPv6 link local address on the ACP virtual
interface and ND (Neighbor Discovery - [RFC4861]) to discover which interface and ND (Neighbor Discovery - [RFC4861]) to discover which
IPv6 link-local neighbor address belongs to which ACP secure channel IPv6 link-local neighbor address belongs to which ACP secure channel
mapped to the ACP virtual interface. This is independent of whether mapped to the ACP virtual interface. This is independent of whether
the ACP virtual interface is point-to-point or multi-access. the ACP virtual interface is point-to-point or multi-access.
"Optimistic Duplicate Address Detection (DAD)" according to [RFC4429] "Optimistic Duplicate Address Detection (DAD)" according to [RFC4429]
is RECOMMENDED because the likelihood for duplicates between ACP is RECOMMENDED because the likelihood for duplicates between ACP
nodes is highly improbable as long as the address can be formed from nodes is highly improbable as long as the address can be formed from
a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see a globally unique local assigned identifier (e.g., EUI-48/EUI-64, see
skipping to change at page 88, line 34 skipping to change at page 90, line 9
ACP connect has security consequences: All systems and processes ACP connect has security consequences: All systems and processes
connected via ACP connect have access to all ACP nodes on the entire connected via ACP connect have access to all ACP nodes on the entire
ACP, without further authentication. Thus, the ACP connect interface ACP, without further authentication. Thus, the ACP connect interface
and NOC systems connected to it needs to be physically controlled/ and NOC systems connected to it needs to be physically controlled/
secured. For this reason the mechanisms described here do explicitly secured. For this reason the mechanisms described here do explicitly
not include options to allow for a non-ACP router to be connected not include options to allow for a non-ACP router to be connected
across an ACP connect interface and addresses behind such a router across an ACP connect interface and addresses behind such a router
routed inside the ACP. routed inside the ACP.
Physical controlled/secured means that attackers can gain no access
to the physical device hosting the ACP Edge Node, the physical
interfaces and links providing the ACP connect link nor the physical
devices hosting the NOC Device. In a simple case, ACP Edge node and
NOC Device are co-located in an access controlled room, such as a
NOC, to which attackers can not gain physical access.
An ACP connect interface provides exclusively access to only the ACP. An ACP connect interface provides exclusively access to only the ACP.
This is likely insufficient for many NMS hosts. Instead, they would This is likely insufficient for many NMS hosts. Instead, they would
require a second "Data-Plane" interface outside the ACP for require a second "Data-Plane" interface outside the ACP for
connections between the NMS host and administrators, or Internet connections between the NMS host and administrators, or Internet
based services, or for direct access to the Data-Plane. The document based services, or for direct access to the Data-Plane. The document
"Using Autonomic Control Plane for Stable Connectivity of Network "Using Autonomic Control Plane for Stable Connectivity of Network
OAM" [RFC8368] explains in more detail how the ACP can be integrated OAM" [RFC8368] explains in more detail how the ACP can be integrated
in a mixed NOC environment. in a mixed NOC environment.
An ACP connect interface SHOULD use an IPv6 address/prefix from the An ACP connect interface SHOULD use an IPv6 address/prefix from the
skipping to change at page 93, line 14 skipping to change at page 94, line 46
8.1.5. Use of GRASP 8.1.5. Use of GRASP
GRASP can and should be possible to use across ACP connect GRASP can and should be possible to use across ACP connect
interfaces, especially in the architectural correct solution when it interfaces, especially in the architectural correct solution when it
is used as a mechanism to connect Software (e.g., ASA or legacy NMS is used as a mechanism to connect Software (e.g., ASA or legacy NMS
applications) to the ACP. applications) to the ACP.
Given how the ACP is the security and transport substrate for GRASP, Given how the ACP is the security and transport substrate for GRASP,
the requirements for devices connected via ACP connect is that those the requirements for devices connected via ACP connect is that those
are equivalently (if not better) secured against attacks and run only are equivalently (if not better) secured against attacks than ACP
software that is equally (if not better) protected, known (or nodes that do not use ACP connect and run only software that is
trusted) not to be malicious and accordingly designed to isolate equally (if not better) protected, known (or trusted) not to be
access to the ACP against external equipment. malicious and accordingly designed to isolate access to the ACP
against external equipment.
The difference in security is that cryptographic security of the ACP The difference in security is that cryptographic security of the ACP
secure channel is replaced by required physical security of the secure channel is replaced by required physical security/control of
network connection between an ACP edge node and the NMS or other host the network connection between an ACP edge node and the NMS or other
reachable via the ACP connect interface. Node integrity too is host reachable via the ACP connect interface. See Section 8.1.1.
expected to be easier because the ACP connect node, the ACP connect
link and the nodes connecting to it must be in a contiguous secure
environment, hence assuming there can be no physical attack against
the devices.
When using "Combined ACP and Data-Plane Interfaces", care hasa to be When using "Combined ACP and Data-Plane Interfaces", care hasa to be
taken that only GRASP messages intended for the ACP GRASP domain taken that only GRASP messages intended for the ACP GRASP domain
received from Software or NMS Hosts are forwarded by ACP edge nodes. received from Software or NMS Hosts are forwarded by ACP edge nodes.
Currently there is no definition for a GRASP security and transport Currently there is no definition for a GRASP security and transport
substrate beside the ACP, so there is no definition how such substrate beside the ACP, so there is no definition how such
Software/NMS Host could participate in two separate GRASP Domains Software/NMS Host could participate in two separate GRASP Domains
across the same subnet (ACP and Data-Plane domains). At current it across the same subnet (ACP and Data-Plane domains). At current it
is assumed that all GRASP packets on a Combined ACP and Data-Plane is assumed that all GRASP packets on a Combined ACP and Data-Plane
interface belong to the GRASP ACP Domain. They SHOULD all use the interface belong to the GRASP ACP Domain. They SHOULD all use the
skipping to change at page 94, line 12 skipping to change at page 95, line 41
not sufficient to autonomically create ACP connections across non-ACP not sufficient to autonomically create ACP connections across non-ACP
Layer-3 devices. Layer-3 devices.
8.2.1. Configured Remote ACP neighbor 8.2.1. Configured Remote ACP neighbor
On the ACP node, remote ACP neighbors are configured explicitly. The On the ACP node, remote ACP neighbors are configured explicitly. The
parameters of such a "connection" are described in the following parameters of such a "connection" are described in the following
ABNF. ABNF.
connection = [ method , local-addr, remote-addr, ?pmtu ] connection = [ method , local-addr, remote-addr, ?pmtu ]
method = [ "IKEv2" , ?port ] method = [ "IKEv2" , ?port ]
method //= [ "DTLS", port ] method =/ [ "DTLS", port ]
local-addr = [ address , ?vrf ] local-addr = [ address , ?vrf ]
remote-addr = [ address ] remote-addr = [ address ]
address = ("any" | ipv4-address | ipv6-address ) address = ("any" | ipv4-address | ipv6-address )
vrf = tstr ; Name of a VRF on this node with local-address vrf = tstr ; Name of a VRF on this node with local-address
Figure 17: Parameters for remote ACP neighbors Figure 17: Parameters for remote ACP neighbors
Explicit configuration of a remote-peer according to this ABNF Explicit configuration of a remote-peer according to this ABNF
provides all the information to build a secure channel without provides all the information to build a secure channel without
requiring a tunnel to that peer and running DULL GRASP inside of it. requiring a tunnel to that peer and running DULL GRASP inside of it.
skipping to change at page 96, line 6 skipping to change at page 97, line 32
9. ACP Operations (Informative) 9. ACP Operations (Informative)
The following sections document important operational aspects of the The following sections document important operational aspects of the
ACP. They are not normative because they do not impact the ACP. They are not normative because they do not impact the
interoperability between components of the ACP, but they include interoperability between components of the ACP, but they include
recommendations/requirements for the internal operational model recommendations/requirements for the internal operational model
beneficial or necessary to achieve the desired use-case benefits of beneficial or necessary to achieve the desired use-case benefits of
the ACP (see Section 3). the ACP (see Section 3).
o Section 9.1 describes recommended operator diagnostics o Section 9.1 describes recommended operator diagnostics
capabilities of ACP nodes. The have been derived from diagnostic capabilities of ACP nodes.
of a commercially available ACP implementation.
o Section 9.2 describes high level how an ACP registrar needs to o Section 9.2 describes high level how an ACP registrar needs to
work, what its configuration parameters are and specific issues work, what its configuration parameters are and specific issues
impacting the choices of deployment design due to renewal and impacting the choices of deployment design due to renewal and
revocation issues. It describes a model where ACP Registrars have revocation issues. It describes a model where ACP Registrars have
their own sub-CA to provide the most distributed deployment option their own sub-CA to provide the most distributed deployment option
for ACP Registrars, and it describes considerations for for ACP Registrars, and it describes considerations for
centralized policy control of ACP Registrar operations. centralized policy control of ACP Registrar operations.
o Section 9.3 describes suggested ACP node behavior and operational o Section 9.3 describes suggested ACP node behavior and operational
skipping to change at page 96, line 32 skipping to change at page 98, line 11
The recommendations and suggestions of this chapter were derived from The recommendations and suggestions of this chapter were derived from
operational experience gained with a commercially available pre- operational experience gained with a commercially available pre-
standard ACP implementation. standard ACP implementation.
9.1. ACP (and BRSKI) Diagnostics 9.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 Basic standardized diagnostics would require support for (yang)
the complete (auto-)configuration and operational state of all models representing the complete (auto-)configuration and operational
components: BRSKI, GRASP, ACP and the infrastructure used by them: state of all components: GRASP, ACP and the infrastructure used by
TLS/DTLS, IPsec, certificates, TA, time, VRF and so on. While them: TLS/DTLS, IPsec, certificates, TA, time, VRF and so on. While
necessary, this is not sufficient: necessary, this is not sufficient:
Simply representing the state of components does not allow operators Simply representing the state of components does not allow operators
to quickly take action - unless they do understand how to interpret to quickly take action - unless they do understand how to interpret
the data, and that can mean a requirement for deep understanding of the data, and that can mean a requirement for deep understanding of
all components and how they interact in the ACP/ANI. all components and how they interact in the ACP/ANI.
Diagnostic supports should help to quickly answer the questions Diagnostic supports should help to quickly answer the questions
operators are expected to ask, such as "is the ACP working operators are expected to ask, such as "is the ACP working
correctly?", or "why is there no ACP connection to a known correctly?", or "why is there no ACP connection to a known
skipping to change at page 99, line 15 skipping to change at page 100, line 42
* If the neighbor closed the connection on us, provide any error * If the neighbor closed the connection on us, provide any error
diagnostics from the secure channel protocol. diagnostics from the secure channel protocol.
* If we failed the attempt, display our local reason: * If we failed the attempt, display our local reason:
+ There was no common secure channel protocol supported by the + There was no common secure channel protocol supported by the
two neighbors (this could not happen on nodes supporting two neighbors (this could not happen on nodes supporting
this specification because it mandates common support for this specification because it mandates common support for
IPsec). IPsec).
+ The ACP domain certificate membership check (Section 6.1.3) + The ACP certificate membership check (Section 6.1.3) fails:
fails:
- The neighbor's certificate is not signed directly or - The neighbor's certificate is not signed directly or
indirectly by one of the nodes TA. Provide diagnostics indirectly by one of the nodes TA. Provide diagnostics
which TA it has (can identify whom the device belongs which TA it has (can identify whom the device belongs
to). to).
- The neighbor's certificate does not have the same domain - The neighbor's certificate does not have the same domain
(or no domain at all). Diagnose domain-name and (or no domain at all). Diagnose domain-name and
potentially other cert info. potentially other cert info.
skipping to change at page 101, line 46 skipping to change at page 103, line 26
A fourth example case is when multiple registrars where set up for A fourth example case is when multiple registrars where set up for
the same ACP but without correctly setting up the same TA. For the same ACP but without correctly setting up the same TA. For
example when registrars support to also be CA themselves but are example when registrars support to also be CA themselves but are
misconfigured to become TA instead of intermediate CA. misconfigured to become TA instead of intermediate CA.
9.2. ACP Registrars 9.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 certificate into an ACP domain
domain via any appropriate mechanism/protocol, automated or not. 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.
9.2.1. Registrar interactions 9.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
skipping to change at page 102, line 34 skipping to change at page 104, line 12
use the Data-Plane. ACP and Data-Plane in an ACP registrar could use the Data-Plane. ACP and Data-Plane in an ACP registrar could
(and by default should be) completely isolated from each other at the (and by default should be) completely isolated from each other at the
network level. Only applications such as the ACP registrar would network level. Only applications such as the ACP registrar would
need the ability for their transport stacks to access both. need the ability for their transport stacks to access both.
In non-autonomic enrollment options, the Data-Plane between a ACP In non-autonomic enrollment options, the Data-Plane between a ACP
registrar and the candidate ACP node needs to be configured first. registrar and the candidate ACP node needs to be configured first.
This includes the ACP registrar and the candidate ACP node. Then any This includes the ACP registrar and the candidate ACP node. Then any
appropriate set of protocols can be used between ACP registrar and appropriate set of protocols can be used between ACP registrar and
candidate ACP node to discover the other side, and then connect and candidate ACP node to discover the other side, and then connect and
enroll (configure) the candidate ACP node with an ACP domain enroll (configure) the candidate ACP node with an ACP certificate.
certificate. Netconf ZeroTouch ([RFC8572]) is an example protocol Netconf ZeroTouch ([RFC8572]) is an example protocol that could be
that could be used for this. BRSKI using optional discovery used for this. BRSKI using optional discovery mechanisms is equally
mechanisms is equally a possibility for candidate ACP nodes a possibility for candidate ACP nodes attempting to be enrolled
attempting to be enrolled across non-ACP networks, such as the across non-ACP networks, such as the Internet.
Internet.
When candidate ACP nodes have secure bootstrap, such as BRSKI When candidate ACP nodes have secure bootstrap, such as BRSKI
Pledges, they will not trust to be configured/enrolled across the Pledges, they will not trust to be configured/enrolled across the
network, unless being presented with a voucher (see [RFC8366]) network, unless being presented with a voucher (see [RFC8366])
authorizing the network to take possession of the node. An ACP authorizing the network to take possession of the node. An ACP
registrar will then need a method to retrieve such a voucher, either registrar will then need a method to retrieve such a voucher, either
offline, or online from a MASA (Manufacturer Authorized Signing offline, or online from a MASA (Manufacturer Authorized Signing
Authority). BRSKI and Netconf ZeroTouch are two protocols that Authority). BRSKI and Netconf ZeroTouch are two protocols that
include capabilities to present the voucher to the candidate ACP include capabilities to present the voucher to the candidate ACP
node. node.
skipping to change at page 103, line 48 skipping to change at page 105, line 26
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 IDevID information is automatically learned such as from the IDevID
certificate of candidate ACP nodes (as defined in BRSKI). certificate of candidate ACP nodes (as defined in BRSKI).
9.2.3. Certificate renewal and limitations 9.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 certificate from, for example because
because that original ACP registrar is gone. The ACP registrar that original ACP registrar is gone. The ACP registrar through which
through which the renewal/rekeying is performed would by default the renewal/rekeying is performed would by default trust the acp-
trust the acp-node-name from the ACP nodes current ACP domain node-name from the ACP nodes current ACP certificate and maintain
certificate and maintain this information so that the ACP node this information so that the ACP node maintains its ACP address
maintains its ACP address prefix. In EST renewal/rekeying, the ACP prefix. In EST renewal/rekeying, the ACP nodes current ACP
nodes current ACP domain certificate is signaled during the TLS certificate is signaled during the TLS handshake.
handshake.
This simple scenario has two limitations: This simple scenario has two limitations:
1. The ACP registrars cannot directly assign certificates to nodes 1. The ACP registrars cannot directly assign certificates to nodes
and therefore needs an "online" connection to the TA. and therefore needs an "online" connection to the TA.
2. Recovery from a compromised ACP registrar is difficult. When an 2. Recovery from a compromised ACP registrar is difficult. When an
ACP registrar is compromised, it can insert for example a ACP registrar is compromised, it can insert for example a
conflicting acp-node-name and create thereby an attack against conflicting acp-node-name and create thereby an attack against
other ACP nodes through the ACP routing protocol. 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 certificates assigned via the ACP registrar after it was
was compromised. And without additional centralized tracking of compromised. And without additional centralized tracking of assigned
assigned certificates there is no way to do this. certificates there is no way to do this.
9.2.4. ACP Registrars with sub-CA 9.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 TA whenever an ACP node is enrolled, and for connectivity to a TA whenever an ACP node is enrolled, and
reduces the need for connectivity of such an ACP registrar to a TA to reduces the need for connectivity of such an ACP registrar to a TA to
only those times when it needs to renew its own certificate. The ACP only those times when it needs to renew its own certificate. The ACP
registrar would also now use its own (sub-CA) certificate to enroll registrar would also now use its own (sub-CA) certificate to enroll
and sign the ACP nodes certificates, and therefore it is only 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.
Alternatively one can let it expire and not renew it, when the Alternatively one can let it expire and not renew it, when the
certificate of the sub-CA is appropriately short-lived. certificate of the sub-CA is appropriately short-lived.
As the ACP domain membership check verifies a peer ACP node's ACP As the ACP domain membership check verifies a peer ACP node's ACP
domain certificate trust chain, it will also verify the signing certificate trust chain, it will also verify the signing certificate
certificate which is the compromised/revoked sub-CA certificate. which is the compromised/revoked sub-CA certificate. Therefore ACP
Therefore ACP domain membership for an ACP node enrolled from a domain membership for an ACP node enrolled from a compromised and
compromised and discovered ACP registrar will fail. discovered ACP registrar will fail.
ACP nodes enrolled by a compromised ACP registrar would automatically ACP nodes enrolled by a compromised ACP registrar would automatically
fail to establish ACP channels and ACP domain certificate renewal via fail to establish ACP channels and ACP domain certificate renewal via
EST and therefore revert to their role as a candidate ACP members and EST and therefore revert to their role as a candidate ACP members and
attempt to get a new ACP domain certificate from an ACP registrar - attempt to get a new ACP certificate from an ACP registrar - for
for example, via BRSKI. In result, ACP registrars that have an 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 certificates easier and therefore also be used as
used as a tool to introduce short lived certificates and not rely on a tool to introduce short lived certificates and not rely on CRL,
CRL, whereas the certificates for the sub-CAs themselves could be whereas the certificates for the sub-CAs themselves could be longer
longer lived and subject to CRL. lived and subject to CRL.
9.2.5. Centralized Policy Control 9.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 every ACP registrar. per-"serialNumber" policy can be loaded into every ACP registrar.
skipping to change at page 106, line 33 skipping to change at page 108, line 11
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.
9.3.2. Admin Down State 9.3.2. Admin Down State
Interfaces on most network equipment have at least two states: "up" Interfaces on m ost 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
interface is not "down". Therefore an easy way to ensure that all interface is not "down". Therefore an easy way to ensure that all
L2/L3 operations on an interface are inactive is to put the interface L2/L3 operations on an interface are inactive is to put the interface
into "down" state. The fact that this also physically shuts down the into "down" state. The fact that this also physically shuts down the
interface is in many cases just a side effect, but it may be interface is in many cases just a side effect, but it may be
important in other cases (see below, Section 9.3.2.2). important in other cases (see below, Section 9.3.2.2).
To provide ACP/ANI resilience against operators configuring One of the common problems of remote management is for the operator
interfaces to "down" state, this document recommends to separate the or SDN controller to cut its own connectivity to the remote node by a
"down" state of interfaces into an "admin down" state where the configuration impacting its own management connection into the node.
physical layer is kept running and ACP/ANI can use the interface and The ACP itself should have no dedicated configuration other than
a "physical down" state. Any existing "down" configurations would aforementioned enablement of the ACP on brownfield ACP nodes. This
map to "admin down". In "admin down", any existing L2/L3 services of leaves configuration that can not distinguish between ACP and Data-
the Data-Plane should see no difference to "physical down" state. To Plane as sources of configuration mistakes as these commands will
ensure that no Data-Plane packets could be sent/received, packet impact the ACP even though they should only impact the Data-Plane.
filtering could be established automatically as described above in
Section 9.3.1. The one ubiquitous type of commands that do this on many type of
routers are interface "down" commands/configurations. When such a
command is applied to the interface through which the ACP provides
access for remote management it would cut the remote management
connection through the ACP because, as outlined above, the "down"
commands typically impact the physical layer too and not only the
Data-Plane services.
To provide ACP/ANI resilience against such operator misconfiguration,
this document recommends to separate 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 a "physical down" state. Any
existing "down" configurations would 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 ensure that no Data-Plane
packets could be sent/received, packet filtering could be established
automatically as described above in Section 9.3.1.
An example of non-ACP but ANI traffic that should be permitted to
pass even in "admin-down" state is BRSKI enrollment traffic between
BRSKI pledge and a BRSKI proxy.
As necessary (see discussion below) new configuration options could As necessary (see discussion below) new configuration options could
be introduced to issue "physical down". The options should be be introduced to issue "physical down". The options should be
provided with additional checks to minimize the risk of issuing them provided with additional checks to minimize the risk of issuing them
in a way that breaks the ACP without automatic restoration. For in a way that breaks the ACP without automatic restoration. For
example they could be denied to be issued from a control connection example they could be denied to be issued from a control connection
(netconf/ssh) that goes across the interface itself ("do not (netconf/ssh) that goes across the interface itself ("do not
disconnect yourself"). Or they could be performed only temporary and disconnect yourself"). Or they could be performed only temporary and
only be made permanent with additional later reconfirmation. only be made permanent with additional later reconfirmation.
skipping to change at page 114, line 47 skipping to change at page 116, line 47
There is no desirable configuration for the ACP. Instead, all There is no desirable configuration for the ACP. Instead, all
parameters that need to be configured in support of the ACP are parameters that need to be configured in support of the ACP are
limitations of the solution, but they are only needed in cases where limitations of the solution, but they are only needed in cases where
not all components are made autonomic. Whereever this is necessary, not all components are made autonomic. Whereever this is necessary,
it relies on pre-existing mechanisms for configuration such as CLI or it relies on pre-existing mechanisms for configuration such as CLI or
YANG ([RFC7950]) data models. YANG ([RFC7950]) data models.
The most important examples of such configuration include: The most important examples of such configuration include:
o When ACP nodes do not support an autonomic way to receive an ACP o When ACP nodes do not support an autonomic way to receive an ACP
domain certificate, for example BRSKI, then such certificate needs certificate, for example BRSKI, then such certificate needs to be
to be configured via some pre-existing mechanisms outside the configured via some pre-existing mechanisms outside the scope of
scope of this specification. Today, router have typically a this specification. Today, router have typically a variety of
variety of mechanisms to do this. mechanisms to do this.
o Certificate maintenance requires PKI functions. Discovery of o Certificate maintenance requires PKI functions. Discovery of
these functions across the ACP is automated (see Section 6.1.5), these functions across the ACP is automated (see Section 6.1.5),
but their configuration is not. but their configuration is not.
o When non-ACP capable nodes such as pre-existing NMS need to be o When non-ACP capable nodes such as pre-existing NMS need to be
physically connected to the ACP, the ACP node to which they attach physically connected to the ACP, the ACP node to which they attach
needs to be configured with ACP-connect according to Section 8.1. needs to be configured with ACP-connect according to Section 8.1.
It is also possible to use that single physical connection to It is also possible to use that single physical connection to
connect both to ACP and the Data-Plane of the network as explained connect both to ACP and the Data-Plane of the network as explained
skipping to change at page 117, line 41 skipping to change at page 119, line 41
10.2.1. From the outside 10.2.1. From the outside
As explained in Section 6, the ACP is based on secure channels built As explained in Section 6, the ACP is based on secure channels built
between nodes that have mutually authenticated each other with their between nodes that have mutually authenticated each other with their
domain certificates. The channels themselves are protected using domain certificates. The channels themselves are protected using
standard encryption technologies such as DTLS or IPsec which provide standard encryption technologies such as DTLS or IPsec which provide
additional authentication during channel establishment, data additional authentication during channel establishment, data
integrity and data confidentiality protection of data inside the ACP integrity and data confidentiality protection of data inside the ACP
and in addition, provide replay protection. and in addition, provide replay protection.
An attacker will not be able to join the ACP unless having a valid Attacker will not be able to join the ACP unless they have a valid
domain certificate, also packet injection and sniffing traffic will ACP certificate. On-path attackers without a valid ACP certificate
not be possible due to the security provided by the encryption can not inject packets into the ACP due to ACP secure channels. They
protocol. can also not decrypt ACP traffic except if they can crack the
encryption. They can attempt behavioral traffic analysis on the
encrypted ACP traffic.
The degree to which compromised ACP nodes can impact the ACP depends
on the implementation of the ACP nodes and their impairment. When an
attacker has only gained administrative privileges to configure ACP
nodes remotely, the attacker can disrupt the ACP only through one of
the few configuration options to disable it, see Section 9.3, or by
configuring of non-autonomic ACP options if those are supported on
the impaired ACP nodes, see Section 8. Injecting or ectracting
traffic into/from an impaired ACP node is only possible when an
impaired ACP node supports ACP connect (see Section 8.1) and the
attacker can control traffic into/from one of the ACP nodes
interfaces, such as by having physical access to the ACP node.
The ACP also serves as protection (through authentication and The ACP also serves as protection (through authentication and
encryption) for protocols relevant to OAM that may not have secured encryption) for protocols relevant to OAM that may not have secured
protocol stack options or where implementation or deployment of those protocol stack options or where implementation or deployment of those
options fail on some vendor/product/customer limitations. This options fail on some vendor/product/customer limitations. This
includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP
([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog ([IEEE-1588-2008]), DNS ([RFC3596]), DHCPv6 ([RFC3315]), syslog
([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS ([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS
([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a
few. Not all of these protocol references are necessarily the latest few. Not all of these protocol references are necessarily the latest
skipping to change at page 118, line 29 skipping to change at page 120, line 43
packets. The only exception are ACP connected interfaces which packets. The only exception are ACP connected interfaces which
require higher physical protection. The ULA addresses are only require higher physical protection. The ULA addresses are only
reachable inside the ACP context, therefore, unreachable from the reachable inside the ACP context, therefore, unreachable from the
Data-Plane. Also, the ACP protocols should be implemented to be Data-Plane. Also, the ACP protocols should be implemented to be
attack resistant and not consume unnecessary resources even while attack resistant and not consume unnecessary resources even while
under attack. under attack.
10.2.2. From the inside 10.2.2. From the inside
The security model of the ACP is based on trusting all members of the The security model of the ACP is based on trusting all members of the
group of nodes that receive an ACP domain certificate for the same group of nodes that receive an ACP certificate for the same domain.
domain. Attacks from the inside by a compromised group member are Attacks from the inside by a compromised group member are therefore
therefore the biggest challenge. the biggest challenge.
Group members must be protected against attackers so that there is no Group members must be protected against attackers so that there is no
easy way to compromise them, or use them as a proxy for attacking easy way to compromise them, or use them as a proxy for attacking
other devices across the ACP. For example, management plane other devices across the ACP. For example, management plane
functions (transport ports) should only be reachable from the ACP but functions (transport ports) should only be reachable from the ACP but
not the Data-Plane. Especially for those management plane functions not the Data-Plane. Especially for those management plane functions
that have no good protection by themselves because they do not have that have no good protection by themselves because they do not have
secure end-to-end transport and to whom ACP not only provides secure end-to-end transport and to whom ACP not only provides
automatic reliable connectivity but also protection against attacks. automatic reliable connectivity but also protection against attacks.
Protection across all potential attack vectors is typically easier to Protection across all potential attack vectors is typically easier to
do in devices whose software is designed from the ground up with do in devices whose software is designed from the ground up with ACP
security in mind than with legacy software based systems where the in mind than with legacy software based systems where the ACP is
ACP is added on as another feature. added on as another feature.
As explained above, traffic across the ACP SHOULD still be end-to-end As explained above, traffic across the ACP should still be end-to-end
encrypted whenever possible. This includes traffic such as GRASP, encrypted whenever possible. This includes traffic such as GRASP,
EST and BRSKI inside the ACP. This minimizes man in the middle EST and BRSKI inside the ACP. This minimizes man in the middle
attacks by compromised ACP group members. Such attackers cannot attacks by compromised ACP group members. Such attackers cannot
eavesdrop or modify communications, they can just filter them (which eavesdrop or modify communications, they can just filter them (which
is unavoidable by any means). is unavoidable by any means).
See Appendix A.10.8 for further considerations how to avoid and deal See Appendix A.10.8 for further considerations how to avoid and deal
with compromised nodes. with compromised nodes.
10.3. The Administrator View 10.3. The Administrator View
skipping to change at page 119, line 38 skipping to change at page 122, line 7
with ACP aspects unless they explicitly desire to do so. with ACP aspects unless they explicitly desire to 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.
11. Security Considerations 11. Security Considerations
After seeding an ACP by configuring at least one ACP registrar with A set of ACP nodes with ACP certificates for the same ACP domain and
routing-subdomain and a CA, an ACP is self-protecting and there is no with ACP functionaliy enabled is automatically "self-building": The
need to apply configuration to make it secure (typically the ACP ACP is automatically established between neighboring ACP nodes. It
Registrar doubles as EST server for certificate renewal). Its is also "self-protecting": The ACP secure channels are authenticated
security therefore does not depend on configuration. This does not and encrypted. No configuration is required for this.
include workarounds for non-autonomic components as explained in
Section 8. See Section 10.2 for details of how the ACP protects The self-protecting property does not include workarounds for non-
itself against attacks from the outside and to a more limited degree autonomic components as explained in Section 8. See Section 10.2 for
from the inside as well. details of how the ACP protects itself against attacks from the
outside and to a more limited degree from the inside as well.
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
is compromised, the security of the ACP is also compromised. This is compromised, the security of the ACP is also compromised. This
is typically under the control of the network administrator. is typically under the control of the network administrator.
o Every ACP registrar is criticial infrastructure that needs to be o Every ACP registrar is criticial infrastructure that needs to be
hardened against attacks, similar to a CA. A malicious registrar hardened against attacks, similar to a CA. A malicious registrar
can enroll enemy plegdes to an ACP network or break ACP routing by can enroll enemy plegdes to an ACP network or break ACP routing by
duplicate ACP address assignment to pledges via their ACP domain duplicate ACP address assignment to pledges via their ACP
certificates. certificates.
o Security can be compromised by implementation errors (bugs), as in o Security can be compromised by implementation errors (bugs), as in
all products. all products.
There is no prevention of source-address spoofing inside the ACP. There is no prevention of source-address spoofing inside the ACP.
This implies that if an attacker gains access to the ACP, it can This implies that if an attacker gains access to the ACP, it can
spoof all addresses inside the ACP and fake messages from any other spoof all addresses inside the ACP and fake messages from any other
node. node. New protocol/services run across the ACP should therefore use
end-to-end authentication inside the ACP. This is already done by
GRASP as specified in this document.
The ACP is designed to enable automation of current network The ACP is designed to enable automation of current network
management and future autonomic peer-to-peer/distributed network management and future autonomic peer-to-peer/distributed network
automation. Any ACP member can send ACP IPv6 packet to other ACP automation. Any ACP member can send ACP IPv6 packet to other ACP
members and announce via ACP GRASP services to all ACP members members and announce via ACP GRASP services to all ACP members
without depenency against centralized components. without depenency against centralized components.
The ACP relies on peer-to-peer authentication and authorization using The ACP relies on peer-to-peer authentication and authorization using
ACP certificates. This security model is necessary to enable the ACP certificates. This security model is necessary to enable the
autonomic ad-hoc any-to-any connectivity between ACP nodes. It autonomic ad-hoc any-to-any connectivity between ACP nodes. It
provides infrastructure protection through hop by hop authentication provides infrastructure protection through hop by hop authentication
and encryption - without relying on third parties. For any services and encryption - without relying on third parties. For any services
where this complete autonomic peer-to-peer group security model is where this complete autonomic peer-to-peer group security model is
appropriate, the ACP domain certificate can also be used unchanged. appropriate, the ACP certificate can also be used unchanged. For
For example for any type of Data-Plane routing protocol security. example for any type of Data-Plane routing protocol security.
This ACP security model is designed primarily to protect against This ACP security model is designed primarily to protect against
attack from the outside, but not against attacks from the inside. To attack from the outside, but not against attacks from the inside. To
protect against spoofing attacks from compromised on-path ACP nodes, protect against spoofing attacks from compromised on-path ACP nodes,
end-to-end encryption inside the ACP is used by new ACP signaling: end-to-end encryption inside the ACP is used by new ACP signaling:
GRASP across the ACP using TLS. The same is expected from any non- GRASP across the ACP using TLS. The same is expected from any non-
legacy services/protocols using the ACP. Because no group-keys are legacy services/protocols using the ACP. Because no group-keys are
used, there is no risk for impacted nodes to access end-to-end used, there is no risk for impacted nodes to access end-to-end
encrypted traffic from other ACP nodes. encrypted traffic from other ACP nodes.
skipping to change at page 121, line 11 skipping to change at page 123, line 29
ACP and the absence of configuration options that could be abused ACP and the absence of configuration options that could be abused
that allow to change/break ACP behavior. This is excluding that allow to change/break ACP behavior. This is excluding
configuration for workaround in support of non-autonomic components. configuration for workaround in support of non-autonomic components.
Mitigation against compromised ACP members is possible through Mitigation against compromised ACP members is possible through
standard automated certificate management mechanisms including standard automated certificate management mechanisms including
revocation and non-renewal of short-lived certificates. In this revocation and non-renewal of short-lived certificates. In this
version of the specification, there are no further optimization of version of the specification, there are no further optimization of
these mechanisms defined for the ACP (but see Appendix A.10.8). these mechanisms defined for the ACP (but see Appendix A.10.8).
Higher layer service built using ACP domain certificates should not Higher layer service built using ACP certificates should not solely
solely rely on undifferentiated group security when another model is rely on undifferentiated group security when another model is more
more appropriate/more secure. For example central network appropriate/more secure. For example central network configuration
configuration relies on a security model where only few especially relies on a security model where only few especially trusted nodes
trusted nodes are allowed to configure the Data-Plane of network are allowed to configure the Data-Plane of network nodes (CLIL,
nodes (CLIL, Netconf). This can be done through ACP domain Netconf). This can be done through ACP certificates by
certificates by differentiating them and introduce roles. See differentiating them and introduce roles. See Appendix A.10.5.
Appendix A.10.5.
Fundamentally, security depends on avoiding operator and network Operators and provisioning software developers need to be aware of
operations automation mistakes, implementation and architecture. how the provisioning/configuration of network devices impacts the
Autonomic approaches such as the ACP largely eliminate operator ability of the operator / provisioning software to remotely access
mistakes and make it easier to recover from network operations the network nodes. By using the ACP, most of the issues of
mistakes. Implementation and architectural mistakes are still configuration/provisioning caused loss of connectivity for remote
possible, as in all networking technologies. provisioning/configuration will be eliminated, see Section 6. Only
few exceptions such as explicit physical interface down configuration
will be left Section 9.3.2.
Many details of ACP are designed with security in mind and discussed Many details of ACP are designed with security in mind and discussed
elsewhere in the document: elsewhere in the document:
IPv6 addresses used by nodes in the ACP are covered as part of the IPv6 addresses used by nodes in the ACP are covered as part of the
node's domain certificate as described in Section 6.1.2. This allows node's domain certificate as described in Section 6.1.2. This allows
even verification of ownership of a peer's IPv6 address when using a even verification of ownership of a peer's IPv6 address when using a
connection authenticated with the domain certificate. connection authenticated with the domain certificate.
The ACP acts as a security (and transport) substrate for GRASP inside The ACP acts as a security (and transport) substrate for GRASP inside
skipping to change at page 127, line 5 skipping to change at page 129, line 19
11. Textually enhanced / better structured security considerations 11. Textually enhanced / better structured security considerations
section after IESG security review. section after IESG security review.
A. (new) Moved all explanations and discussions about futures from A. (new) Moved all explanations and discussions about futures from
section 10 into this new appendix. This text should not be removed section 10 into this new appendix. This text should not be removed
because it captures a lot of repeated asked questions in WG and because it captures a lot of repeated asked questions in WG and
during reviews and from users, and also captures ideas for some during reviews and from users, and also captures ideas for some
likely important followup work. But none of this is relevant to likely important followup work. But none of this is relevant to
implementing (section 6) and operating (section 10) the ACP. implementing (section 6) and operating (section 10) the ACP.
14.2. draft-ietf-anima-autonomic-control-plane-27 14.2. draft-ietf-anima-autonomic-control-plane-28
IESG review Roman Danyliw:
6. Requested additional text elaborating misconfiguration plus
attack vectors.
6.1.3.1 Added paragraph about unsecured NTP as basis for time in the
absence of other options.
6.7.2 reworded text about additional secure channel protocol
reqiurements.
6.7.3.1.2. Added requirement for ACP nodes supporting IKEv2 to
support RFC8247 (not sure how that got dropped from prior versions.
Replaced minimum crypto requirements definition via specific AES
options with more generic "symmetric key/hash strength" requirements.
6.10.7.3. Added example how to derive addressing scheme from IDevID
(PID). Added explanation how to deal with non-persistant registrar
address database (hint: it sucks or is wasteful, what did you
expect).
8.1.1. Added explanation for 'Physical controlled/secured'.
8.1.5. Removed 'Physical controlled/secured' text, refer back to
8.1.1.
8.2.1. Fixed ABNF 'or' syntax line.
9.3.2. Added explanation of remote management problem with interface
"down" type commands.
10.2.1. Added explanations for attacks from impaired ACP nodes.
11. Rewrote intro paragraph. Removed text referring to enrollment/
registrars as they are out of scope of ACP (dependencies only).
11. Added note about need for new protocols inside ACP to use end-
to-end authentication.
11. Rewrote paragraph about operator mistakes so as to be
actionably. Operators must not make mistakes - but ACP minimizes the
mistakes they can make.
ACP domain certificate -> ACP certificate.
Various other cosmetic edits (thanks!) and typo fixes (sorry for not
running full spell check for every version. Will definitely do
before RFC editor).
Other:
6.12.5.2.1./6.12.5.2.2. Added text explaining link breakage wrt.
RTL (came about re-analyzing behavior after question about hop
count).
Removed now unnecessary references for earlier rrc822Name otherName
choice.
14.3. draft-ietf-anima-autonomic-control-plane-27
Too many revisions with too many fixes. Lets do a one-word change Too many revisions with too many fixes. Lets do a one-word change
revision for a change now if it helps to accelerate the review revision for a change now if it helps to accelerate the review
process. process.
Added "subjectAltName /" to make it unambiguous that AcpNodeName is Added "subjectAltName /" to make it unambiguous that AcpNodeName is
indeed a SAN (from Russ). indeed a SAN (from Russ).
14.3. draft-ietf-anima-autonomic-control-plane-26 14.4. draft-ietf-anima-autonomic-control-plane-26
Russ Housley review of -25. Russ Housley review of -25.
1.1 Explicit reference for TLS 1.2 RFC. 1.1 Explicit reference for TLS 1.2 RFC.
2. Changed term of "ACP Domain Information" to AcpNodeName (ASN.1) / 2. Changed term of "ACP Domain Information" to AcpNodeName (ASN.1) /
acp-node-name (ABNF), also through rest of document. acp-node-name (ABNF), also through rest of document.
2. Improved CA behavior definition. changed IDevID/LDevID to IDevID/ 2. Improved CA behavior definition. changed IDevID/LDevID to IDevID/
LDevID certificate to be more unambiguous. LDevID certificate to be more unambiguous.
skipping to change at page 128, line 7 skipping to change at page 131, line 35
6.1.4 Fixed up text re. inability to use public CA to situation with 6.1.4 Fixed up text re. inability to use public CA to situation with
otherName / AcpNodeName (no more ACME rfc822Name validation for us otherName / AcpNodeName (no more ACME rfc822Name validation for us
*sob* *sob* *sob*). *sob* *sob* *sob*).
12. Added ASN.1 registration requests to IANA section. 12. Added ASN.1 registration requests to IANA section.
Appenices. Minor changes for rfc822Name to otherName change. Appenices. Minor changes for rfc822Name to otherName change.
Various minor verbal fixes/enhancements. Various minor verbal fixes/enhancements.
14.4. draft-ietf-anima-autonomic-control-plane-25 14.5. draft-ietf-anima-autonomic-control-plane-25
Crypto parameter discuss from Valery Smyslov and Paul Wouters and Crypto parameter discuss from Valery Smyslov and Paul Wouters and
resulting changes. resulting changes.
6.7.2 Moved Michael Richardson suggested diagnostic of signaling TA 6.7.2 Moved Michael Richardson suggested diagnostic of signaling TA
from IPsec section to this general requirements section and added from IPsec section to this general requirements section and added
explanation how this may be inappropriate if TA payload is considered explanation how this may be inappropriate if TA payload is considered
secret by TA owner. secret by TA owner.
6.7.3.1 Added traffic selectors for native IPsec. Improved text 6.7.3.1 Added traffic selectors for native IPsec. Improved text
skipping to change at page 131, line 10 skipping to change at page 134, line 38
2. Fixed definition of "Enrollment", "Trust Anchor", "CA", and "root 2. Fixed definition of "Enrollment", "Trust Anchor", "CA", and "root
CA". Changed "Certificate Authority" to "Certification Authority" CA". Changed "Certificate Authority" to "Certification Authority"
throughout the document (correct term according to X.509). throughout the document (correct term according to X.509).
6.1 Fixed explanation of mutual ACP trust. 6.1 Fixed explanation of mutual ACP trust.
6.1.1 s/X509/X509v3/. 6.1.1 s/X509/X509v3/.
6.1.2 created bulleted lists for explanations and justifications for 6.1.2 created bulleted lists for explanations and justifications for
choices of ACP domain certificate encoding. No semantic changes, choices of ACP certificate encoding. No semantic changes, just to
just to make it easier to refer to the points in discussions (rfcdiff make it easier to refer to the points in discussions (rfcdiff seems
seems to have a bug showing text differences due to formatting to have a bug showing text differences due to formatting changes).
changes).
6.1.3 Moved content of rule #1 into previous rule #2 because 6.1.3 Moved content of rule #1 into previous rule #2 because
certification chain validation does imply validation of lifetime. certification chain validation does imply validation of lifetime.
numbers of all rules reduced by 1, changed hopefully all references numbers of all rules reduced by 1, changed hopefully all references
to the rule numbers in the document. to the rule numbers in the document.
Rule #3, Hopefully fixed linguistic problem self-contradiction of Rule #3, Hopefully fixed linguistic problem self-contradiction of
MUST by lower casing MUST in the explanation part and rewriting the MUST by lower casing MUST in the explanation part and rewriting the
condition when this is not applicable. condition when this is not applicable.
skipping to change at page 131, line 35 skipping to change at page 135, line 16
(TA"). Replaced throughout document Trust Anchor with abbreviation (TA"). Replaced throughout document Trust Anchor with abbreviation
TA. TA.
Enhanced several sentences/rewrote paragraphs to make explanations Enhanced several sentences/rewrote paragraphs to make explanations
clearer. clearer.
6.6 Added explanation how ACP nodes must throttle their attempts for 6.6 Added explanation how ACP nodes must throttle their attempts for
connection making purely on the result of their own connection connection making purely on the result of their own connection
attempts, not based on those connections where they are responder. attempts, not based on those connections where they are responder.
14.5. draft-ietf-anima-autonomic-control-plane-24 14.6. draft-ietf-anima-autonomic-control-plane-24
Leftover from -23 review by Eric Vyncke: Leftover from -23 review by Eric Vyncke:
Swapping sections 9 and 10, section 9 was meant to be at end of Swapping sections 9 and 10, section 9 was meant to be at end of
document and summarize. Its not meant to be misinterpreted as document and summarize. Its not meant to be misinterpreted as
introducing any new information. This did happen because section 10 introducing any new information. This did happen because section 10
was added after section 9. was added after section 9.
14.6. draft-ietf-anima-autonomic-control-plane-23 14.7. draft-ietf-anima-autonomic-control-plane-23
Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal. Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal.
Review of IPsec security with Mcr and ipsec mailing list. Review of IPsec security with Mcr and ipsec mailing list.
6.7.1 - new section: Moved general considerations for secure channel 6.7.1 - new section: Moved general considerations for secure channel
protocols here, refined them. protocols here, refined them.
6.7.2 - new section: Moved common requirements for secure channel 6.7.2 - new section: Moved common requirements for secure channel
protocols here, refined them. protocols here, refined them.
skipping to change at page 133, line 20 skipping to change at page 136, line 47
and did not well explain why ACP for L2/L3 switches can be and did not well explain why ACP for L2/L3 switches can be
implemented without any L2 (HW) changes. Also missing explanation of implemented without any L2 (HW) changes. Also missing explanation of
only running GRASP untagged when VLANs are used. only running GRASP untagged when VLANs are used.
8.1.1 - Added requirement for ACP Edge nodes to allow configurable 8.1.1 - Added requirement for ACP Edge nodes to allow configurable
filtering of IPv6 RPI headers. filtering of IPv6 RPI headers.
11. - (security section). Moved explanation of address stealing from 11. - (security section). Moved explanation of address stealing from
7.2 to here. 7.2 to here.
14.7. draft-ietf-anima-autonomic-control-plane-22 14.8. draft-ietf-anima-autonomic-control-plane-22
Ben Kaduk review of -21: Ben Kaduk review of -21:
RFC822 encoding of ACP domain information: RFC822 encoding of ACP domain information:
6.1.2 rewrote text for explaining / justifying use of rfc822name as 6.1.2 rewrote text for explaining / justifying use of rfc822name as
identifier for node CP in certificate (was discussed in thread, but identifier for node CP in certificate (was discussed in thread, but
badly written in prior versions). badly written in prior versions).
6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is 6.1.2 Changed EBNF syntax to use "+" after rfcSELF because that is
skipping to change at page 135, line 8 skipping to change at page 138, line 38
information. information.
- removed last two paragraphs about relationship to rfc8247, as his - removed last two paragraphs about relationship to rfc8247, as his
is now written in first paragraph of the section. is now written in first paragraph of the section.
End of Ben Kaduk review related fixes. End of Ben Kaduk review related fixes.
Other: Other:
Forgot to update example of ACP domain information to use capitalized Forgot to update example of ACP domain information to use capitalized
hex-digits as required by HEXDIGIT used. hex-digits as required by HEXLC used.
Added reference to RFC8316 (AN use-cases) to beginning of section 3 Added reference to RFC8316 (AN use-cases) to beginning of section 3
(ACP use cases). (ACP use cases).
Small Enhanced IPsec parameters description / requirements fixes Small Enhanced IPsec parameters description / requirements fixes
(from Michael Richardson). (from Michael Richardson).
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-41 (work in progress), April 2020.
[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.
[IKEV2IANA] [IKEV2IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2) IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters", <https://www.iana.org/assignments/ikev2- Parameters", <https://www.iana.org/assignments/ikev2-
parameters/ikev2-parameters.xhtml>. parameters/ikev2-parameters.xhtml>.
skipping to change at page 136, line 35 skipping to change at page 140, line 26
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012, RFC 6552, DOI 10.17487/RFC6552, March 2012,
<https://www.rfc-editor.org/info/rfc6552>. <https://www.rfc-editor.org/info/rfc6552>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
skipping to change at page 138, line 39 skipping to change at page 142, line 29
networks via GRASP", draft-eckert-anima-noc-autoconfig-00 networks via GRASP", draft-eckert-anima-noc-autoconfig-00
(work in progress), July 2018. (work in progress), July 2018.
[I-D.ietf-acme-star] [I-D.ietf-acme-star]
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Support for Short-Term, Automatically-Renewed Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management (STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-11 (work in Environment (ACME)", draft-ietf-acme-star-11 (work in
progress), October 2019. progress), October 2019.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-41 (work in progress), April 2020.
[I-D.ietf-anima-prefix-management] [I-D.ietf-anima-prefix-management]
Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic
IPv6 Edge Prefix Management in Large-scale Networks", IPv6 Edge Prefix Management in Large-scale Networks",
draft-ietf-anima-prefix-management-07 (work in progress), draft-ietf-anima-prefix-management-07 (work in progress),
December 2017. December 2017.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
Networking", draft-ietf-anima-reference-model-10 (work in Networking", draft-ietf-anima-reference-model-10 (work in
progress), November 2018. progress), November 2018.
[I-D.ietf-roll-applicability-template] [I-D.ietf-roll-applicability-template]
Richardson, M., "ROLL Applicability Statement Template", Richardson, M., "ROLL Applicability Statement Template",
draft-ietf-roll-applicability-template-09 (work in draft-ietf-roll-applicability-template-09 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-39 (work in progress), June 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1.3", draft-ietf-tls-dtls13-38 (work in progress), May
2020. 2020.
[IEEE-1588-2008] [IEEE-1588-2008]
IEEE, "IEEE Standard for a Precision Clock Synchronization IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
December 2008, <http://standards.ieee.org/findstds/ December 2008, <http://standards.ieee.org/findstds/
skipping to change at page 140, line 35 skipping to change at page 144, line 13
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<https://www.rfc-editor.org/info/rfc2315>. <https://www.rfc-editor.org/info/rfc2315>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>. <https://www.rfc-editor.org/info/rfc2409>.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, DOI 10.17487/RFC2821, April 2001,
<https://www.rfc-editor.org/info/rfc2821>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>. <https://www.rfc-editor.org/info/rfc2865>.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
DOI 10.17487/RFC3164, August 2001, DOI 10.17487/RFC3164, August 2001,
<https://www.rfc-editor.org/info/rfc3164>. <https://www.rfc-editor.org/info/rfc3164>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
skipping to change at page 147, line 12 skipping to change at page 150, line 43
type would be defined, it could be a backward compatible extension of type would be defined, it could be a backward compatible extension of
this ACP specification. Information such as the size of a zone- this ACP specification. Information such as the size of a zone-
prefix and the length of the prefix assigned to the ACP node itself prefix and the length of the prefix assigned to the ACP node itself
could be encoded via the extension field of the acp-node-name. could be encoded via the extension field of the acp-node-name.
Note that an explicitly defined "Manual" addressing sub-scheme is Note that an explicitly defined "Manual" addressing sub-scheme is
always beneficial to provide an easy way for ACP nodes to prohibit always beneficial to provide an easy way for ACP nodes to prohibit
incorrect manual configuration of any non-"Manual" ACP address spaces incorrect manual configuration of any non-"Manual" ACP address spaces
and therefore ensure that "Manual" operations will never impact and therefore ensure that "Manual" operations will never impact
correct routing for any non-"Manual" ACP addresses assigned via ACP correct routing for any non-"Manual" ACP addresses assigned via ACP
domain certificates. certificates.
A.2. BRSKI Bootstrap (ANI) A.2. BRSKI Bootstrap (ANI)
BRSKI describes how nodes with an IDevID certificate can securely and BRSKI describes how nodes with an IDevID certificate can securely and
zero-touch enroll with an LDevID certificate to support the ACP. zero-touch enroll with an LDevID certificate to support the ACP.
BRSKI also leverages the ACP to enable zero-touch bootstrap of new BRSKI also leverages the ACP to enable zero-touch bootstrap of new
nodes across networks without any configuration requirements across nodes across networks without any configuration requirements across
the transit nodes (e.g., no DHCP/DNS forwarding/server setup). This the transit nodes (e.g., no DHCP/DNS forwarding/server setup). This
includes otherwise not configured networks as described in includes otherwise not configured networks as described in
Section 3.2. Therefore BRSKI in conjunction with ACP provides for a Section 3.2. Therefore BRSKI in conjunction with ACP provides for a
skipping to change at page 154, line 16 skipping to change at page 157, line 42
An ACP domain is the set of all ACP nodes that can authenticate each An ACP domain is the set of all ACP nodes that can authenticate each
other as belonging to the same ACP network using the ACP domain other as belonging to the same ACP network using the ACP domain
membership check (Section 6.1.3). GRASP inside the ACP is run across membership check (Section 6.1.3). GRASP inside the ACP is run across
all transitively connected ACP nodes in a domain. all transitively connected ACP nodes in a domain.
The rsub element in the acp-node-name permits the use of addresses The rsub element in the acp-node-name permits the use of addresses
from different ULA prefixes. One use case is to create multiple from different ULA prefixes. One use case is to create multiple
physical networks that initially may be separated with one ACP domain physical networks that initially may be separated with one ACP domain
but different routing subdomains, so that all nodes can mutual trust but different routing subdomains, so that all nodes can mutual trust
their ACP domain certificates (not depending on rsub) and so that their ACP certificates (not depending on rsub) and so that they could
they could connect later together into a contiguous ACP network. connect later together into a contiguous ACP network.
One instance of such a use case is an ACP for regions interconnected One instance of such a use case is an ACP for regions interconnected
via a non-ACP enabled core, for example due to the absence of product via a non-ACP enabled core, for example due to the absence of product
support for ACP on the core nodes. ACP connect configurations as support for ACP on the core nodes. ACP connect configurations as
defined in this document can be used to extend and interconnect those defined in this document can be used to extend and interconnect those
ACP islands to the NOC and merge them into a single ACP when later ACP islands to the NOC and merge them into a single ACP when later
that product support gap is closed. that product support gap is closed.
Note that RPL scales very well. It is not necessary to use multiple Note that RPL scales very well. It is not necessary to use multiple
routing subdomains to scale ACP domains in a way it would be possible routing subdomains to scale ACP domains in a way it would be possible
skipping to change at page 160, line 10 skipping to change at page 163, line 30
ACP connect is an explicit mechanism to "leak" ACP traffic explicitly ACP connect is an explicit mechanism to "leak" ACP traffic explicitly
(for example in a NOC). It is therefore also a possible security gap (for example in a NOC). It is therefore also a possible security gap
when it is easy to enable ACP connect on arbitrary compromised ACP when it is easy to enable ACP connect on arbitrary compromised ACP
nodes. nodes.
One simple solution is to define an extension in the ACP certificates One simple solution is to define an extension in the ACP certificates
ACP information field indicating the permission for ACP connect to be ACP information field indicating the permission for ACP connect to be
configured on that ACP node. This could similarly be done to decide configured on that ACP node. This could similarly be done to decide
whether a node is permitted to be a registrar or not. whether a node is permitted to be a registrar or not.
Tying the permitted "roles" of an ACP node to the ACP domain Tying the permitted "roles" of an ACP node to the ACP certificate
certificate provides fairly strong protection against provides fairly strong protection against misconfiguration, but is
misconfiguration, but is still subject to code modifications. still subject to code modifications.
Another interesting role to assign to certificates is that of a NOC Another interesting role to assign to certificates is that of a NOC
node. This would allow to limit certain type of connections such as node. This would allow to limit certain type of connections such as
OAM TLS connections to only NOC initiator or responders. OAM TLS connections to only NOC initiator or responders.
A.10.6. Autonomic L3 transit A.10.6. Autonomic L3 transit
In this specification, the ACP can only establish autonomic In this specification, the ACP can only establish autonomic
connectivity across L2 hops and only explicitly configured options to connectivity across L2 hops and only explicitly configured options to
tunnel across L3. Future work should specify mechanisms to tunnel across L3. Future work should specify mechanisms to
skipping to change at page 162, line 6 skipping to change at page 165, line 29
ongoing configuration tracking from central locations for example, ongoing configuration tracking from central locations for example,
and to react accordingly. and to react accordingly.
The primary reaction is withdrawal/change of credentials, terminate The primary reaction is withdrawal/change of credentials, terminate
malicious existing management sessions and fixing the configuration. malicious existing management sessions and fixing the configuration.
Ensuring that management sessions using invalidated credentials are Ensuring that management sessions using invalidated credentials are
terminated automatically without recourse will likely require new terminated automatically without recourse will likely require new
work. work.
Only when these steps are not feasible would it be necessary to Only when these steps are not feasible would it be necessary to
revoke or expire the ACP domain certificate credentials and consider revoke or expire the ACP certificate credentials and consider the
the node kicked off the network - until the situation can be further node kicked off the network - until the situation can be further
rectified, likely requiring direct physical access to the node. rectified, likely requiring direct physical access to the node.
Without extensions, compromised ACP nodes can only be removed from Without extensions, compromised ACP nodes can only be removed from
the ACP at the speed of CRL/OCSP information refresh or expiry (and the ACP at the speed of CRL/OCSP information refresh or expiry (and
non-removal) of short lived certificates. Future extensions to the non-removal) of short lived certificates. Future extensions to the
ACP could for example use GRASP flooding distribution of triggered ACP could for example use GRASP flooding distribution of triggered
updates of CRL/OCSP or explicit removal indication of the compromised updates of CRL/OCSP or explicit removal indication of the compromised
nodes domain certificate. nodes domain certificate.
Authors' Addresses Authors' Addresses
 End of changes. 149 change blocks. 
570 lines changed or deleted 708 lines changed or added

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