draft-ietf-anima-autonomic-control-plane-22.txt   draft-ietf-anima-autonomic-control-plane-23.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: August 6, 2020 Expires: September 10, 2020
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
February 3, 2020 March 9, 2020
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-22 draft-ietf-anima-autonomic-control-plane-23
Abstract Abstract
Autonomic functions need a control plane to communicate, which Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Management depends on some addressing and routing. This Autonomic Control Plane
and Control Plane should ideally be self-managing, and as independent should ideally be self-managing, and as independent as possible of
as possible of configuration. This document defines such a plane and configuration. This document defines such a plane and calls it the
calls it the "Autonomic Control Plane", with the primary use as a "Autonomic Control Plane", with the primary use as a control plane
control plane for autonomic functions. It also serves as a "virtual for autonomic functions. It also serves as a "virtual out-of-band
out-of-band channel" for Operations Administration and Management channel" for Operations, Administration and Management (OAM)
(OAM) communications over a network that provides automatically communications over a network that provides automatically configured
configured hop-by-hop authenticated and encrypted communications via hop-by-hop authenticated and encrypted communications via
automatically configured IPv6 even when the network is not automatically configured IPv6 even when the network is not
configured, or misconfigured. configured, or misconfigured.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 6, 2020. This Internet-Draft will expire on September 10, 2020.
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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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) . . . . . . . . . . . . . . . . . 5
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8
2. Acronyms and Terminology (Informative) . . . . . . . . . . . 9 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 9
3. Use Cases for an Autonomic Control Plane (Informative) . . . 15 3. Use Cases for an Autonomic Control Plane (Informative) . . . 16
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 15 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 16
3.2. Secure Bootstrap over a not configured Network . . . . . 15 3.2. Secure Bootstrap over a not configured Network . . . . . 16
3.3. Data-Plane Independent Permanent Reachability . . . . . . 16 3.3. Data-Plane Independent Permanent Reachability . . . . . . 17
4. Requirements (Informative) . . . . . . . . . . . . . . . . . 17 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 18
5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 18 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 19
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 20 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 21
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 21
6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 21 6.1.1. ACP Certificates . . . . . . . . . . . . . . . . . . 22
6.1.2. ACP Certificate ACP Domain Information Field . . . . 23 6.1.2. ACP Certificate ACP Domain Information Field . . . . 24
6.1.3. ACP domain membership check . . . . . . . . . . . . . 27 6.1.3. ACP domain membership check . . . . . . . . . . . . . 28
6.1.4. Trust Points and Trust Anchors . . . . . . . . . . . 29 6.1.3.1. Realtime clock and Time Validation . . . . . . . 30
6.1.5. Certificate and Trust Point Maintenance . . . . . . . 30 6.1.4. Trust Points and Trust Anchors . . . . . . . . . . . 30
6.1.5.1. GRASP objective for EST server . . . . . . . . . 31 6.1.5. Certificate and Trust Point Maintenance . . . . . . . 31
6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 32 6.1.5.1. GRASP objective for EST server . . . . . . . . . 32
6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 32 6.1.5.2. Renewal . . . . . . . . . . . . . . . . . . . . . 34
6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 33 6.1.5.3. Certificate Revocation Lists (CRLs) . . . . . . . 34
6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 33 6.1.5.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 35
6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 35 6.1.5.5. Re-enrollment . . . . . . . . . . . . . . . . . . 35
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 35 6.1.5.6. Failing Certificates . . . . . . . . . . . . . . 36
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 36 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 37
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 39 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 38
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 39 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 41
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 43 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 41
6.7. Security Association (Secure Channel) protocols . . . . . 43 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 45
6.7.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 44 6.7. Security Association (Secure Channel) protocols . . . . . 45
6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 44 6.7.1. General considerations . . . . . . . . . . . . . . . 45
6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 47 6.7.2. Common requirements . . . . . . . . . . . . . . . . . 46
6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 48 6.7.3. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 47
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 48 6.7.3.1. Native IPsec . . . . . . . . . . . . . . . . . . 48
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 49 6.7.3.1.1. RFC8221 (IPsec/ESP) . . . . . . . . . . . . . 48
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 49 6.7.3.1.2. RFC847 (IKEv2) . . . . . . . . . . . . . . . 49
6.8.2. ACP as the Security and Transport substrate for GRASP 50 6.7.3.2. IPsec with GRE encapsulation . . . . . . . . . . 50
6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 52
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 53
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 54
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 54
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 56
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 57
6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 59
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 60
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 61
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 62
6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 62
6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 63
6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 63
6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 64
6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 65
6.10.7.5. Further Details . . . . . . . . . . . . . . . . 65
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 65
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 66
6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 66
6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 68
6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 68
6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 68
6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 68
6.11.1.6. Objective Function . . . . . . . . . . . . . . . 68
6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 68
6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 69
6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 69
6.11.1.10. P2P communications . . . . . . . . . . . . . . . 69
6.11.1.11. IPv6 address configuration . . . . . . . . . . . 69
6.11.1.12. Administrative parameters . . . . . . . . . . . 69
6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 70
6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 70
6.12. General ACP Considerations . . . . . . . . . . . . . . . 70
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 70
6.12.2. Addressing of Secure Channels . . . . . . . . . . . 71
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 71
6.12.4. Multiple links between nodes . . . . . . . . . . . . 72
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 72
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 75
7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 75
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 76
8. Support for Non-ACP Components (Normative) . . . . . . . . . 78
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 78
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 78
8.1.2. Software Components . . . . . . . . . . . . . . . . . 80
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 81
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 82
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 83
8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 84 6.7.4. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 51
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 84 6.7.5. ACP Secure Channel Profiles . . . . . . . . . . . . . 53
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 86 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 53
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 86 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 53
9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 86 6.8.2. ACP as the Security and Transport substrate for GRASP 54
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 86 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 57
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 88 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 58
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 88 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 58
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 89 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 58
9.3. The Administrator View . . . . . . . . . . . . . . . . . 89 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 60
10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 90 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 61
10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 91 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 63
10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 95 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 64
10.2.1. Registrar interactions . . . . . . . . . . . . . . . 95 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 65
10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 96 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 66
10.2.3. Certificate renewal and limitations . . . . . . . . 97 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 67
10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 98 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 67
10.2.5. Centralized Policy Control . . . . . . . . . . . . . 98 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 68
10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 99 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 68
10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 99 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 69
10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 100 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 70
10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 101 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 70
10.3.2.2. Fast state propagation and Diagnostics . . . . . 101 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 70
10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 102 6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 71
10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 102 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 72
10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 103 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 72
10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 103 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 72
10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 104 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 73
10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 105 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 73
10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 105 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 73
10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 106 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 73
10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 106 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 73
10.4. Configuration and the ACP (summary) . . . . . . . . . . 107 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 74
11. Security Considerations . . . . . . . . . . . . . . . . . . . 108 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 74
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111 6.11.1.12. Administrative parameters . . . . . . . . . . . 74
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111 6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 74
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 112 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 75
14.1. Summary of changes since entering IESG review . . . . . 112 6.12. General ACP Considerations . . . . . . . . . . . . . . . 75
14.1.1. Reviews (while in IESG review status) / status . . . 112 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 75
14.1.2. BRSKI / ACP registrar related enhancements . . . . . 113 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 75
14.1.3. Normative enhancements since start of IESG review . 113 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 76
14.1.4. Explanatory enhancements since start of IESG review 114 6.12.4. Multiple links between nodes . . . . . . . . . . . . 76
14.2. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 115 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 77
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.12.5.1. ACP loopback interfaces . . . . . . . . . . . . 77
15.1. Normative References . . . . . . . . . . . . . . . . . . 117 6.12.5.2. ACP virtual interfaces . . . . . . . . . . . . . 77
15.2. Informative References . . . . . . . . . . . . . . . . . 120 6.12.5.2.1. ACP point-to-point virtual interfaces . . . 78
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.12.5.2.2. ACP multi-access virtual interfaces . . . . 78
Appendix A. Background and Futures (Informative) . . . . . . . . 127 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 80
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 127 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 80
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 128 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 81
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 129 8. Support for Non-ACP Components (Normative) . . . . . . . . . 83
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 129 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 83
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 129 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 83
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 130 8.1.2. Software Components . . . . . . . . . . . . . . . . . 85
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 130 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 86
A.5. ACP Information Distribution and multicast . . . . . . . 131 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 87
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 132 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 89
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 134 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 135 ACP neighbors) . . . . . . . . . . . . . . . . . . . . . 89
A.9. Adopting ACP concepts for other environments . . . . . . 136 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 90
A.10. Further (future) options . . . . . . . . . . . . . . . . 138 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 91
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 138 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 91
A.10.2. More options for avoiding IPv6 Data-Plane dependency 138 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 91
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 139 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 91
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 139 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 93
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 140 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 93
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 141 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 94
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 141 9.3. The Administrator View . . . . . . . . . . . . . . . . . 94
A.10.8. Avoiding and dealing with compromised ACP nodes . . 142 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 143 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 96
10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 100
10.2.1. Registrar interactions . . . . . . . . . . . . . . . 100
10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 101
10.2.3. Certificate renewal and limitations . . . . . . . . 102
10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 103
10.2.5. Centralized Policy Control . . . . . . . . . . . . . 103
10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 104
10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 104
10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 105
10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 106
10.3.2.2. Fast state propagation and Diagnostics . . . . . 106
10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 107
10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 107
10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 108
10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 108
10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 109
10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 110
10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 110
10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 111
10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 111
10.4. Configuration and the ACP (summary) . . . . . . . . . . 112
11. Security Considerations . . . . . . . . . . . . . . . . . . . 113
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 116
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 117
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 117
14.1. Summary of changes since entering IESG review . . . . . 117
14.1.1. Reviews (while in IESG review status) / status . . . 117
14.1.2. BRSKI / ACP registrar related enhancements . . . . . 118
14.1.3. Normative enhancements since start of IESG review . 118
14.1.4. Explanatory enhancements since start of IESG review 119
14.2. draft-ietf-anima-autonomic-control-plane-23 . . . . . . 120
14.3. draft-ietf-anima-autonomic-control-plane-22 . . . . . . 122
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 124
15.1. Normative References . . . . . . . . . . . . . . . . . . 124
15.2. Informative References . . . . . . . . . . . . . . . . . 127
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Appendix A. Background and Futures (Informative) . . . . . . . . 134
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 134
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 135
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 136
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 136
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 136
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 137
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 137
A.5. ACP Information Distribution and multicast . . . . . . . 139
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 140
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 141
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 143
A.9. Adopting ACP concepts for other environments . . . . . . 144
A.10. Further (future) options . . . . . . . . . . . . . . . . 145
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 145
A.10.2. More options for avoiding IPv6 Data-Plane dependency 146
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 146
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 147
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 147
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 148
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 148
A.10.8. Avoiding and dealing with compromised ACP nodes . . 149
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 150
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].
Autonomic functions need an autonomically built communications Autonomic functions need an autonomically built communications
infrastructure. This infrastructure needs to be secure, resilient infrastructure. This infrastructure needs to be secure, resilient
and re-usable by all autonomic functions. Section 5 of [RFC7575] and re-usable by all autonomic functions. Section 5 of [RFC7575]
introduces that infrastructure and calls it the Autonomic Control introduces that infrastructure and calls it the Autonomic Control
Plane (ACP). More descriptively it would be the "Autonomic Plane (ACP). More descriptively it would be the "Autonomic
communications infrastructure for Management and Control". For communications infrastructure for OAM and Control". For naming
naming consistency with that prior document, this document continues consistency with that prior document, this document continues to use
to use the name ACP though. the name ACP though.
Today, the management and control plane of networks typically uses a Today, the OAM and control plane of networks typically uses a routing
routing and forwarding table which is dependent on correct and forwarding table which is dependent on correct configuration and
configuration and routing. Misconfigurations or routing problems can routing. Misconfigurations or routing problems can disrupt OAM and
disrupt management and control channels. Traditionally, an out-of- control channels. Traditionally, an out-of-band network has been
band network has been used to avoid or allow recovery from such used to avoid or allow recovery from such problems, or personnel are
problems, or personnel are sent on site to access devices through sent on site to access devices through out-of-band management ports
out-of-band management ports (also called craft ports, serial (also called craft ports, serial console, management ethernet port).
console, management ethernet port). However, both options are However, both options are expensive.
expensive.
In increasingly automated networks either centralized management In increasingly automated networks either centralized management
systems or distributed autonomic service agents in the network systems or distributed autonomic service agents in the network
require a control plane which is independent of the configuration of require a control plane which is independent of the configuration of
the network they manage, to avoid impacting their own operations the network they manage, to avoid impacting their own operations
through the configuration actions they take. through the configuration actions they take.
This document describes a modular design for a self-forming, self- This document describes a modular design for a self-forming, self-
managing and self-protecting Autonomic Control Plane (ACP), which is managing and self-protecting ACP, which is a virtual in-band network
a virtual in-band network designed to be as independent as possible designed to be as independent as possible of configuration,
of configuration, addressing and routing problems. The details how addressing and routing problems. The details how this is achieved
this is achieved are described in Section 6. The ACP is designed to are described in Section 6. The ACP is designed to remain
remain operational even in the presence of configuration errors, operational even in the presence of configuration errors, addressing
addressing or routing issues, or where policy could inadvertently or routing issues, or where policy could inadvertently affect
affect connectivity of both data packets or control packets. connectivity of both data packets or control packets.
This document uses the term "Data-Plane" to refer to anything in the This document uses the term "Data-Plane" to refer to anything in the
network nodes that is not the ACP, and therefore considered to be network nodes that is not the ACP, and therefore considered to be
dependent on (mis-)configuration. This Data-Plane includes both the dependent on (mis-)configuration. This Data-Plane includes both the
traditional forwarding-plane, as well as any pre-existing control- traditional forwarding-plane, as well as any pre-existing control-
plane, such as routing protocols that establish routing tables for plane, such as routing protocols that establish routing tables for
the forwarding plane. the forwarding plane.
The Autonomic Control Plane serves several purposes at the same time: The Autonomic Control Plane serves several purposes at the same time:
skipping to change at page 6, line 46 skipping to change at page 7, line 8
inside the ACP and depends on the ACP as its "security and inside the ACP and depends on the ACP as its "security and
transport substrate". transport substrate".
2. A controller or network management system can use it to securely 2. A controller or network management system can use it to securely
bootstrap network devices in remote locations, even if the (Data- bootstrap network devices in remote locations, even if the (Data-
Plane) network in between is not yet configured; no Data-Plane Plane) network in between is not yet configured; no Data-Plane
dependent bootstrap configuration is required. An example of dependent bootstrap configuration is required. An example of
such a secure bootstrap process is described in such a secure bootstrap process is described in
[I-D.ietf-anima-bootstrapping-keyinfra]. [I-D.ietf-anima-bootstrapping-keyinfra].
3. An operator can use it to log into remote devices, even if the 3. An operator can use it to access remote devices using protocols
network is misconfigured or not configured. such as Secure SHell (SSH) or Network Configuration Protocol
(NETCONF) running across the ACP, even if the network is
misconfigured or not configured.
This document describes these purposes as use cases for the ACP in This document describes these purposes as use cases for the ACP in
Section 3, it defines the requirements in Section 4. Section 5 gives Section 3, it defines the requirements in Section 4. Section 5 gives
an overview how the ACP is constructed. an overview how the ACP is constructed.
The normative part of this document starts with Section 6, where the The normative part of this document starts with Section 6, where the
ACP is specified. Section 7 defines normative how to support ACP on ACP is specified. Section 7 defines normative how to support ACP on
L2 switches. Section 8 explains normative how non-ACP nodes and L2 switches. Section 8 explains normative how non-ACP nodes and
networks can be integrated. networks can be integrated.
skipping to change at page 7, line 33 skipping to change at page 7, line 45
be implemented and operated without any other components of autonomic be implemented and operated without any other components of autonomic
networks, except for the GRASP protocol. ACP relies on per-link DULL networks, except for the GRASP protocol. ACP relies on per-link DULL
GRASP (see Section 6.3) to autodiscover ACP neighbors, and includes GRASP (see Section 6.3) to autodiscover ACP neighbors, and includes
the ACP GRASP instance to provide service discovery for clients of the ACP GRASP instance to provide service discovery for clients of
the ACP (see Section 6.8) including for its own maintenance of ACP the ACP (see Section 6.8) including for its own maintenance of ACP
certificates. certificates.
The document "Using Autonomic Control Plane for Stable Connectivity The document "Using Autonomic Control Plane for Stable Connectivity
of Network OAM" [RFC8368] describes how the ACP alone can be used to of Network OAM" [RFC8368] describes how the ACP alone can be used to
provide secure and stable connectivity for autonomic and non- provide secure and stable connectivity for autonomic and non-
autonomic Operations Administration and Management (OAM) autonomic OAM applications. That document also explains how existing
applications. That document also explains how existing management management solutions can leverage the ACP in parallel with
solutions can leverage the ACP in parallel with traditional traditional management models, when to use the ACP and how to
management models, when to use the ACP and how to integrate with integrate with potentially IPv4 only OAM backends.
potentially IPv4 only OAM backends.
Combining ACP with Bootstrapping Remote Secure Key Infrastructures Combining ACP with Bootstrapping Remote Secure Key Infrastructures
(BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the
"Autonomic Network Infrastructure" as defined in "Autonomic Network Infrastructure" (ANI) as defined in
[I-D.ietf-anima-reference-model], which provides autonomic [I-D.ietf-anima-reference-model], which provides autonomic
connectivity (from ACP) with secure zero-touch (automated) bootstrap connectivity (from ACP) with secure zero-touch (automated) bootstrap
from BRSKI. The ANI itself does not constitute an Autonomic Network, from BRSKI. The ANI itself does not constitute an Autonomic Network,
but it allows the building of more or less autonomic networks on top but it allows the building of more or less autonomic networks on top
of it - using either centralized, Software Defined Networking- of it - using either centralized, Software Defined Networking-
(SDN-)style (see [RFC7426]) automation or distributed automation via (SDN-)style (see [RFC7426]) automation or distributed automation via
Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a Autonomic Service Agents (ASA) / Autonomic Functions (AF) - or a
mixture of both. See [I-D.ietf-anima-reference-model] for more mixture of both. See [I-D.ietf-anima-reference-model] for more
information. information.
skipping to change at page 8, line 16 skipping to change at page 8, line 26
Please see the following Terminology section (Section 2) for Please see the following Terminology section (Section 2) for
explanations of terms used in this section. explanations of terms used in this section.
The design of the ACP as defined in this document is considered to be The design of the ACP as defined in this document is considered to be
applicable to all types of "professionally managed" networks: Service applicable to all types of "professionally managed" networks: Service
Provider, Local Area Network (LAN), Metro(politan networks), Wide Provider, Local Area Network (LAN), Metro(politan networks), Wide
Area Network (WAN), Enterprise Information Technology (IT) and Area Network (WAN), Enterprise Information Technology (IT) and
->"Operational Technology" () (OT) networks. The ACP can operate ->"Operational Technology" () (OT) networks. The ACP can operate
equally on layer 3 equipment and on layer 2 equipment such as bridges equally on layer 3 equipment and on layer 2 equipment such as bridges
(see Section 7). The hop-by-hop authentication and confidentiality (see Section 7). The hop-by-hop authentication, integrity-protection
mechanism used by the ACP is defined to be negotiable, therefore it and confidentiality mechanism used by the ACP is defined to be
can be extended to environments with different protocol preferences. negotiable, therefore it can be extended to environments with
The minimum implementation requirements in this document attempt to different protocol preferences. The minimum implementation
achieve maximum interoperability by requiring support for multiple requirements in this document attempt to achieve maximum
options depending on the type of device: IPsec, see [RFC4301], and interoperability by requiring support for multiple options depending
datagram Transport Layer Security version 1.2 (DTLS), see [RFC6347]). on the type of device: IPsec, see [RFC4301], and datagram Transport
Layer Security (DTLS) version 1.2, see [RFC6347]).
The implementation footprint of the ACP consists of Public Key The implementation footprint of the ACP consists of Public Key
Infrastructure (PKI) code for the ACP certificate, the GRASP Infrastructure (PKI) code for the ACP certificate, the GRASP
protocol, UDP, TCP and TLS (for security and reliability of GRASP), protocol, UDP, TCP and TLS (for security and reliability of GRASP),
the ACP secure channel protocol used (such as IPsec or DTLS), and an the ACP secure channel protocol used (such as IPsec or DTLS), and an
instance of IPv6 packet forwarding and routing via the Routing instance of IPv6 packet forwarding and routing via the Routing
Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that
is separate from routing and forwarding for the Data-Plane (user is separate from routing and forwarding for the Data-Plane (user
traffic). traffic).
skipping to change at page 9, line 45 skipping to change at page 10, line 11
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
and one for RFC number.] and one for RFC number.]
This document serves both as a normative specification for how ACP
nodes have to behave as well as describing requirements, benefits,
architecture and operational aspects to explain the context.
Normative sections are labelled "(Normative)" and use
[RFC2119]/[RFC8174] keywords. Other sections are labelled
"(Informative)" and do not use those normative keywords.
In the rest of the document we will refer to systems using the ACP as In the rest of the document we will refer to systems using the ACP as
"nodes". Typically such a node is a physical (network equipment) "nodes". Typically such a node is a physical (network equipment)
device, but it can equally be some virtualized system. Therefore, we device, but it can equally be some virtualized system. Therefore, we
do not refer to them as devices unless the context specifically calls do not refer to them as devices unless the context specifically calls
for a physical system. for a physical system.
This document introduces or uses the following terms (sorted This document introduces or uses the following terms (sorted
alphabetically). Terms introduced are explained on first use, so alphabetically). Terms introduced are explained on first use, so
this list is for reference only. this list is for reference only.
skipping to change at page 11, line 13 skipping to change at page 11, line 31
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 cryptographically authenticated and encrypted ACP secure channel: A channel authenticated via ->"ACP domain
data connection established between (normally) adjacent ACP nodes certificates" () providing integrity protection and
to carry traffic of the ACP VRF securely and isolated from Data- confidentiality through encryption. These are established between
Plane traffic in-band over the same link/path as the Data-Plane. (normally) adjacent ACP nodes to carry traffic of the ACP VRF
securely and isolated from Data-Plane traffic in-band over the
same link/path as the Data-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 11, line 43 skipping to change at page 12, line 15
ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is ANI (nodes/network): "Autonomic Network Infrastructure". The ANI is
the infrastructure to enable Autonomic Networks. It includes ACP, the infrastructure to enable Autonomic Networks. It includes ACP,
BRSKI and GRASP. Every Autonomic Network includes the ANI, but BRSKI and GRASP. Every Autonomic Network includes the ANI, but
not every ANI network needs to include autonomic functions beyond not every ANI network needs to include autonomic functions beyond
the ANI (nor Intent). An ANI network without further autonomic the ANI (nor Intent). An ANI network without further autonomic
functions can for example support secure zero-touch (automated) functions can for example support secure zero-touch (automated)
bootstrap and stable connectivity for SDN networks - see bootstrap and stable connectivity for SDN networks - see
[RFC8368]. [RFC8368].
ANIMA: "Autonomic Networking Integrated Model and Approach". ACP, ANIMA: "Autonomic Networking Integrated Model and Approach". ACP,
BRSKI and GRASP are products of the IETF ANIMA working group. BRSKI and GRASP are specifications of the IETF ANIMA working
group.
ASA: "Autonomic Service Agent". Autonomic software modules running ASA: "Autonomic Service Agent". Autonomic software modules running
on an ANI device. The components making up the ANI (BRSKI, ACP, on an ANI device. The components making up the ANI (BRSKI, ACP,
GRASP) are also described as ASAs. GRASP) are also described as ASAs.
Autonomic Function: A function/service in an Autonomic Network (AN) Autonomic Function: A function/service in an Autonomic Network (AN)
composed of one or more ASA across one or more ANI nodes. composed of one or more ASA across one or more ANI nodes.
BRSKI: "Bootstrapping Remote Secure Key Infrastructures" BRSKI: "Bootstrapping Remote Secure Key Infrastructures"
([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending ([I-D.ietf-anima-bootstrapping-keyinfra]. A protocol extending
EST to enable secure zero-touch bootstrap in conjunction with ACP. EST to enable secure zero-touch bootstrap in conjunction with ACP.
ANI nodes use ACP, BRSKI and GRASP. ANI nodes use ACP, BRSKI and GRASP.
CA: "Certificate Authority". An entity that issues digital
certificates. A CA uses its own cerrtificate to sign the
certificates it issues. This signing certificate can be
considered to be an identifier of the CA, so the term CA is also
loosely used to refer to the certificate used by the CA for
signing.
CRL: "Certificate Revocation List". A list of revoked certificates.
Required to revoke certificates before their lifetime expires.
Data-Plane: The counterpoint to the ACP VRF in an ACP node: all Data-Plane: The counterpoint to the ACP VRF in an ACP node: all
routing and forwarding in the node other than the ACP VRF. In a routing and forwarding in the node other than the ACP VRF. In a
simple ACP or ANI node, the Data-Plane is typically provisioned by simple ACP or ANI node, the Data-Plane is typically provisioned by
means other than autonomically, for example manually (including means other than autonomically, for example manually (including
across the ACP) or via SDN controllers. In a fully Autonomic across the ACP) or via SDN controllers. In a fully Autonomic
Network node, the Data-Plane is managed autonomically via Network node, the Data-Plane is managed autonomically via
Autonomic Functions and Intent. Note that other (non-ANIMA) RFCs Autonomic Functions and Intent. Note that other (non-ANIMA) RFCs
use the Data-Plane to refer to what is better called the use the Data-Plane to refer to what is better called the
forwarding plane. This is not the way the term is used in this forwarding plane. This is not the way the term is used in this
document! document!
device: A physical system, or physical node. device: A physical system, or physical node.
Enrollment: The process where a node presents identification (for Enrollment: The process where a node presents identification (for
example through keying material such as the private key of an example through keying material such as the private key of an
IDevID) to a network and acquires a network specific identity uch IDevID) to a network and acquires a network specific identity such
as an LDevID and trust anchors such as Certificate Authority (CA) as an LDevID and trust anchors such as Certificate Authority (CA)
certificates. certificates.
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. BRSKI is track protocol for enrollment of a node with an LDevID. BRSKI is
based on EST. 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
the ACP secure channels to support BRSKI and other NOC/OAM or the ACP secure channels to support BRSKI and other NOC/OAM or
Autonomic Functions. See [I-D.ietf-anima-grasp]. Autonomic Functions. See [I-D.ietf-anima-grasp].
IDevID: An "Initial Device IDentity" X.509 certificate installed by IDevID: An "Initial Device IDentity" X.509 certificate installed by
the vendor on new equipment. Contains information that the vendor on new equipment. Contains information that
establishes the identity of the node in the context of its vendor/ establishes the identity of the node in the context of its vendor/
manufacturer such as device model/type and serial number. See manufacturer such as device model/type and serial number. See
[AR8021]. IDevID cannot be used for the ACP because they are not [AR8021]. IDevID cannot be used as a node identifier for the ACP
provisioned by the owner of the network, so they can not directly because they are not provisioned by the owner of the network, so
indicate an ACP domain they belong to. they can not directly indicate an ACP domain they belong to.
in-band (management): The type of management used predominantly in in-band (management): The type of management used predominantly in
IP based networks, not leveraging an ->"out-of-band network" (). IP based networks, not leveraging an ->"out-of-band network" ().
In in-band management, access to the managed equipment depends on In in-band management, access to the managed equipment depends on
the configuration of this equipment itself: interface, addressing, the configuration of this equipment itself: interface, addressing,
forwarding, routing, policy, security, management. This forwarding, routing, policy, security, management. This
dependency makes in-band management fragile because the dependency makes in-band management fragile because the
configuration actions performed may break in-band management configuration actions performed may break in-band management
connectivity. Breakage can not only be unintentional, it can connectivity. Breakage can not only be unintentional, it can
simply be an unavoidable side effect of being unable to create simply be an unavoidable side effect of being unable to create
skipping to change at page 13, line 24 skipping to change at page 14, line 9
[I-D.ietf-anima-reference-model]. [I-D.ietf-anima-reference-model].
Loopback interface: The conventional name for an internal IP Loopback interface: The conventional name for an internal IP
interface to which addresses may be assigned, but which transmits interface to which addresses may be assigned, but which transmits
no external traffic. no external traffic.
LDevID: A "Local Device IDentity" is an X.509 certificate installed LDevID: A "Local Device IDentity" is an X.509 certificate installed
during "enrollment". The Domain Certificate used by the ACP is an during "enrollment". The Domain Certificate used by the ACP is an
LDevID. See [AR8021]. LDevID. See [AR8021].
Management: Used in this document as another word for ->"OAM" ().
MASA (service): "Manufacturer Authorized Signing Authority". A
vendor/manufacturer or delegated cloud service on the Internet
used as part of the BRSKI protocol.
MIC: "Manufacturer Installed Certificate". This is another word to MIC: "Manufacturer Installed Certificate". This is another word to
describe an IDevID in referenced materials. This term is not used describe an IDevID in referenced materials. This term is not used
in this document. in this document.
native interface: Interfaces existing on a node without native interface: Interfaces existing on a node without
configuration of the already running node. On physical nodes configuration of the already running node. On physical nodes
these are usually physical interfaces. On virtual nodes their these are usually physical interfaces. On virtual nodes their
equivalent. equivalent.
node: A system, e.g., supporting the ACP according to this document. NOC: Network Operations Center.
Can be virtual or physical. Physical nodes are called devices.
node: A system supporting the ACP according to this document. Can
be virtual or physical. Physical nodes are called devices.
Node-ID: The identifier of an ACP node inside that ACP. It is the Node-ID: The identifier of an ACP node inside that ACP. It is the
last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of last 64 (see Section 6.10.3) or 78-bits (see Section 6.10.5) of
the ACP address. the ACP address.
OAM: Operations, Administration and Management. Includes Network
Monitoring.
Operational Technology (OT): "https://en.wikipedia.org/wiki/ Operational Technology (OT): "https://en.wikipedia.org/wiki/
Operational_Technology" [1]: "The hardware and software dedicated Operational_Technology" [1]: "The hardware and software dedicated
to detecting or causing changes in physical processes through to detecting or causing changes in physical processes through
direct monitoring and/or control of physical devices such as direct monitoring and/or control of physical devices such as
valves, pumps, etc.". OT networks are today in most cases well valves, pumps, etc.". OT networks are today in most cases well
separated from Information Technology (IT) networks. separated from Information Technology (IT) networks.
(virtual) out-of-band network: An out-of-band network is a secondary (virtual) out-of-band network: An out-of-band network is a secondary
network used to manage a primary network. The equipment of the network used to manage a primary network. The equipment of the
primary network is connected to the out-of-band network via primary network is connected to the out-of-band network via
skipping to change at page 14, line 16 skipping to change at page 15, line 11
access to the primary network independent of the configuration access to the primary network independent of the configuration
state of the primary network. One of the goals of the ACP is to state of the primary network. One of the goals of the ACP is to
provide this benefit of out-of-band networks virtually on the provide this benefit of out-of-band networks virtually on the
primary network equipment. The ACP VRF acts as a virtual out of primary network equipment. The ACP VRF acts as a virtual out of
band network device providing configuration independent management band network device providing configuration independent management
access. The ACP secure channels are the virtual links of the ACP access. The ACP secure channels are the virtual links of the ACP
virtual out-of-band network, meant to be operating independent of virtual out-of-band network, meant to be operating independent of
the configuration of the primary network. See also ->"in-band the configuration of the primary network. See also ->"in-band
(management)" (). (management)" ().
root CA: "root certificate authority". A trusted ->"CA" (). The
certificate used by the CA to sign issued certificates is expected
to be a ->"TA" (), which makes it the root of a certificate chain.
The term root CA is also loosely used to refer to the root CA's
signing certificate. Root CA certificates are self-signed.
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].
MASA (service): "Manufacturer Authorized Signing Authority". A
vendor/manufacturer or delegated cloud service on the Internet
used as part of the BRSKI protocol.
(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 domain certificate. ANI nodes use BRSKI, so ANI
registrars are also called BRSKI registrars. For non-ANI ACP registrars are also called BRSKI registrars. For non-ANI ACP
nodes, the registrar mechanisms are undefined by this document. nodes, the registrar mechanisms are undefined by this document.
See Section 6.10.7. Renewal and other maintenance (such as See Section 6.10.7. Renewal and other maintenance (such as
revocation) of ACP domain certificates may be performed by other revocation) of ACP domain certificates may be performed by other
entities than registrars. EST must be supported for ACP domain entities than registrars. EST must be supported for ACP domain
certificate renewal (see Section 6.1.5). BRSKI is an extension of certificate renewal (see Section 6.1.5). BRSKI is an extension of
EST, so ANI/BRSKI registrars can easily support ACP domain EST, so ANI/BRSKI registrars can easily support ACP domain
certificate renewal in addition to initial enrollment. certificate renewal in addition to initial enrollment.
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
in this document. in this document.
TA "Trust Anchor(s)". A list of one or more certificates that are
trusted signers of other certificates. Authenticating a
certificate consists of verifying the chain of signing
certificates until a TA is encountered. In the most simple case,
the TA is a single certificate of the single root CAThe most
simple form of a TA is a root certificate.
UDI: "Unique Device Identifier". In the context of this document UDI: "Unique Device Identifier". In the context of this document
unsecured identity information of a node typically consisting of unsecured identity information of a node typically consisting of
at least device model/type and serial number, often in a vendor at least device model/type and serial number, often in a vendor
specific format. See sUDI and LDevID. specific format. See sUDI and LDevID.
ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6
address in the block fc00::/7, defined in [RFC4193]. It is the address in the block fc00::/7, defined in [RFC4193]. It is the
approximate IPv6 counterpart of the IPv4 private address approximate IPv6 counterpart of the IPv4 private address
([RFC1918]). The ULA Global ID prefix are the first 48-bits of a ([RFC1918]). The ULA Global ID prefix are the first 48-bits of a
ULA address. In this document it is abbreviated as "ULA prefix". ULA address. In this document it is abbreviated as "ULA prefix".
skipping to change at page 16, line 25 skipping to change at page 17, line 29
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 domain certificate can also be used to end-to-end encrypt the
bootstrap communication between such proxies and server. Note that bootstrap 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 network management Today, most critical control plane protocols and OAM protocols are
protocols are using the Data-Plane of the network. This leads to using the Data-Plane of the network. This leads to often undesirable
often undesirable dependencies between control and management plane dependencies between control and OAM plane on one side and the Data-
on one side and the Data-Plane on the other: Only if the forwarding Plane on the other: Only if the forwarding and control plane of the
and control plane of the Data-Plane are configured correctly, will Data-Plane are configured correctly, will the Data-Plane and the OAM/
the Data-Plane and the management plane work as expected. control plane work as expected.
Data-Plane connectivity can be affected by errors and faults, for Data-Plane connectivity can be affected by errors and faults, for
example misconfigurations that make AAA (Authentication, example misconfigurations that make AAA (Authentication,
Authorization and Accounting) servers unreachable or can lock an Authorization and Accounting) servers unreachable or can lock an
administrator out of a device; routing or addressing issues can make administrator out of a device; routing or addressing issues can make
a device unreachable; shutting down interfaces over which a current a device unreachable; shutting down interfaces over which a current
management session is running can lock an admin irreversibly out of management session is running can lock an admin irreversibly out of
the device. Traditionally only out-of-band access can help recover the device. Traditionally only out-of-band access can help recover
from such issues (such as serial console or ethernet management from such issues (such as serial console or ethernet management
port). port).
skipping to change at page 17, line 9 skipping to change at page 18, line 14
Note that specific control plane functions for the Data-Plane often Note that specific control plane functions for the Data-Plane often
want to depend on forwarding of their packets via the Data-Plane: want to depend on forwarding of their packets via the Data-Plane:
Aliveness and routing protocol signaling packets across the Data- Aliveness and routing protocol signaling packets across the Data-
Plane to verify reachability across the Data-Plane, using IPv4 Plane to verify reachability across the Data-Plane, using IPv4
signaling packets for IPv4 routing vs. IPv6 signaling packets for signaling packets for IPv4 routing vs. IPv6 signaling packets for
IPv6 routing. IPv6 routing.
Assuming appropriate implementation (see Section 6.12.2 for more Assuming appropriate implementation (see Section 6.12.2 for more
details), the ACP provides reachability that is independent of the details), the ACP provides reachability that is independent of the
Data-Plane. This allows the control plane and management plane to Data-Plane. This allows the control plane and OAM plane to operate
operate more robustly: more robustly:
o For management plane protocols, the ACP provides the functionality o For management plane protocols, the ACP provides the functionality
of a Virtual out-of-band (VooB) channel, by providing connectivity of a Virtual out-of-band (VooB) channel, by providing connectivity
to all nodes regardless of their Data-Plane configuration, routing to all nodes regardless of their Data-Plane configuration, routing
and forwarding tables. and forwarding tables.
o For control plane protocols, the ACP allows their operation even o For control plane protocols, the ACP allows their operation even
when the Data-Plane is temporarily faulty, or during transitional when the Data-Plane is temporarily faulty, or during transitional
events, such as routing changes, which may affect the control events, such as routing changes, which may affect the control
plane at least temporarily. This is specifically important for plane at least temporarily. This is specifically important for
skipping to change at page 17, line 48 skipping to change at page 19, line 4
configuration and routing. Requirements 2 and 3 build on this configuration and routing. Requirements 2 and 3 build on this
requirement, but also have value on their own. requirement, but also have value on their own.
ACP2: The ACP must have a separate address space from the Data- ACP2: The ACP must have a separate address space from the Data-
Plane. Reason: traceability, debug-ability, separation from Plane. Reason: traceability, debug-ability, separation from
Data-Plane, infrastructure security (filtering based on known Data-Plane, infrastructure security (filtering based on known
address space). address space).
ACP3: The ACP must use autonomically managed address space. Reason: ACP3: The ACP must use autonomically managed address space. Reason:
easy bootstrap and setup ("autonomic"); robustness (admin easy bootstrap and setup ("autonomic"); robustness (admin
cannot break network easily). This document suggests using cannot break network easily). This document uses Unique Local
ULA addressing for this purpose ("Unique Local Address", see Addresses (ULA) for this purpose, see [RFC4193].
[RFC4193]).
ACP4: The ACP must be generic, that is it must be usable by all the ACP4: The ACP must be generic, that is it must be usable by all the
functions and protocols of the ANI. Clients of the ACP must functions and protocols of the ANI. Clients of the ACP must
not be tied to a particular application or transport protocol. not be tied to a particular application or transport protocol.
ACP5: The ACP must provide security: Messages coming through the ACP ACP5: The ACP must provide security: Messages coming through the ACP
must be authenticated to be from a trusted node, and should must be authenticated to be from a trusted node, and should
(very strong should) be encrypted. (very strong should) be encrypted.
Explanation for ACP4: In a fully autonomic network (AN), newly Explanation for ACP4: In a fully autonomic network (AN), newly
skipping to change at page 20, line 7 skipping to change at page 21, line 7
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 This section describes the components and steps to set up an ACP and
Autonomic Control Plane (ACP), and highlights the key properties highlights the key properties which make it "indestructible" against
which make it "indestructible" against many inadvertent changes to many inadvertent changes to the Data-Plane, for example caused by
the Data-Plane, for example caused by misconfigurations. misconfigurations.
An ACP node can be a router, switch, controller, NMS host, or any An ACP node can be a router, switch, controller, NMS host, or any
other IP capable node. Initially, it must have its ACP domain other IP capable node. Initially, it MUST have its ACP domain
certificate, as well as an (empty) ACP Adjacency Table (described in certificate, as well as an (empty) ACP Adjacency Table (described in
Section 6.2). It then can start to discover ACP neighbors and build Section 6.2). It then can start to discover ACP neighbors and build
the ACP. This is described step by step in the following sections: the ACP. This is described step by step in the following sections:
6.1. ACP Domain, Certificate and Network 6.1. ACP Domain, Certificate and Network
The ACP relies on group security. An ACP domain is a group of nodes The ACP relies on group security. An ACP domain is a group of nodes
that trust each other to participate in ACP operations 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 establish between ACP domain members via protocols such as IPsec. To establish
trust, each ACP member requires keying material: An ACP node MUST trust, each ACP member requires keying material: An ACP node MUST
have a certificate (LDevID) and a Trust Anchor (TA) consisting of a have a Local Device IDentity certificate (LDevID) and a Trust Anchor
certificate (chain) used to sign the LDevID of all ACP domain (TA) consisting of a certificate (chain) used to sign the LDevID of
members. The LDevID is used to cryptographically authenticate the all ACP domain members. The LDevID is used to cryptographically
membership of its owner node in the ACP domain to other ACP domain authenticate the membership of its owner node in the ACP domain to
members. The TA is used to authenticate the ACP domain membership of other ACP domain members. The TA is used to authenticate the ACP
other nodes (see Section 6.1.3). domain membership of other nodes (see Section 6.1.3). This document
calls the LDevID used for the the ACP the ACP certificate.
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 is called the ACP domain certificate, the TA is the The LDevID is called the ACP domain certificate, the TA is the
Certificate Authority (CA) of the ACP domain. Certificate Authority (CA) root certificate of the ACP domain.
The ACP does not mandate specific mechanisms by which this keying The ACP does not mandate specific mechanisms by which this keying
material is provisioned into the ACP node. It only requires the material is provisioned into the ACP node. It only requires the
certificate to comply with Section 6.1.1, specifically the Domain certificate to comply with Section 6.1.1, specifically the Domain
information field as specified in Section 6.1.2 in its domain information field as specified in Section 6.1.2 in its domain
certificate as well as those of candidate ACP peers. See certificate as well as those of candidate ACP peers. See
Appendix A.2 for more information about enrollment or provisioning Appendix A.2 for more information about enrollment or provisioning
options. options.
This document uses the term ACP in many places where the Autonomic This document uses the term ACP in many places where the Autonomic
skipping to change at page 22, line 43 skipping to change at page 23, line 43
which is encoded as an rfc822Name field. which is encoded as an rfc822Name field.
Any other field of the ACP domain certificate is to be populated as Any other field of the ACP domain certificate is to be populated as
required by [RFC5280] or desired by the operator of the ACP domain required by [RFC5280] or desired by the operator of the ACP domain
ACP registrars/CA and required by other purposes that the ACP domain ACP registrars/CA and required by other purposes that the ACP domain
certificate is intended to be used for. certificate is intended to be used for.
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 into the ACP copy the device identifying fields of the node's IDevID into the ACP
domain certificate, such as the "serialNumber" (see domain certificate, such as the "serialNumber" (see
[I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). Inclusion of [I-D.ietf-anima-bootstrapping-keyinfra] section 2.3.1). This can be
this information makes it easier to potentially attack the node done for example if it would be acceptable for the devices
though, for example by learning the device model, which may help to "serialNumber" to be signalled via the Link Layer Discovery Protocol
select a fitting subset of attacks. Neighboring attackers can (LLDP, [LLDP]) because like LLDP signalled information, the ACP
retrieve the certificate through an otherwise unsuccessful initiation certificate information can be retrieved bei neighboring nodes
of a secure channel association. without further authentication and be used either for beneficial
diagnostics or for malicious attacks. Retrieval of the ACP
certificate is possible via a (failing) attempt to set up an ACP
secure channel, and the "serialNumber" contains usually device type
information that may help to faster determine working exploits/
attacks against the device.
Note that there is no intention to constrain authorization within the Note that there is no intention to constrain authorization within the
ACP or autonomic networks using the ACP to just the ACP domain ACP or autonomic networks using the ACP to just the ACP domain
membership check as defined in this document. It can be extended or membership check as defined in this document. It can be extended or
modified with 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 ACP Domain Information Field 6.1.2. ACP Certificate ACP Domain Information Field
skipping to change at page 23, line 22 skipping to change at page 24, line 28
following ABNF ([RFC5234]) definition: following ABNF ([RFC5234]) definition:
[RFC Editor: Please substitute SELF in all occurrences of rfcSELF in [RFC Editor: Please substitute SELF in all occurrences of rfcSELF in
this document with the RFC number assigned to this document and this document with the RFC number assigned to this document and
remove this comment line] remove this comment line]
domain-information = local-part "@" acp-domain-name domain-information = local-part "@" acp-domain-name
local-part = key [ "+" local-info ] local-part = key [ "+" local-info ]
key = "rfcSELF" key = "rfcSELF"
local-info = [ acp-address ] [ "+" rsub extensions ] local-info = [ acp-address ] [ "+" rsub extensions ]
acp-address = 32HEXDIG | 0 ; HEXDIG as of RFC5234 section B.1 HEXLC = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
; DIGIT as of RFC5234 section B.1
acp-address = 32HEXLC | "0"
rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5 rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5
acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5 acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5
extensions = *( "+" extension ) extensions = *( "+" extension )
extension = ; future standard definition. extension = ; future standard definition.
; Must fit RFC5322 simple dot-atom format. ; Must fit RFC5322 simple dot-atom format.
routing-subdomain = [ rsub " ." ] acp-domain-name routing-subdomain = [ rsub "." ] acp-domain-name
Example: Example:
given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000
and an ACP domain-name of acp.example.com and an ACP domain-name of acp.example.com
and an rsub extenstion of area51.research and an rsub extenstion of area51.research
then this results in: then this results in:
domain-information = rfcSELF+FD89B714F3DB00000200000064000000 domain-information = rfcSELF+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 Domain Information Field ABNF Figure 2: ACP Domain Information Field ABNF
domain-information is the encoded information that is put into the domain-information is the encoded information that is put into the
ACP domain certificates subjectAltName / rfc822Name field. routing- ACP domain certificates subjectAltName / rfc822Name field. routing-
subdomain is a string that can be constructed from the domain- subdomain is a string that can be constructed from the domain-
information, and it is used in the hash-creation of the ULA (see information, and it is used in the hash-creation of the ULA (see
skipping to change at page 25, line 6 skipping to change at page 26, line 12
Formatting notes: Formatting notes:
o "rsub" needs to be in the "local-part": If the format just had o "rsub" needs to be in the "local-part": If the format just had
routing-subdomain as the domain part of the domain-information, routing-subdomain as the domain part of the domain-information,
rsub and acp-domain-name could not be separated from each other. rsub and acp-domain-name could not be separated from each other.
It also makes domain-information a valid e-mail target across all It also makes domain-information a valid e-mail target across all
routing-subdomains. routing-subdomains.
o "acp-address" cannot use standard IPv6 address formats because it o "acp-address" cannot use standard IPv6 address formats because it
must match the simple dot-atom format of [RFC5322]. The character has to match the simple dot-atom format of [RFC5322]. The
":" is not allowed in that format. character ":" is not allowed in that format.
o If "acp-address" is empty, and "rsub" is empty too, the "local- o If "acp-address" is empty, and "rsub" is empty too, the "local-
part" will have the format "rfcSELF++extension(s)". The two plus part" will have the format "rfcSELF++extension(s)". The two plus
characters are necessary so the node can unambiguously parse that characters are necessary so the node can unambiguously parse that
both "acp-address" and "rsub" are empty. both "acp-address" and "rsub" are empty.
o The maximum size of "domain-information" is 254 characters and the o The maximum size of "domain-information" is 254 characters and the
maximum size of local-part is 64 characters according to [RFC5280] maximum size of local-part is 64 characters according to [RFC5280]
that is referring to [RFC2821] (superseded by [RFC5321]). that is referring to [RFC2821] (superseded by [RFC5321]).
skipping to change at page 27, line 10 skipping to change at page 28, line 15
User Agent as a separator between mail subscriber and sub-mailbox. User Agent as a separator between mail subscriber and sub-mailbox.
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.3. ACP domain membership check 6.1.3. ACP domain membership check
The following points constitute the ACP domain membership check of a The following points constitute the ACP domain membership check of a
candidate peer via its certificate: candidate peer via its certificate:
1: The peer certificate is valid (lifetime). 1: The peer certificate MUST be valid (lifetime).
2: The peer has proved ownership of the private key associated with 2: The peer has proved ownership of the private key associated with
the 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.
3: The peer's certificate passes certificate path validation as 3: The peer's certificate passes certificate path validation as
defined in [RFC5280], section 6 against one of the Trust Anchors defined in [RFC5280], section 6 against one of the TA associated
associated with the ACP node's ACP domain certificate (see with the ACP node's ACP domain certificate (see Section 6.1.4
Section 6.1.4 below). below).
4: If the node certificate indicates a Certificate Revocation List 4: If the node certificate indicates a Certificate Revocation List
(CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or
Online Certificate Status Protocol (OCSP) responder ([RFC5280], Online Certificate Status Protocol (OCSP) responder ([RFC5280],
section 4.2.2.1), then the peer's certificate must be valid section 4.2.2.1), then the peer's certificate MUST be valid
according to those criteria: An OCSP check for the peer's according to those criteria: An OCSP check for the peer's
certificate across the ACP must succeed or the peer certificate certificate across the ACP MUST succeed or the peer certificate
must not be listed in the CRL retrieved from the CDP. This rule MUST not be listed in the CRL retrieved from the CDP. This rule
has to be skipped for ACP secure channel peer authentication when has to be skipped for ACP secure channel peer authentication when
the node has no ACP or non-ACP connectivity to retrieve current the node has no ACP or non-ACP connectivity to retrieve current
CRL or access an OCSP responder (and the security association CRL or access an OCSP responder (and the security association
protocol itself has also no way to communicate CRL or OCSP check). protocol itself has also no way to communicate CRL or OCSP check).
When an ACP node learns later via OCSP/CRL that an ACP peer's
certificate is invalid for which rule 4 had to be skipped during
ACP secure channel establishment, then the ACP secure channel to
that peer MUST be closed even if this peer is the only
connectivity to access CRL/OCSP. This applies (of course) to all
ACP secure channels to this peer if there are multiple. The ACP
secure channel connection MUST be retried periodically to support
the case that the neighbor aquires a new, valid certificate.
5: The peer's certificate has a syntactically valid ACP domain 5: The peer's certificate has a syntactically valid ACP domain
information field (encoded as subjectAltName / rfc822Name) and the information field (encoded as subjectAltName / rfc822Name) and the
acp-domain-name in that peer's domain information field is the acp-domain-name in that peer's domain information field is the
same as in this ACP node's certificate (lowercase normalized). same as in this ACP node's certificate (lowercase normalized).
Note: When an ACP node learns later via OCSP/CRL that an ACP peer's
certificate for which rule 4 had to be skipped during ACP secure
channel establishment is invalid, then the ACP secure channel to that
peer SHOULD be closed even if this peer is the only connectivity to
access CRL/OCSP. The ACP secure channel connection MUST be retried
periodically to support the case that the neighbor aquires a new,
valid certificate.
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:
6: The candidate peer certificate's ACP domain information field 6: The candidate peer certificate's ACP domain information field
has a non-empty acp-address field (either 32HEXDIG or 0, according has a non-empty acp-address field (either 32HEXDIG or 0, according
to Figure 2). 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 6 ensures that this is taken into account have an acp-address. Rule 6 ensures that this is taken into account
skipping to change at page 28, line 31 skipping to change at page 29, line 35
their ACP domain certificate. These ACP nodes are permitted to their ACP domain certificate. These ACP nodes are permitted to
establish ACP secure channels. Mechanisms for those nodes to establish ACP secure channels. Mechanisms for those nodes to
determine their ACP address are outside the scope of this determine their ACP address are outside the scope of this
specification, but this option is defined here so that any ACP nodes specification, but this option is defined here so that any ACP nodes
can build ACP secure channels to them according to Rule 6. can build ACP secure channels to them according to Rule 6.
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 IKEv2 [RFC7296] when security association protocols (such as Internet Key Exchange
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
such as a web servers domain name prefix often encoded in such as a web servers domain name prefix often encoded in
certificate common name. Steps 5 and 6 are the equivalent steps. certificate common name. Steps 5 and 6 are the equivalent steps.
Step 4 Constitutes standard CRL/OCSP checks refined for the case Step 4 Constitutes standard CRL/OCSP checks refined for the case
of missing connectivity and limited functionality security of missing connectivity and limited functionality security
association protocols. association protocols.
skipping to change at page 29, line 9 skipping to change at page 30, line 14
Step 6 is the additional verification of the presence of an ACP Step 6 is the additional verification of the presence of an ACP
address. address.
Steps 1...6 authorize to build an ACP secure channel. Steps 1...6 authorize to build an ACP secure channel.
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
An ACP node with a realtime clock in which it has confidence, MUST
check the time stamps when performing ACP domain membership check
such as as the certificate validity period in step 1. and the
respective times in step 4 for revocation information (e.g.:
signingTimes in CMS signatures).
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
node SHOULD obtain the current time in a secured fashion, such as via
a Network Time Protocol signalled through the ACP. It then ignores
time stamp validation only until the current time is known. In the
absence of implementing a secured mechanism, such an ACP node MAY use
a current time learned in an insecured fashion in the ACP domain
membership check.
Beside ACP domain membership check, the ACP itself has no dependency
against knowledge of the current time, but protocols and services
using the ACP will likley have the need to know the current time.
For example event logging.
6.1.4. Trust Points and Trust Anchors 6.1.4. Trust Points and Trust Anchors
ACP nodes need Trust Point (TP) certificates to perform certificate ACP nodes need Trust Point (TP) certificates to perform certificate
path validation as required by Section 6.1.3, rule 3. Trust Point(s) path validation as required by Section 6.1.3, rule 3. Trust Point(s)
must be provisioned to an ACP node (together with its ACP domain MUST be provisioned to an ACP node (together with its ACP domain
certificate) by an ACP Registrar during initial enrolment of a certificate) by an ACP Registrar during initial enrolment of a
candidate ACP node. ACP nodes MUST also support renewal of TPs via candidate ACP node. ACP nodes MUST also support renewal of TPs via
EST as described below in Section 6.1.5. Enrollment over Secure Transport (EST, see [RFC7030]), as described
below in Section 6.1.5.
Trust Point is the term used in this document for a certificate Trust Point is the term used in this document for a CA and its
authority (CA) and its associated set of certificates. Multiple associated set of certificates. Multiple certificates are required
certificates are required for a CA to deal with CA certificate for a CA to deal with CA certificate renewals as explained in
renewals as explained in Section 4.4 of CMP ([RFC4210]). Section 4.4 of CMP ([RFC4210]).
A certificate path is a chain of certificates starting at the ACP A certificate path is a chain of certificates starting at the ACP
certificate (leaf/end-entity) followed by zero or more intermediate certificate (leaf/end-entity) followed by zero or more intermediate
Trust Point or sub-CA certificates and ending with a self-signed Trust Point or sub-CA certificates and ending with a self-signed
certificate of a so called root-CA or Trust Anchor. Certificate path certificate of a so called root-CA or Trust Anchor. Certificate path
validation authenticates that the ACP certificate is signed by a validation authenticates that the ACP certificate is signed by a
Trust Anchor, directly or indirectly via one or more intermediate Trust Anchor, directly or indirectly via one or more intermediate
Trust Points. Trust Points.
Note that different ACP nodes may have different Trust Points and Note that different ACP nodes may have different Trust Points and
skipping to change at page 29, line 46 skipping to change at page 31, line 25
certificate. The protocols through which ACP domain membership check certificate. The protocols through which ACP domain membership check
rules 1-4 are performed therefore need to support the exchange not rules 1-4 are performed therefore need to support the exchange not
only of the ACP nodes certificates, but also their intermediate Trust only of the ACP nodes certificates, but also their intermediate Trust
Points. Points.
ACP nodes MUST support for the ACP domain membership check the ACP nodes MUST support for the ACP domain membership check the
certificate path validation with 0 or 1 intermediate Trust Points. certificate path validation with 0 or 1 intermediate Trust Points.
They SHOULD support 2 intermediate Trust Points and two Trust Anchors They SHOULD support 2 intermediate Trust Points and two Trust Anchors
(to permit migration to different root-CAs). (to permit migration to different root-CAs).
Trust Points for ACP domain certificates must be trusted to sign Trust Points for ACP domain certificates are trusted to sign
certificates with valid ACP domain information fields only for certificates with valid ACP domain information fields only for
trusted ACP registrars of that domain. This can be achieved by using trusted ACP registrars of that domain. This can be achieved by using
Trust Anchors private to the owner of the ACP domain or potentially Trust Anchors private to the owner of the ACP domain or potentially
through appropriate contractual agreements between the involved through appropriate contractual agreements between the involved
parties. Public CA without such obligations and guarantees can not parties. Public CA without such obligations and guarantees can not
be used. be used.
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 private trust anchors (CAs) when the ACP Registrars are same set of private trust anchors (CAs) when the ACP Registrars are
trusted not to permit certificates with incorrect ACP information trusted not to permit certificates with incorrect ACP information
fields to be signed, such as ACP information with a wrong acp-domain fields to be signed, such as ACP information with a wrong acp-domain
field. In this case, CAs can be completely unaware of ACP specifics, field. In this case, CAs can be completely unaware of ACP specifics,
so that it should be possible to use any existing CA software. When so that it should be possible to use any existing CA software. When
ACP Registrars are not to be trusted, the correctness of the ACP ACP Registrars are not to be trusted, the correctness of the ACP
domain information field for the candidate ACP node has to be domain information field for the candidate ACP node has to be
verified by the CA signing the ACP domain certificate. verified by the CA signing the ACP domain certificate.
6.1.5. Certificate and Trust Point Maintenance 6.1.5. Certificate and Trust Point Maintenance
ACP nodes MUST support renewal of their Certificate and Trust Points ACP nodes MUST support renewal of their Certificate and TPs via EST
(TP) via EST ("Enrollment over Secure Transport", see [RFC7030]) and ("Enrollment over Secure Transport", see [RFC7030]) and MAY support
MAY support other mechanisms. An ACP network MUST have at least one other mechanisms. An ACP network MUST have at least one ACP node
ACP node supporting EST server functionality across the ACP so that supporting EST server functionality across the ACP so that EST
EST renewal is useable. renewal is useable.
ACP nodes SHOULD be able to remember the EST server from which they ACP nodes SHOULD be able to remember the IPv6 locator parameters of
last renewed their ACP domain certificate and SHOULD provide the the O_IPv6_LOCATOR in GRASP of the EST server from which they last
ability for this remembered EST server to also be set by the ACP renewed their ACP domain certificate. They SHOULD provide the
ability for these EST server parameters to also be set by the ACP
Registrar (see Section 6.10.7) that initially enrolled the ACP device Registrar (see Section 6.10.7) that initially enrolled the ACP device
with its ACP domain certificate. When BRSKI (see with its ACP domain certificate. When BRSKI (see
[I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address 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..5, not rule 6 as this is not for an ACP secure channel setup). 1..5, not rule 6 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
[RFC6402] extended key usage extension and the EST client must check [RFC6402] extended key usage extension and the EST client MUST check
its presence. its presence.
The additional check against the id-kp-cmcRA extended key usage The additional check against the id-kp-cmcRA extended key usage
extension field ensures that clients do not fall prey to an illicit extension field ensures that clients do not fall prey to an illicit
EST server. While such illicit EST servers should not be able to EST server. While such illicit EST servers should not be able to
support certificate signing requests (as they are not able to elicit support certificate signing requests (as they are not able to elicit
a signing response from a valid CA), such an illicit EST server would a signing response from a valid CA), such an illicit EST server would
be able to provide faked CA certificates to EST clients that need to be able to provide faked CA certificates to EST clients that need to
renew their CA certificates when they expire. renew their CA certificates when they expire.
skipping to change at page 31, line 24 skipping to change at page 33, line 16
[M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000,
["SRV.est", 4, 255 ], ["SRV.est", 4, 255 ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fd89b714f3db0000200000064000001', TCP, 443] h'fd89b714f3db0000200000064000001', TCP, 443]
] ]
Figure 3: GRASP SRV.est example Figure 3: GRASP SRV.est example
The formal definition of the objective in Concise data definition The formal definition of the objective in Concise data definition
language (CDDL) (see [I-D.ietf-cbor-cddl]) is as follows: language (CDDL) (see [RFC8610]) is as follows:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
; see example above and explanation ; see example above and explanation
; below for initiator and ttl ; below for initiator and ttl
objective = ["SRV.est", objective-flags, loop-count, objective = ["SRV.est", objective-flags, loop-count,
objective-value] objective-value]
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in GRASP spec
skipping to change at page 32, line 42 skipping to change at page 34, line 32
information into GRASP. information into GRASP.
Renewal of certificates SHOULD start after less than 50% of the Renewal of certificates SHOULD start after less than 50% of the
domain certificate lifetime so that network operations has ample time domain certificate lifetime so that network operations has ample time
to investigate and resolve any problems that causes a node to not to investigate and resolve any problems that causes a node to not
renew its domain certificate in time - and to allow prolonged periods renew its domain certificate in time - and to allow prolonged periods
of running parts of a network disconnected from any CA. of running parts of a network disconnected from any CA.
6.1.5.3. Certificate Revocation Lists (CRLs) 6.1.5.3. Certificate Revocation Lists (CRLs)
The ACP node SHOULD support Certificate Revocation Lists (CRL) via The ACP node SHOULD support revocation through CRL(s) via HTTP from
HTTP from one or more CRL Distribution Points (CDPs). The CDP(s) one or more CRL Distribution Points (CDPs). The CDP(s) MUST be
MUST be indicated in the Domain Certificate when used. If the CDP indicated in the Domain Certificate when used. If the CDP URL uses
URL uses an IPv6 address (ULA address when using the addressing rules an IPv6 address (ULA address when using the addressing rules
specified in this document), the ACP node will connect to the CDP via specified in this document), the ACP node will connect to the CDP via
the ACP. If the CDP uses a domain name, the ACP node will connect to the ACP. If the CDP uses a domain name, the ACP node will connect to
the CDP via the Data-Plane. the CDP via the Data-Plane.
It is common to use domain names for CDP(s), but there is no It is common to use domain names for CDP(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 CDP via DNS name doubles as an indicator whether or not to reach the CDP via
skipping to change at page 36, line 45 skipping to change at page 38, line 35
Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work
and then only the following ACP secure channel setup packets - but and then only the following ACP secure channel setup packets - but
not any other unnecessary traffic (e.g., no other link-local IPv6 not any other unnecessary traffic (e.g., no other link-local IPv6
transport stack responders for example). transport stack responders for example).
Note that the use of the IPv6 link-local multicast address Note that the use of the IPv6 link-local multicast address
(ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener
Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to
receive packets for that address. Otherwise DULL GRASP could fail to receive packets for that address. Otherwise DULL GRASP could fail to
operate correctly in the presence of MLD snooping, non-ACP enabled L2 operate correctly in the presence of MLD snooping, non-ACP enabled L2
switches - because those would stop forwarding DULL GRASP packets. switches ([RFC4541]) - because those would stop forwarding DULL GRASP
Switches not supporting MLD snooping simply need to operate as pure packets. Switches not supporting MLD snooping simply need to operate
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 10.3 for further, non- across ACP virtual interfaces. See Section 10.3 for further, non-
normative suggestions on how to enable/disable ACP at node and normative suggestions on how to enable/disable ACP at node and
interface level. See Section 8.2.2 for more details about tunnels interface level. See Section 8.2.2 for more details about tunnels
(typical non-native interfaces). See Section 7 for how ACP should be (typical non-native interfaces). See Section 7 for how ACP should be
extended on devices operating (also) as L2 bridges. extended on devices operating (also) as L2 bridges.
Note: If an ACP node also implements BRSKI to enroll its ACP domain Note: If an ACP node also implements BRSKI to enroll its ACP domain
skipping to change at page 37, line 25 skipping to change at page 39, line 15
discover both a bootstrap proxy and ACP neighbor at the same time. discover both a bootstrap proxy and ACP neighbor at the same time.
An ACP node announces itself to potential ACP peers by use of the An ACP node announces itself to potential ACP peers by use of the
"AN_ACP" objective. This is a synchronization objective intended to "AN_ACP" objective. This is a synchronization objective intended to
be flooded on a single link using the GRASP Flood Synchronization be flooded on a single link using the GRASP Flood Synchronization
(M_FLOOD) message. In accordance with the design of the Flood (M_FLOOD) message. In accordance with the design of the Flood
message, a locator consisting of a specific link-local IP address, IP message, a locator consisting of a specific link-local IP address, IP
protocol number and port number will be distributed with the flooded protocol number and port number will be distributed with the flooded
objective. An example of the message is informally: objective. An example of the message is informally:
[M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 210000, [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000,
["AN_ACP", 4, 1, "IKEv2" ], ["AN_ACP", 4, 1, "IKEv2" ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80000000000000c0011001FEEF0000, UDP, 15000] h'fe80000000000000c0011001feef0000', UDP, 15000]
["AN_ACP", 4, 1, "DTLS" ], ["AN_ACP", 4, 1, "DTLS" ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80000000000000c0011001FEEF0000, UDP, 17000] h'fe80000000000000c0011001feef0000', UDP, 17000]
] ]
Figure 5: GRASP AN_ACP example Figure 5: GRASP AN_ACP example
The formal CDDL definition is: The formal CDDL definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_ACP", objective-flags, loop-count, objective = ["AN_ACP", objective-flags, loop-count,
objective-value] objective-value]
skipping to change at page 38, line 16 skipping to change at page 40, line 7
The loop-count is fixed at 1 since this is a link-local operation. The loop-count is fixed at 1 since this is a link-local operation.
In the above example the RECOMMENDED period of sending of the In the above example the RECOMMENDED period of sending of the
objective is 60 seconds. The indicated ttl of 210000 msec means that objective is 60 seconds. The indicated ttl of 210000 msec means that
the objective would be cached by ACP nodes even when two out of three the objective would be cached by ACP nodes even when two out of three
messages are dropped in transit. messages are dropped in transit.
The session-id is a random number used for loop prevention The session-id is a random number used for loop prevention
(distinguishing a message from a prior instance of the same message). (distinguishing a message from a prior instance of the same message).
In DULL this field is irrelevant but must still be set according to In DULL this field is irrelevant but has to be set according to the
the GRASP specification. GRASP specification.
The originator MUST be the IPv6 link local address of the originating The originator MUST be the IPv6 link local address of the originating
ACP node on the sending interface. ACP node on the sending interface.
The 'objective-value' parameter is a string indicating the protocol The 'objective-value' parameter is a string indicating the protocol
available at the specified or implied locator. It must be a protocol available at the specified or implied locator. It is a protocol
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 abbreviation for "Internet Key Exchange protocol IKEv2 is the actual protocol used to negotiate an Internet Protocol
version 2". It is the main protocol used by the Internet IP security security architecture (IPsec) connection. GRASP therefore indicates
architecture (IPsec). We therefore use the term "IKEv2" and not "IKEv2" and not "IPsec". If "IPsec" was used, this too could mean
"IPsec" in the GRASP definitions and example above. "IKEv2" has a use of the obsolete older version IKE (v1) ([RFC2409]). IKEv2 has am
well-defined port number 500, but in the above example, the candidate IANA assigned port number 500, but in the above example, the
ACP neighbor is offering ACP secure channel negotiation via IKEv2 on candidate ACP neighbor is offering ACP secure channel negotiation via
port 15000 (for the sake of creating a non-standard example). 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
IANA assigned one).
"DTLS" indicates datagram Transport Layer Security version 1.2. "DTLS" indicates DTLS version 1.2. This can also be a newer version
There is no default UDP port, it must always be locally assigned by of the protocol as long as it can negotiate down to version 1.2 in
the node. See Section 6.7.2. the presence of a peer only speaking DTLS version 1.2. There is no
default UDP port for DTLS, it is always locally assigned by the node.
For details, see Section 6.7.4.
If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6
address MUST be the same as the initiator address (these are DULL address MUST be the same as the initiator address (these are DULL
requirements to minimize third party DoS attacks). requirements to minimize third party DoS attacks).
The secure channel methods defined in this document use the The secure channel methods defined in this document use the
objective-values of "IKEv2" and "DTLS". There is no distinction objective-values of "IKEv2" and "DTLS". There is no distinction
between IKEv2 native and GRE-IKEv2 because this is purely negotiated between IKEv2 native and GRE-IKEv2 because this is purely negotiated
via IKEv2. via IKEv2.
skipping to change at page 39, line 33 skipping to change at page 41, line 28
include ACP nodes ACP domain certificate even though this would be include ACP nodes ACP domain certificate even though this would be
useful for diagnostics and to simplify the security exchange in ACP useful for diagnostics and to simplify the security exchange in ACP
secure channel security association protocols (see Section 6.7). The secure channel security association protocols (see Section 6.7). The
reason is that DULL GRASP messages are periodically multicasted reason is that DULL GRASP messages are periodically multicasted
across IPv6 subnets and full certificates could easily lead to across IPv6 subnets and full certificates could easily lead to
fragmented IPv6 DULL GRASP multicast packets due to the size of a fragmented IPv6 DULL GRASP multicast packets due to the size of a
certificate. This would be highly undesirable. certificate. This would be highly undesirable.
6.4. Candidate ACP Neighbor Selection 6.4. Candidate ACP Neighbor Selection
An ACP node must determine to which other ACP nodes in the adjacency An ACP node determines to which other ACP nodes in the adjacency
table it should build an ACP connection. This is based on the table it should attempt to build an ACP connection. This is based on
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.
The result of the candidate ACP neighbor selection process is a list The result of the candidate ACP neighbor selection process is a list
of adjacent or configured autonomic neighbors to which an ACP channel of adjacent or configured autonomic neighbors to which an ACP channel
should be established. The next step begins that channel should be established. The next step begins that channel
establishment. establishment.
skipping to change at page 40, line 20 skipping to change at page 42, line 14
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 but just mentioned as a
likely next interesting secure channel protocol. likely next interesting secure channel protocol.
To support extensible secure channel protocol selection without a To support extensible secure channel protocol selection without a
single common MTI protocol, ACP nodes must try all the ACP secure single common mandatory to implement (MTI) protocol, ACP nodes MUST
channel protocols it supports and that are feasible because the try all the ACP secure channel protocols it supports and that are
candidate ACP neighbor also announced them via its AN_ACP GRASP feasible because the candidate ACP neighbor also announced them via
parameters (these are called the "feasible" ACP secure channel its AN_ACP GRASP parameters (these are called the "feasible" ACP
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 must be used by all know each other's certificates because they are used by all secure
secure channel protocols for mutual authentication. The node with channel protocols for mutual authentication. The node with the
the lower Node-ID in the ACP address of its ACP domain certificate lower Node-ID in the ACP address of its ACP domain certificate
becomes Bob, the one with the higher Node-ID in the certificate becomes Bob, the one with the higher Node-ID in the certificate
Alice. A peer with an empty ACP address field in its ACP domain Alice. A peer with an empty ACP address field in its ACP domain
certificate becomes Bob (this specification does not define such certificate becomes Bob (this specification does not define such
peers, only the interoperability with them). peers, only 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
skipping to change at page 42, line 5 skipping to change at page 44, line 5
connection setup is completed. The protocol could for example be connection setup is completed. The protocol could for example be
IPsec via IKEv2 ("IP security", see [RFC4301] and "Internet Key IPsec via IKEv2 ("IP security", see [RFC4301] and "Internet Key
Exchange protocol version 2", see [RFC7296]. It is now up to Alice Exchange protocol version 2", see [RFC7296]. It is now up to Alice
to decide how to proceed. Even if the IPsec connection from Bob to decide how to proceed. Even if the IPsec connection from Bob
succeeded, Alice might prefer another secure protocol over IPsec succeeded, Alice might prefer another secure protocol over IPsec
(e.g., FOOBAR), and try to set that up with Bob. If that preference (e.g., FOOBAR), and try to set that up with Bob. If that preference
of Alice succeeds, she would close the IPsec connection. If no of Alice succeeds, she would close the IPsec connection. If no
better protocol attempt succeeds, she would keep the IPsec better protocol attempt succeeds, she would keep the IPsec
connection. connection.
The following sequence of steps show this example in more detail: The following sequence of steps show this example in more detail.
Each step is tagged with [<step#>{:<connection>}]. The connection is
included to easier distinguish which of the two competing connections
the step belong to, one initiated by Node 1, one initiated by Node 2.
[1] Node 1 sends GRASP AN_ACP message to announce itself [1] Node 1 sends GRASP AN_ACP message to announce itself
[2] Node 2 sends GRASP AN_ACP message to announce itself [2] Node 2 sends GRASP AN_ACP message to announce itself
[3] Node 2 receives [1] from Node 1 [3] Node 2 receives [1] from Node 1
[4:C1] Because of [3], Node 2 starts as initiator on its [4:C1] Because of [3], Node 2 starts as initiator on its
preferred secure channel protocol towards Node 1. preferred secure channel protocol towards Node 1.
Connection C1. Connection C1.
skipping to change at page 43, line 24 skipping to change at page 45, line 27
certificate. This implies that any secure channel protocol MUST certificate. This implies that any secure channel protocol MUST
support certificate based authentication that can support the ACP support certificate based authentication that can support the ACP
domain membership check as defined in Section 6.1.3. If it fails, domain membership check as defined in Section 6.1.3. If it fails,
the connection attempt is aborted and an error logged. Attempts to the connection attempt is aborted and an error logged. Attempts to
reconnect MUST be throttled. The RECOMMENDED default is exponential reconnect MUST be throttled. The RECOMMENDED default is exponential
base 2 backoff with a minimum delay of 10 seconds and a maximum delay base 2 backoff with a minimum delay of 10 seconds and a maximum delay
of 640 seconds. of 640 seconds.
6.7. Security Association (Secure Channel) protocols 6.7. Security Association (Secure Channel) protocols
This section describes how ACP nodes establish secured data
connections to automatically discovered or configured peers in the
ACP. Section 6.3 above described how IPv6 subnet adjacent peers are
discovered automatically. Section 8.2 describes how non IPv6 subnet
adjacent peers can be configured.
Section 6.12.5.2 describes how secure channels are mapped to virtual
IPv6 subnet interfaces in the ACP. The simple case is to map every
ACP secure channel into a separate ACP point-to-point virtual
interface Section 6.12.5.2.1. When a single subnet has multiple ACP
peers this results in multiple ACP point-to-point virtual interfaces
across that underlying multi-party IPv6 subnet. This can be
optimized with ACP multi-access virtual interfaces Section 6.12.5.2.2
but the benefits of that optimization may not justify the complexity
of that option.
6.7.1. General considerations
Due to Channel Selection (Section 6.5), ACP can support an evolving Due to Channel Selection (Section 6.5), ACP can support an evolving
set of security association protocols. These protocols only need to set of security association protocols. These protocols only need to
be used to establish secure channels with L2 adjacent ACP neighbors be used to establish secure channels with L2 adjacent ACP neighbors
and only optionally (where needed) across non-ACP capable L3 network and only optionally (where needed) across non-ACP capable L3 network
(see Section 8.2). Therefore, there is architecturally no need for (see Section 8.2). Therefore, there is architecturally no need for
any network wide mandatory to implement (MTI) security association any network wide MTI security association protocols. Instead, ACP
protocols. Instead, ACP nodes only need to implement those protocols nodes only need to implement those protocols required to interoperate
required to be supported by their neighbors. See Section 6.7.3 for with their candidate peers, not with potentially any node in the ACP
an example of this. domain. See Section 6.7.5 for an example of this.
The degree of security required on every hop of an ACP network needs
to be consistent across the network so that there is no designated
"weakest link" because it is that "weakest link" that would otherwise
become the designated point of attack. When the secure channel
protection on one link is compromised, it can be used to send/receive
packets across the whole ACP network. Therefore, even though the
security association protocols can be different, their minimum degree
of security should be comparable.
Secure channel protocols do not need to always support arbitrary L3
connectivity between peers, but can leverage the fact that the
standard use case for ACP secure channels is an L2 adjacency. Hence,
L2 mechanism dependent mechanisms could be adopted for use as secure
channel association protocols:
L2 mechanisms such as strong encrypted radio technologies or [MACSEC]
may offer equivalent encryption and the ACP security association
protocol may only be required to authenticate ACP domain membership
of a peer and/or derive a key for the L2 mechanism. Mechanisms to
auto-discover and associate ACP peers leveraging such underlying L2
security are possible and desirable to avoid duplication of
encryption, but none are specified in this document.
Strong physical security of a link may stand in where cryptographic
security is infeasible. As there is no secure mechanism to
automatically discover strong physical security solely between two
peers, it can only be used with explicit configuration and that
configuration too could become an attack vector. This document
therefore only specifies with ACP connect (Figure 15) one explicitly
configured mechanism without any secure channel association protocol
- for the case where both the link and the nodes attached to it have
strong physical security.
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 domain certificate according to Section 6.1.3. Because
auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3) auto-discovery of candidate ACP neighbors via GRASP (see Section 6.3)
as specified in this document does not communicate the neighbors ACP as specified in this document does not communicate the neighbors ACP
domain certificate, and ACP nodes may not (yet) have any other domain certificate, and ACP nodes may not (yet) have any other
network connectivity to retrieve certificates, any security network connectivity to retrieve certificates, any security
association protocol MUST use a mechanism to communicate the association protocol MUST use a mechanism to communicate the
certificate directly instead of relying on a referential mechanism certificate directly instead of relying on a referential mechanism
such as communicating only a hash and/or URL for the certificate. such as communicating only a hash and/or URL for the certificate.
Any security association protocol MUST provide Forward Secrecy A security association protocol MUST use Forward Secrecy (whether
(whether inherently or as part of a profile of the security inherently or as part of a profile of the security association
association protocol). protocol).
The degree of security required on every hop of an ACP network needs
to be consistent across the network so that there is no designated
"weakest link" because it is that "weakest link" that would otherwise
become the designated point of attack. When the secure channel
protection on one link is compromised, it can be used to send/receive
packets across the whole ACP network. This principle does not imply
that the requirements against ACP security association protocols have
to be the same across all subnets in an ACP network:
o Underlying L2 mechanisms such as strong encrypted radio Because the ACP payload of legacy protocol payloads inside the ACP
technologies or [MACSEC] may offer equivalent encryption and the and hop-by-hop ACP flooded GRASP information is unencrypted, the ACP
ACP security association protocol may only be required to secure channel protocol requires confidentiality. Symmetric
authenticate ACP domain membership of a peer and/or derive a key encryption for the transmission of secure channel data MUST use
for the L2 mechanism. Mechanisms to auto-discover and associate encryption schemes considered to be security wise equal to or better
ACP peers leveraging such underlying L2 security are possible and than AES256. There MUST NOT be support for NULL encryption.
desirable to avoid duplication of encryption, but none are
specified in this document.
o Strong physical security of a link may stand in where An ACP secure channel MUST immediately be terminated when the
cryptographic security is infeasible. As there is no secure lifetime of any certificate in the chain used to authenticate the
mechanism to automatically discover strong physical security neighbor expires or becomes revoked. This may not be standard
solely between two peers, it can only be used with explicit behavior in secure channel protocols because the certificate
configuration and that configuration too could become an attack authentication may only influences the setup of the secure channel in
vector. This document therefore only specifies with ACP connect these protocols, but may not be re-validated during the lifetime of
(Figure 15) one explicitly configured mechanism without any secure the secure connection in the absence of this requirement.
channel association protocol - for the case where both the link
and the nodes attached to it have strong physical security.
The following sub-sections define the security association protocols When introducing the profile for a security association protocol in
that are considered to be important and feasible to specify in this support of the ACP, protocol options SHOULD be eliminated that do not
document. provide benefits for devices that should be able to support the ACP.
For example, definitions for security protocols often include old/
inferior security options required only to interoperate with existing
devices that will not be a able to update to the currently preferred
security options. Such old/inferior security options do not need to
be supported when a security association protocol is first specified
for the ACP, strengthening the "weakest link" and simplifying ACP
implementation overhead.
6.7.1. 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 narrow profile of the The ACP usage of IPsec and IKEv2 mandates a narrow profile of the
current standards-track usage guidance for IPsec [RFC8221] and IKEv2 current standards-track usage guidance for IPsec [RFC8221] and IKEv2
[RFC8247]. This profile provides for stringent security properties [RFC8247]. This profile provides for stringent security properties
and can exclude deprecated/legacy algorithms because there is no need and can exclude deprecated/legacy algorithms because there is no need
for interoperability with legacy equipment for ACP secure channels. for interoperability with legacy equipment for ACP secure channels.
Any such backward compatibility would lead only to increased attack Any such backward compatibility would lead only to increased attack
surface and implementation complexity, for no benefit. surface and implementation complexity, for no benefit.
6.7.1.1. Native IPsec 6.7.3.1. Native IPsec
To run ACP via IPsec natively, no further IANA assignments/
definitions are required.
An ACP node that is supporting native IPsec MUST use IPsec in tunnel An ACP node that is supporting native IPsec MUST use IPsec in tunnel
mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next
Header of 41). It MUST use local and peer link-local IPv6 addresses Header of 41). It MUST use local and peer link-local IPv6 addresses
for encapsulation. Manual keying MUST NOT be used, see Section 6.1. for encapsulation. Manual keying MUST NOT be used, see Section 6.1.
IPsec tunnel mode is required because the ACP will route/forward IPsec tunnel mode is required because the ACP will route/forward
packets received from any other ACP node across the ACP secure packets received from any other ACP node across the ACP secure
channels, and not only its own generated ACP packets. With IPsec channels, and not only its own generated ACP packets. With IPsec
transport mode, it would only be possible to send packets originated transport mode, it would only be possible to send packets originated
by the ACP node itself. by the ACP node itself.
6.7.1.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), with the following modifications to simplify hardware updates). The requirements from above and this section amend and
accelerated ACP IPsec implementation requirements by eliminating superceed its requirements.
requirements for legacy or cryptographically weak options.
ACP MUST NOT use any NULL encryption option due to the AH MUST NOT be used (because it does not provide confidentiality).
confidentiality of ACP payload that may not be encrypted by itself
when carrying legacy management protocol traffics as well as hop-by-
hop GRASP, which is designed to rely on the ACP for confidentiality
of hop-by-hop distributed information. Therefore, IPsec MUST support
ESP and MUST NOT use AH. For ESP, ENCR_NULL MUST NOT be used for ACP
secure channels.
Only ENCR_AES_GCM_16 is REQUIRED as an encryption algorithm for ACP For the required ESP encryption algorithms in section 5 of [RFC8221]
secure channels with ESP. the following guidance applies:
If an ACP node can perform ENCR_AES_CBC, ENCR_AES_CCM_8 at higher o ENCR_NULL AH MUST NOT be used (because it does not provide
performance than ENCR_AES_GCM_16 or ENCR_CHACHA20_POLY1305 at equal confidentiality).
or higher performance than ENCR_AES_GCM_16 then that ACP node SHOULD
support such an encryption algorithm and prefer it in the IKEv2
negotiation if its performance is higher than that of
ENCR_AES_GCM_16. Otherwise there are no normative requirements
against either of these options. These requirements are overriding
the MUST/SHOULD/SHOULD requirements of [RFC8221] for these three
algorithms for the following reasons:
o There is no unconditional requirement against ENCR_AES_CBC because o ENCR_AES_GCM_16 is the only MTI ESP encryption algorithm for ACP
via IPsec/ESP (it is already listed as MUST in [RFC8221]).
* ENCR_AES_GCM_16 is assumed to be feasible with less cost/higher o ENCR_AES_CBC and ENCR_AES_CCM_8 MAY be supported. If either
higher performance in modern devices hardware accelerated provides higher performance than ENCR_AES_GCM_16 it SHOULD be
implementations compared to ENCR-AES_CBC. supported.
* AES-GCM is an authenticated encryption with associated data o ENCR_CHACHA20_POLY1305 SHOULD be supported at equal or higher
(AEAD) cipher mode, so no ESP authentication algorithm performance than ENCR_AES_GCM_16. If that performance is not
requirement is needed (unless further encryption algorithms are feasible, it MAY be supported.
supported), further simplifying ACP IPsec implementations.
* there is no requirement to interoperate with legacy equipment IKEv2 indicates an order for the offered algorithms. The algorithms
in ACP secure channels, so a single MTI encryption algorithm SHOULD be ordered by performance. The first algorithm supported by
for IPsec in ACP secure channels is sufficient for both sides is generally choosen.
interoperability.
o There is no unconditional requirement against ENCR_AES_CCM_8 Explanations:
because it is currently not likely that it would be preferrable in
ACP secure channels for more constrained IoT devices over options
such as DTLS. In [RFC8221] this algorithm is more desirable,
because of solutions relying only on IPsec without such non-IPsec
alternatives.
o There is no unconditional requirement against o There is no requirement to interoperate with legacy equipment in
ENCR_CHACHA20_POLY1305 because there is currently no mechanism in ACP secure channels, so a single MTI encryption algorithm for
the ACP to migrate all secure channels in an ACP domain to a IPsec in ACP secure channels is sufficient for interoperability
different preferred encryption algorithm in the case of future and allows for the most lightweight implementations.
discovered crypto weaknesses of AES. Once such mechanisms are
defined, ENCR_CHACHA20_POLY1305 would be a good encryption
algorithm, but due to the transitive traffic through ACP secure
channels only when this does not result in an unexpected drop in
performance.
When using AES for encryption, keys less than 256 bits MUST NOT be o ENCR_AES_GCM_16 is an authenticated encryption with associated
used, and 256-bit keys MUST be supported. data (AEAD) cipher mode, so no additional ESP authentication
algorithm is needed, simplifying the MTI requirements of IPsec for
the ACP.
Once there are updates to [RFC8221], these should accordingly be o There is no MTI requirement against support of ENCR_AES_CBC
reflected in updates to these ACP requirements, for example if because ENCR_AES_GCM_16 is assumed to be feasible with less cost/
ENCR_AES_GCM_16 was to be superceeded in the future. higher performance in modern devices hardware accelerated
implementations compared to ENCR-AES_CBC.
6.7.1.1.2. RFC847 (IKEv2) o ENCR_CHACHA20_POLY1305 is mandatory in [RFC8221] because of its
target use as a fallback algorithm in case weaknesses in AES are
uncoverered. Unfortunately, there is currently no way to
automatically propagate across an ACP a policy to disallow use of
AES based algorithms, so this target benefit of
ENCR_CHACHA20_POLY1305 can not fully be adopted yet for the ACP.
Therefore this algorithm is only recommended. Changing from AES
to this algorithm at potentially big drop in performance could
also render the ACP inoperable. Therefore the performance
requirement against this algorithm so that it could become an
effective security backup to AES for the ACP once a policy to
switch over to it or prefer it is available in an ACP framework.
IKEv2 for ACP secure channels MUST support the requirements of [RFC8221] allows for 128-bit or 256-bit AES keys. This document
[RFC8247] (as necessary to support the above described modified mandates that only 256-bit AES keys MUST be supported.
[RFC8221] requirements for IPsec via ESP). Because IKEv2 for ACP
secure channels is sufficient to be implemented in control plane
software as opposed to ESP (which may need to be implemented in
accelerated forwarding plane for sufficient performance), there are
no restrictions on the requirements of [RFC8247] for ACP secure
channels. Instead, the following paragraphs describe additional or
stricter requirements necessary for the authentication of ACP secure
channels in IKEv2 via ACP domain certificates.
IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP) MUST When [RFC8221] is updated, ACP implementations will need to consider
be supported (in addition to 2048-bit MODP). ECC provides a similar legacy interoperability, and the IPsec WG has generally done a very
security level to finite-field (MODP) key exchange with a shorter key good job of taking that into account in its recommendations.
length, so is generally preferred absent other considerations.
6.7.3.1.2. RFC847 (IKEv2)
[RFC8247] provides a baseline recommendation for mandatory to
implement ciphers, integrity checks, pseudo-random-functions and
Diffie-Hellman mechanisms. Those recommendations, and the
recommendations of subsequent documents apply well to the ACP.
Because IKEv2 for ACP secure channels is sufficient to be implemented
in control plane software, rather than in ASIC hardware, and ACP
nodes supporting IKEv2 are not assumed to be code-space constrained,
and because existing IKEv2 implementations are expected to support
[RFC8247] recommendations, this documents makes no attempt to
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.
The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP),
listed as a SHOULD, is to be configured, along with the 2048-bit MODP
(group 14). ECC provides a similar security level to finite-field
(MODP) key exchange with a shorter key length, so is generally
preferred absent other considerations.
IKEv2 authentication MUST use the ACP domain certificates. The IKEv2 authentication MUST use the ACP domain certificates. The
Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be
supported (see [IKEV2IANA] for this and other IANA IKEv2 parameter supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter
names used in this text). If certificate chains are used, all names used in this text.
intermediate certificates up to, but not including the locally
provisioned trust anchor certificate must be signaled.
A certificate payload with the ACP certificate MUST be included A certificate payload with the ACP certificate MUST be included
during IKEv2 authentication to support the ACP domain membership during IKEv2 authentication to support the ACP domain membership
check as described in Section 6.1.3, because it is using additional check as described in Section 6.1.3, because it is using additional
elements of the ACP certificates. ACP peers are expected to have the elements of the ACP certificates.
same set of Trust Anchors (TA), so a certificate path MUST only be
included in the signaled payload when the path contains intermediate If certificate chains are used, all intermediate certificates up to,
certificates not in the TA set, such as sub-CAs (see Section 6.10.7). and including the locally provisioned trust anchor certificate MUST
be signaled. See Section 6.10.7 for the sub-CA example in which
certificate chains are used.
While the top-trust anchor will never be used by an ACP peer with
proper provisioned ACP TAs, it can provide a significant amount of
useful information to debug an ACP network. There is some small
concern that this might provide useful information to an attacker
about who the network is, but the other certificates that are sent
already clearly indicate this information.
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 domain certificate
includes an ACP address in the ACP domain information field (not "0" includes an ACP address in the ACP domain information field (not "0"
or empty), the address in the IKEv2 identification payload must match or empty), the address in the IKEv2 identification payload MUST match
it. See Section 6.1.3 for more information about "0" or empty ACP it. See Section 6.1.3 for more information about "0" or empty ACP
address fields in the ACP domain information field. address fields in the ACP domain information field.
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, as indicated by a PKIX- used with both RSA and ECDSA certificates, as indicated by a PKIX-
style OID. style OID.
The Digital Signature hash SHA2-512 MUST be supported (in addition to The Digital Signature hash SHA2-512 MUST be supported (in addition to
SHA2-256). SHA2-256).
6.7.1.2. IPsec with GRE encapsulation 6.7.3.2. IPsec with GRE encapsulation
In network devices it is often more common to implement high In network devices it is often more common to implement high
performance virtual interfaces on top of GRE encapsulation than on performance virtual interfaces on top of GRE encapsulation than on
top of a "native" IPsec association (without any other encapsulation top of a "native" IPsec association (without any other encapsulation
than those defined by IPsec). On those devices it may be beneficial than those defined by IPsec). On those devices it may be beneficial
to run the ACP secure channel on top of GRE protected by the IPsec to run the ACP secure channel on top of GRE protected by the IPsec
association. association.
To run ACP via GRE/IPsec, no further IANA assignments/definitions are
required.
The requirements for ESP/IPsec/IKEv2 are the same as for native IPsec The requirements for ESP/IPsec/IKEv2 are the same as for native IPsec
(see Section 6.7.1.1) except that IPsec transport mode and next (see Section 6.7.3.1) except that IPsec transport mode and next
protocol GRE (47) are to be negotiated. Tunnel mode is not required protocol GRE (47) are to be negotiated. Tunnel mode is not required
because of GRE. because of GRE.
If IKEv2 initiator and responder support IPsec over GRE, it has to be If IKEv2 initiator and responder support IPsec over GRE, it has to be
preferred over native IPsec. The ACP IPv6 traffic has to be carried preferred over native IPsec. The ACP IPv6 traffic has to be carried
across GRE according to [RFC7676]. across GRE according to [RFC7676].
6.7.2. ACP via DTLS 6.7.4. ACP via DTLS
We define the use of ACP via DTLS in the assumption that it is likely We define the use of ACP via DTLS in the assumption that it is likely
the first transport encryption supported in some classes of the first transport encryption supported in some classes of
constrained devices. constrained devices because DTLS is already used in those devices but
IPsec is not, and code-space may be limited.
An ACP node announces its ability to support DTLS (as described here) An ACP node announces its ability to support DTLS v1.2 compliant with
as an ACP secure channel protocol in GRASP through the "DTLS" the requirements defined in this document as an ACP secure channel
objective-value in the "AN_ACP" objective. protocol in GRASP through the "DTLS" objective-value in the "AN_ACP"
objective.
To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP To run ACP via UDP and DTLS v1.2 [RFC6347], a locally assigned UDP
port is used that is announced as a parameter in the GRASP AN_ACP port is used that is announced as a parameter in the GRASP AN_ACP
objective to candidate neighbors. objective to candidate neighbors. This port can also be any newer
version of DTLS as long as that version can negotiate a DTLS v1.2
connection in the presence of an DTLS v1.2 only peer.
All ACP nodes supporting DTLS as a secure channel protocol MUST All ACP nodes supporting DTLS as a secure channel protocol MUST
adhere to the DTLS implementation recommendations and security adhere to the DTLS implementation recommendations and security
considerations of BCP 195 [RFC7525] except with respect to the DTLS considerations of BCP 195 [RFC7525] except with respect to the DTLS
version. ACP nodes supporting DTLS MUST implement only DTLS 1.2 or version. ACP nodes supporting DTLS MUST support DTLS 1.2. They MUST
later. For example, implementing DTLS-1.3 ([I-D.ietf-tls-dtls13]) is NOT support older versions of DTLS. Implementation MUST comply with
also an option. BCP 195, [RFC7525].
Unlike for IPsec, no attempts are made to simplify the requirements
of the BCP 195 recommendations because the expectation is that DTLS
would be using software-only implementations where the ability to
reuse of widely adopted implementations is more important than
minizing the complexity of a hardware accelerated implementation
which is known to be important for IPsec.
DTLS v1.3 ([I-D.ietf-tls-dtls13]) is "backward compatible" with DTLS
v1.2 (see section 1. of DTLS v1.3): A DTLS implementation supporting
both DTLS v1.2 and DTLS v1.3 does comply with the above requirements
of negoting to DTLS v1.2 in the presence of a DTLS v1.2 only peer,
but using DTLS v1.3 when booth peers support it.
Version v1.2 is the MTI version of DTLS in this specification because
o There is more experience with DTLS v1.2 across the spectrum of
target ACP nodes.
o Firmware of lower end, embedded ACP nodes may not support a newer
version for a long time.
o There are significant changes of DTLS v1.3, such as a different
record layer requiring time to gain implementation and deployment
experience especially on lower end, code space limited devices.
o The existing BCP [RFC7525] for DTLS v1.2 may equally take longer
time to be updated with experience from a newer DTLS version.
o There are no significant use-case relevant benefits of DTLS v1.3
over DTLS v1.2 in the context of the ACP profile for DTLS. For
example, signaling performance improvements for session setup in
DTLS v1.3 is not important for the ACP given the long-lived nature
of ACP secure channel connections and the fact that DTLS
connections are mostly link-local (short RTT).
Nevertheless, newer versions of DTLS, such as DTLS v1.3 have more
strict security requirements and use of the latest standard protocol
version is for IETF security standards in general recommended.
Therefore, ACP implementations are advised to support all the newer
versions of DTLS that can still negotiate down to DTLS v1.2.
[RFC-editor: if by the time of AUTH48, DTLS 1.3 would have evolved to
be an RFC, then not only would the references to the DTLS v1.3 draft
be changed to the RFC number, but that RFC is then going to be put
into the normative list of references and the above paragraph is
going to be amended to say: Implementations SHOULD support
[DTLSv1.3-RFC]. This is not done right now, because there is no
benefit in potentially waiting in RFC-editor queue for that RFC given
how the text alreayd lays out a non-nrmative desire to support
DTLSv1.3.]
There is no additional session setup or other security association There is no additional session setup or other security association
besides this simple DTLS setup. As soon as the DTLS session is besides this simple DTLS setup. As soon as the DTLS session is
functional, the ACP peers will exchange ACP IPv6 packets as the functional, the ACP peers will exchange ACP IPv6 packets as the
payload of the DTLS transport connection. Any DTLS defined security payload of the DTLS transport connection. Any DTLS defined security
association mechanisms such as re-keying are used as they would be association mechanisms such as re-keying are used as they would be
for any transport application relying solely on DTLS. for any transport application relying solely on DTLS.
6.7.3. ACP Secure Channel Requirements 6.7.5. ACP Secure Channel Profiles
As explained in the beginning of Section 6.5, there is no single As explained in the beginning of Section 6.5, there is no single
secure channel mechanism mandated for all ACP nodes. Instead, this secure channel mechanism mandated for all ACP nodes. Instead, this
section defines two ACP profiles (baseline and constrained) for ACP section defines two ACP profiles (baseline and constrained) for ACP
nodes that do introduce such requirements. nodes that do introduce such requirements.
A baseline ACP node MUST support IPsec natively and MAY support IPsec A baseline ACP node MUST support IPsec natively and MAY support IPsec
via GRE. A constrained ACP node that cannot support IPsec MUST via GRE. A constrained ACP node that cannot support IPsec MUST
support DTLS. An ACP node connecting an area of constrained ACP support DTLS. An ACP node connecting an area of constrained ACP
nodes with an area of baseline ACP nodes must therefore support IPsec nodes with an area of baseline ACP nodes needs to support IPsec and
and DTLS and supports therefore the baseline and constrained profile. DTLS and supports therefore the baseline and constrained profile.
Explanation: Not all type of ACP nodes can or need to connect Explanation: Not all type of ACP nodes can or need to connect
directly to each other or are able to support or prefer all possible directly to each other or are able to support or prefer all possible
secure channel mechanisms. For example, code space limited IoT secure channel 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 high-end core routers may not want them for end-to-end security, but high-end core routers may not want
to support DTLS because they can perform IPsec in accelerated to support DTLS because they can perform IPsec in accelerated
hardware but would need to support DTLS in an underpowered CPU hardware but would need to support DTLS in an underpowered CPU
forwarding path shared with critical control plane operations. This forwarding path shared with critical control plane operations. This
is not a deployment issue for a single ACP across these type of nodes is not a deployment issue for a single ACP across these type of nodes
skipping to change at page 49, line 25 skipping to change at page 53, line 38
sufficiently many secure channel mechanisms to allow interconnecting sufficiently many secure channel mechanisms to allow interconnecting
areas of ACP nodes with a more constrained set of secure channel areas of ACP nodes with a more constrained set of secure channel
protocols. On the edge between IoT areas and high-end core networks, protocols. On the edge between IoT areas and high-end core networks,
general-purpose routers that act as those gateways and that can general-purpose routers that act as those gateways and that can
support a variety of secure channel protocols is the norm already. support a variety of secure channel protocols is the norm already.
ACP nodes need to specify in documentation the set of secure ACP ACP nodes need to specify in documentation the set of secure ACP
mechanisms they support and should declare which profile they support mechanisms they support and should declare which profile they support
according to above requirements. according to above requirements.
An ACP secure channel MUST immediately be terminated when the
lifetime of any certificate in the chain used to authenticate the
neighbor expires or becomes revoked. Note that this is not standard
behavior in secure channel protocols such as IPsec because the
certificate authentication only influences the setup of the secure
channel in these protocols.
6.8. GRASP in the ACP 6.8. GRASP in the ACP
6.8.1. GRASP as a core service of the ACP 6.8.1. GRASP as a core service of the ACP
The ACP MUST run an instance of GRASP inside of it. It is a key part The ACP MUST run an instance of GRASP inside of it. It is a key part
of the ACP services. The function in GRASP that makes it fundamental of the ACP services. The function in GRASP that makes it fundamental
as a service of the ACP is the ability to provide ACP wide service as a service of the ACP is the ability to provide ACP wide service
discovery (using objectives in GRASP). discovery (using objectives in GRASP).
ACP provides IP unicast routing via the RPL routing protocol (see ACP provides IP unicast routing via the RPL routing protocol (see
skipping to change at page 50, line 29 skipping to change at page 54, line 34
the node has a domain certificate, and continues to exist even if all the node has a domain certificate, and continues to exist even if all
of its neighbors cease operation. of its neighbors cease operation.
In this case ASAs using GRASP running on the same node would still In this case ASAs using GRASP running on the same node would still
need to be able to discover each other's objectives. When the ACP need to be able to discover each other's objectives. When the ACP
does not exist, ASAs leveraging the ACP instance of GRASP via APIs does not exist, ASAs leveraging the ACP instance of GRASP via APIs
MUST still be able to operate, and MUST be able to understand that MUST still be able to operate, and MUST be able to understand that
there is no ACP and that therefore the ACP instance of GRASP cannot there is no ACP and that therefore the ACP instance of GRASP cannot
operate. operate.
The way ACP acts as the security and transport substrate for GRASP is The following explanation how ACP acts as the security and transport
visualized in the following picture: substrate for GRASP is visualized in Figure 8 below.
GRASP unicast messages inside the ACP always use the ACP address.
Link-local addresses from the ACP VRF MUST NOT be used inside
objectives. GRASP unicast messages inside the ACP are transported
via TLS which MUST comply with [RFC7525] execept that only TLS
version 1.2 ([RFC5246]) is REQUIRED and TLS 1.3 ([RFC8446] is
RECOMMENDED. There is no need for older version backward
compatibility in the new use-case of ACP. Mutual authentication MUST
use the ACP domain membership check defined in (Section 6.1.3).
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
into an ACP GRASP virtual interface that is constructed from the TCP
connection(s) to the IPv6 link-local neighbor address(es) on the
underlying ACP virtual interface. If the ACP GRASP virtual interface
has two or more neighbors, the GRASP link-local multicast messages
are replicated to all neighbor TCP connections.
TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options
with less than 256bit AES or less than SHA384. TLS for GRASP MUST
also include the "Supported Elliptic Curves" extension, it MUST
support support the NIST P-256 (secp256r1) and P-384 (secp384r1(24))
curves [RFC4492]. In addition, GRASP TLS clients SHOULD send an
ec_point_formats extension with a single element, "uncompressed".
For further interoperability recommendations, GRASP TLS
implementations SHOULD follow [RFC7525].
TCP and TLS connections for GRASP in the ACP use the IANA assigned
TCP port for GRASP (7107). Effectively the transport stack is
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
addresses on the ACP virtual interfaces. The latter ones are only
used for flooding of GRASP messages.
..............................ACP.............................. ..............................ACP..............................
. . . .
. /-GRASP-flooding-\ ACP GRASP instance . . /-GRASP-flooding-\ ACP GRASP instance .
. / \ A . / \ A
. GRASP GRASP GRASP C . GRASP GRASP GRASP C
. link-local unicast link-local P . link-local unicast link-local P
. multicast messages multicast . . multicast messages multicast .
. messages | messages . . messages | messages .
. | | | . . | | | .
skipping to change at page 52, line 5 skipping to change at page 57, line 5
| | Data-Plane | | Data-Plane
| | | |
| | - ACP secure channel | | - ACP secure channel
link-local link-local - encapsulation addresses link-local link-local - encapsulation addresses
subnet1 subnet2 - Data-Plane interfaces subnet1 subnet2 - Data-Plane interfaces
| | | |
ACP-Nbr1 ACP-Nbr2 ACP-Nbr1 ACP-Nbr2
Figure 8: ACP as security and transport substrate for GRASP Figure 8: ACP as security and transport substrate for GRASP
GRASP unicast messages inside the ACP always use the ACP address.
Link-local addresses from the ACP VRF must not be used inside
objectives. GRASP unicast messages inside the ACP are transported
via TLS according to [RFC7525] execept that only TLS version 1.2
([RFC5246]) or higher MUST be used - because there is no need for
backward compatibility in the new use-case of ACP. Mutual
authentication MUST use the ACP domain membership check defined in
(Section 6.1.3).
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
into an ACP GRASP virtual interface that is constructed from the TCP
connection(s) to the IPv6 link-local neighbor address(es) on the
underlying ACP virtual interface. If the ACP GRASP virtual interface
has two or more neighbors, the GRASP link-local multicast messages
are replicated to all neighbor TCP connections.
TLS for GRASP MUST offer TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and MUST NOT offer options
with less than 256bit AES or less than SHA384. TLS for GRASP MUST
also include the "Supported Elliptic Curves" extension, it MUST
support support the NIST P-256 (secp256r1) and P-384 (secp384r1(24))
curves [RFC4492]. In addition, GRASP TLS clients SHOULD send an
ec_point_formats extension with a single element, "uncompressed".
For further interoperability recommendations, GRASP TLS
implementations SHOULD follow [RFC7525].
TCP and TLS connections for GRASP in the ACP use the IANA assigned
TCP port for GRASP (7107). Effectively the transport stack is
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
addresses on the ACP virtual interfaces. The latter ones are only
used for flooding of GRASP messages.
6.8.2.1. Discussion 6.8.2.1. Discussion
TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local
messages is used because these messages are flooded across messages is used because these messages are flooded across
potentially many hops to all ACP nodes and a single link with even potentially many hops to all ACP nodes and a single link with even
temporary packet loss issues (e.g., WiFi/Powerline link) can reduce temporary packet loss issues (e.g., WiFi/Powerline link) can reduce
the probability for loss free transmission so much that applications the probability for loss free transmission so much that applications
would want to increase the frequency with which they send these would want to increase the frequency with which they send these
messages. Such shorter periodic retransmission of datagrams would messages. Such shorter periodic retransmission of datagrams would
result in more traffic and processing overhead in the ACP than the result in more traffic and processing overhead in the ACP than the
skipping to change at page 54, line 5 skipping to change at page 58, line 16
traffic. Instead, there is just another layer of protection traffic. Instead, there is just another layer of protection
against certain attacks from the inside which is important due to against certain attacks from the inside which is important due to
the role of GRASP in the ACP. the role of GRASP in the ACP.
6.9. Context Separation 6.9. Context Separation
The ACP is in a separate context from the normal Data-Plane of the The ACP is in a separate context from the normal Data-Plane of the
node. This context includes the ACP channels' IPv6 forwarding and node. This context includes the ACP channels' IPv6 forwarding and
routing as well as any required higher layer ACP functions. routing as well as any required higher layer ACP functions.
In classical network system, a dedicated so called Virtual routing In classical network system, a dedicated VRF is one logical
and forwarding instance (VRF) is one logical implementation option implementation option for the ACP. If possible by the systems
for the ACP. If possible by the systems software architecture, software architecture, separation options that minimize shared
separation options that minimize shared components are preferred, components are preferred, such as a logical container or virtual
such as a logical container or virtual machine instance. The context machine instance. The context for the ACP needs to be established
for the ACP needs to be established automatically during bootstrap of automatically during bootstrap of a node. As much as possible it
a node. As much as possible it should be protected from being should be protected from being modified unintentionally by ("Data-
modified unintentionally by ("Data-Plane") configuration. Plane") configuration.
Context separation improves security, because the ACP is not Context separation improves security, because the ACP is not
reachable from the Data-Plane routing or forwarding table(s). Also, reachable from the Data-Plane routing or forwarding table(s). Also,
configuration errors from the Data-Plane setup do not affect the ACP. configuration errors from the Data-Plane setup do not affect the ACP.
6.10. Addressing inside the ACP 6.10. Addressing inside the ACP
The channels explained above typically only establish communication The channels explained above typically only establish communication
between two adjacent nodes. In order for communication to happen between two adjacent nodes. In order for communication to happen
across multiple hops, the autonomic control plane requires ACP across multiple hops, the autonomic control plane requires ACP
network wide valid addresses and routing. Each ACP node must create network wide valid addresses and routing. Each ACP node creates a
a Loopback interface with an ACP network wide unique address inside Loopback interface with an ACP network wide unique address inside the
the ACP context (as explained in in Section 6.9). This address may ACP context (as explained in in Section 6.9). This address may be
be used also in other virtual contexts. used also in other virtual contexts.
With the algorithm introduced here, all ACP nodes in the same routing With the algorithm introduced here, all ACP nodes in the same routing
subdomain have the same /48 ULA prefix. Conversely, ULA global IDs subdomain have the same /48 ULA prefix. Conversely, ULA global IDs
from different domains are unlikely to clash, such that two ACP from different domains are unlikely to clash, such that two ACP
networks can be merged, as long as the policy allows that merge. See networks can be merged, as long as the policy allows that merge. See
also Section 9.1 for a discussion on merging domains. also Section 9.1 for a discussion on merging domains.
Links inside the ACP only use link-local IPv6 addressing, such that Links inside the ACP only use link-local IPv6 addressing, such that
each node's ACP only requires one routable virtual address. each node's ACP only requires one routable virtual address.
skipping to change at page 55, line 7 skipping to change at page 59, line 18
o Separation: Autonomic address space is used separately from user o Separation: Autonomic address space is used separately from user
address space and other address realms. This supports the address space and other address realms. This supports the
robustness requirement. robustness requirement.
o Loopback-only: Only ACP Loopback interfaces (and potentially those o Loopback-only: Only ACP Loopback interfaces (and potentially those
configured for "ACP connect", see Section 8.1) carry routable configured for "ACP connect", see Section 8.1) carry routable
address(es); all other interfaces (called ACP virtual interfaces) address(es); all other interfaces (called ACP virtual interfaces)
only use IPv6 link local addresses. The usage of IPv6 link local only use IPv6 link local addresses. The usage of IPv6 link local
addressing is discussed in [RFC7404]. addressing is discussed in [RFC7404].
o Use-ULA: For Loopback interfaces of ACP nodes, we use Unique Local o Use-ULA: For Loopback interfaces of ACP nodes, we use ULA with L=1
Addresses (ULA), as defined in [RFC4193] with L=1 (as defined in (as defined in section 3.1 of [RFC4193]). Note that the random
section 3.1 of [RFC4193]). Note that the random hash for ACP hash for ACP Loopback addresses uses the definition in
Loopback addresses uses the definition in Section 6.10.2 and not Section 6.10.2 and not the one of [RFC4193] section 3.2.2.
the one of [RFC4193] section 3.2.2.
o No external connectivity: They do not provide access to the o No external connectivity: They do not provide access to the
Internet. If a node requires further reaching connectivity, it Internet. If a node requires further reaching connectivity, it
should use another, traditionally managed address scheme in should use another, traditionally managed address scheme in
parallel. parallel.
o Addresses in the ACP are permanent, and do not support temporary o Addresses in the ACP are permanent, and do not support temporary
addresses as defined in [RFC4941]. addresses as defined in [RFC4941].
o Addresses in the ACP are not considered sensitive on privacy o Addresses in the ACP are not considered sensitive on privacy
skipping to change at page 57, line 19 skipping to change at page 61, line 28
for this field will be maintained by IANA. for this field will be maintained by IANA.
The sub-scheme may imply a range or set of addresses assigned to the The sub-scheme may imply a range or set of addresses assigned to the
node, this is called the ACP address range/set and explained in each node, this is called the ACP address range/set and explained in each
sub-scheme. sub-scheme.
Please refer to Section 6.10.7 and Appendix A.1 for further Please refer to Section 6.10.7 and Appendix A.1 for further
explanations why the following Sub-Addressing schemes are used and explanations why the following Sub-Addressing schemes are used and
why multiple are necessary. why multiple are necessary.
The following summarizes the addressing schemes: The following summarizes the addressing Sub-Schemes:
+------+-----+----------------+-------+------------+ +------+-----+----------------+-------+------------+
| type | Z | name | F-bit | V-bit size | | Type | Z | name | F-bit | V-bit size |
+------+-----+----------------+-------+------------+ +------+-----+----------------+-------+------------+
| 0x00 | 0 | ACP Zone | N/A | 1 bit | | 0x00 | 0 | ACP Zone | N/A | 1 bit |
+------+-----+----------------+-------+------------+ +------+-----+----------------+-------+------------+
| 0x00 | 1 | ACP Manual | N/A | 1 bit | | 0x00 | 1 | ACP Manual | N/A | 1 bit |
+------+-----+----------------+-------+------------+ +------+-----+----------------+-------+------------+
| 0x01 | N/A | VLong-ASA | 0 | 8-bits | | 0x01 | N/A | VLong-ASA | 0 | 8-bits |
+------+-----+----------------+-------+------------+ +------+-----+----------------+-------+------------+
| 0x01 | N/A | VLong-ACP-edge | 1 | 16-bits | | 0x01 | N/A | VLong-ACP-edge | 1 | 16-bits |
+------+-----+----------------+-------+------------+ +------+-----+----------------+-------+------------+
Figure 10: Addressing schemes Figure 10: Addressing schemes
6.10.3. ACP Zone Addressing Sub-Scheme 6.10.3. ACP Zone Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 00b (zero) This sub-scheme is used when the Type field of the base scheme is
in the base scheme and 0 in the Z bit. 0x00 and the Z bit is 0x0.
64 64 64 64
+-----------------+---+---------++-----------------------------+---+ +-----------------+---+---------++-----------------------------+---+
| (base scheme) | Z | Zone-ID || Node-ID | | (base scheme) | Z | Zone-ID || Node-ID |
| | | || Registrar-ID | Node-Number| V | | | | || Registrar-ID | Node-Number| V |
+-----------------+---+---------++--------------+--------------+---+ +-----------------+---+---------++--------------+--------------+---+
50 1 13 48 15 1 50 1 13 48 15 1
Figure 11: ACP Zone Addressing Sub-Scheme Figure 11: ACP Zone Addressing Sub-Scheme
The fields are defined as follows: The fields are defined as follows:
o Type: MUST be 0x0.
o Z: MUST be 0x0.
o Zone-ID: If set to all zero bits: The Node-ID bits are used as an o Zone-ID: If set to all zero bits: The Node-ID bits are used as an
identifier (as opposed to a locator). This results in a non- identifier (as opposed to a locator). This results in a non-
hierarchical, flat addressing scheme. Any other value indicates a hierarchical, flat addressing scheme. Any other value indicates a
zone. See Section 6.10.3.1 on how this field is used in detail. zone. See Section 6.10.3.1 on how this field is used in detail.
o Z: MUST be 0.
o Node-ID: A unique value for each node. o Node-ID: A unique value for each node.
The 64-bit Node-ID is derived and composed as follows: The 64-bit Node-ID is derived and composed as follows:
o Registrar-ID (48-bit): A number unique inside the domain that o Registrar-ID (48-bit): A number unique inside the domain that
identifies the ACP registrar which assigned the Node-ID to the identifies the ACP registrar which assigned the Node-ID to the
node. A MAC address of the ACP registrar can be used for this node. One or more domain-wide unique identifiers of the ACP
purpose. registrar can be used for this purpose. See Section 6.10.7.2.
o Node-Number: A number which is unique for a given ACP registrar, o Node-Number: A number which is unique for a given ACP registrar,
to identify the node. This can be a sequentially assigned number. to identify the node. This can be a sequentially assigned number.
o V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP o V (1-bit): Virtualization bit: 0: Indicates the ACP itself ("ACP
node base system); 1: Indicates the optional "host" context on the node base system); 1: Indicates the optional "host" context on the
ACP node (see below). ACP node (see below).
In the ACP Zone Addressing Sub-Scheme, the ACP address in the In the ACP Zone Addressing Sub-Scheme, the ACP address in the
certificate has Zone-ID and V fields as all zero bits. The ACP certificate has Zone-ID and V fields as all zero bits. The ACP
skipping to change at page 60, line 7 skipping to change at page 64, line 19
Note: Zones and Zone-ID as defined here are not related to [RFC4007] Note: Zones and Zone-ID as defined here are not related to [RFC4007]
zones or zone_id. ACP zone addresses are not scoped (reachable only zones or zone_id. ACP zone addresses are not scoped (reachable only
from within an RFC4007 zone) but reachable across the whole ACP. An from within an RFC4007 zone) but reachable across the whole ACP. An
RFC4007 zone_id is a zone index that has only local significance on a RFC4007 zone_id is a zone index that has only local significance on a
node, whereas an ACP Zone-ID is an identifier for an ACP zone that is node, whereas an ACP Zone-ID is an identifier for an ACP zone that is
unique across that ACP. unique across that ACP.
6.10.4. ACP Manual Addressing Sub-Scheme 6.10.4. ACP Manual Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 00b (zero) This sub-scheme is used when the Type field of the base scheme is
in the base scheme and 1 in the Z bit. 0x00 and the Z bit is 0x1.
64 64 64 64
+---------------------+---+----------++-----------------------------+ +---------------------+---+----------++-----------------------------+
| (base scheme) | Z | Subnet-ID|| Interface Identifier | | (base scheme) | Z | Subnet-ID|| Interface Identifier |
+---------------------+---+----------++-----------------------------+ +---------------------+---+----------++-----------------------------+
50 1 13 50 1 13
Figure 12: ACP Manual Addressing Sub-Scheme Figure 12: ACP Manual Addressing Sub-Scheme
The fields are defined as follows: The fields are defined as follows:
o Subnet-ID: Configured subnet identifier. o Type: MUST be 0x0.
o Z: MUST be 1. o Z: MUST be 0x1.
o Subnet-ID: Configured subnet identifier.
o Interface Identifier. o Interface Identifier.
This sub-scheme is meant for "manual" allocation to subnets where the This sub-scheme is meant for "manual" allocation to subnets where the
other addressing schemes cannot be used. The primary use case is for other addressing schemes cannot be used. The primary use case is for
assignment to ACP connect subnets (see Section 8.1.1). assignment to ACP connect subnets (see Section 8.1.1).
"Manual" means that allocations of the Subnet-ID need to be done "Manual" means that allocations of the Subnet-ID need to be done
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
skipping to change at page 61, line 13 skipping to change at page 65, line 29
ACP domain certificate is only usable for non- ACP secure channel ACP domain certificate is only usable for non- ACP secure channel
authentication, such as end-to-end transport connections across the authentication, such as end-to-end 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 6.10.5. ACP Vlong Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 01b (one) in This sub-scheme is used when the Type field of the base scheme is
the base scheme. 0x01.
50 78 50 78
+---------------------++-----------------------------+----------+ +---------------------++-----------------------------+----------+
| (base scheme) || Node-ID | | (base scheme) || Node-ID |
| || Registrar-ID |F| Node-Number| V | | || Registrar-ID |F| Node-Number| V |
+---------------------++--------------+--------------+----------+ +---------------------++--------------+--------------+----------+
50 46 1 23/15 8/16 50 46 1 23/15 8/16
Figure 13: ACP Vlong Addressing Sub-Scheme Figure 13: ACP Vlong Addressing Sub-Scheme
skipping to change at page 61, line 43 skipping to change at page 66, line 11
o F: format bit. This bit determines the format of the subsequent o F: format bit. This bit determines the format of the subsequent
bits. bits.
o V: Virtualization bit: this is a field that is either 8 or 16 o V: Virtualization bit: this is a field that is either 8 or 16
bits. For F=0, it is 8 bits, for F=1 it is 16 bits. The V bits bits. For F=0, it is 8 bits, for F=1 it is 16 bits. The V bits
are assigned by the ACP node. In the ACP certificate's ACP are assigned by the ACP node. In the ACP certificate's ACP
address Section 6.1.2, the V-bits are always set to 0. address Section 6.1.2, the V-bits are always set to 0.
o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is
reduced to 46-bits. This still permits the use of the MAC address reduced to 46-bits. One or more domain-wide unique identifiers of
of an ACP registrar by removing the V and U bits from the 48-bits the ACP registrar can be used for this purpose. See
of a MAC address (those two bits are never unique, so they cannot Section 6.10.7.2.
be used to distinguish MAC addresses).
o The Node-Number is unique to each ACP node. There are two formats o The Node-Number is unique to each ACP node. There are two formats
for the Node-Number. When F=0, the node-number is 23 bits, for for the Node-Number. When F=0, the node-number is 23 bits, for
F=1 it is 15 bits. Each format of node-number is considered to be F=1 it is 15 bits. Each format of node-number is considered to be
in a unique number space. in a unique number space.
The F=0 bit format addresses are intended to be used for "general The F=0 bit format addresses are intended to be used for "general
purpose" ACP nodes that would potentially have a limited number (< purpose" ACP nodes that would potentially have a limited number (<
256) of clients (ASA/Autonomic Functions or legacy services) of the 256) of clients (ASA/Autonomic Functions or legacy services) of the
ACP that require separate V(irtual) addresses. ACP that require separate V(irtual) addresses.
skipping to change at page 63, line 15 skipping to change at page 67, line 27
case they can also assign ACP domain certificates without case they can also assign ACP domain certificates without
dependencies against a (shared) root-CA (except during renewals of dependencies against a (shared) root-CA (except during renewals of
their own certificates). their own 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 domain certificate specific fields. They
request certificates for ACP nodes from a Certificate Authority request certificates for ACP nodes from a Certificate Authority
through any appropriate mechanism (out of scope in this document, but through any appropriate mechanism (out of scope in this document, but
required to be BRSKI for ANI registrars). Only nodes that are required to be BRSKI for ANI registrars). Only nodes that are
trusted to be compliant with the requirements against registrar trusted to be compliant with the requirements against registrar
described in this section must be given the necessary credentials to described in this section can be given the necessary credentials to
perform this RA function, such as credentials for the BRSKI perform this RA function, such as credentials for the BRSKI
connection to the CA for ANI registrars. connection to the CA for 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 trust anchors allow to perform the the resulting ACP certificate and trust anchors allow to perform the
ACP domain membership described in Section 6.1.3 with other ACP 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
domain information field as described further below in this section. domain information field as described further below in this section.
skipping to change at page 64, line 5 skipping to change at page 68, line 14
6.10.7.2. Unique Address/Prefix allocation 6.10.7.2. Unique Address/Prefix allocation
ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes ACP registrars MUST NOT allocate ACP address prefixes to ACP nodes
via the ACP domain information field that would collide with the ACP via the ACP domain information field that would collide with the ACP
address prefixes of other ACP nodes in the same ACP domain. This address prefixes of other ACP nodes in the same ACP domain. This
includes both prefixes allocated by the same ACP registrar to includes both prefixes allocated by the same ACP registrar to
different ACP nodes as well as prefixes allocated by other ACP different ACP nodes as well as prefixes allocated by other ACP
registrars for the same ACP domain. registrars for the same ACP domain.
For this purpose, an ACP registrar MUST have one or more unique To support such unique address allocation, an ACP registrar MUST have
46-bit identifiers called Registrar-IDs used to allocate ACP address one or more 46-bit identifiers unique across the ACP domain which is
prefixes. The lower 46-bits of a EUI-48 MAC addresses are globally called the Registrar-ID. Allocation of Registrar-ID(s) to an ACP
unique 46 bit identifiers, so ACP registrars with known unique EUI-48 registrar can happen through OAM mechanisms in conjunction with some
MAC addresses can use these as Registrar-IDs. Registrar-IDs do not database / allocation orchestration.
need to be globally unique but only unique across the set of ACP
registrars for an ACP domain, so other means to assign unique ACP registrars running on physical devices with known globally unique
Registrar-IDs to ACP registrars can be used, such as configuration on EUI-48 MAC address(es) can use the lower 46 bits of those address(es)
the ACP registrars. as unique Registrar-IDs without requiring any external signaling/
configuration (the upper two bits, V and U are not uniquely assigned
but functional). This approach is attractive for distributed, non-
centrally administered, lightweight ACP registrar implementations.
There is no mechanism to deduce from a MAC address itself whether it
is actually uniquely assigned. Implementations need to consult
additional offline information before making this assumption. For
example by knowing that a particular physical product/MIC-chip is
guaranteed to use globally unique assigned EUI-48 MAC address(es).
When the candidate ACP device (called Pledge in BRSKI) is to be When the candidate ACP device (called Pledge in BRSKI) is to be
enrolled into an ACP domain, the ACP registrar needs to allocate a enrolled into an ACP domain, the ACP registrar needs to allocate a
unique ACP address to the node and ensure that the ACP certificate unique ACP address to the node and ensure that the ACP certificate
gets a domain information field (Section 6.1.2) with the appropriate gets a domain information field (Section 6.1.2) with the appropriate
information - ACP domain-name, ACP-address, and so on. If the ACP information - ACP domain-name, ACP-address, and so on. If the ACP
registrar uses BRSKI, it signals the ACP domain information field to registrar uses BRSKI, it signals the ACP domain information field to
the Pledge via the EST /csrattrs command (see the Pledge via the EST /csrattrs command (see
[I-D.ietf-anima-bootstrapping-keyinfra], section 5.9.2 - "EST CSR [I-D.ietf-anima-bootstrapping-keyinfra], section 5.9.2 - "EST CSR
Attributes"). Attributes").
skipping to change at page 65, line 11 skipping to change at page 69, line 28
that is typically indicating the node's vendor and device type and that is typically indicating the node's vendor and device type and
can be used to drive a policy selecting an appropriate addressing can be used to drive a policy selecting an appropriate addressing
sub-scheme for the (class of) node(s). 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. Allocation and use of zone sub-addresses addresses with Zone-ID 0. Allocation and use of zone sub-addresses
with Zone-ID != 0 is outside the scope of this specification because with Zone-ID != 0 is outside the scope of this specification because
it would need to go along with rules for extending ACP routing to it would need to go along with rules for extending ACP routing to
multiple zones, which is outside the scope of this specification. multiple zones, which is outside the scope of this specification.
ACP registrars that can use the IDevID of a candidate ACP device ACP registrars that are aware of can use the IDevID of a candidate
SHOULD be able to choose the zone vs. Vlong sub-address scheme for ACP device SHOULD be able to choose the zone vs. Vlong sub-address
ACP nodes based on the "serialNumber" of the IDevID, for example by scheme for ACP nodes based on the "serialNumber" of the IDevID, for
the PID (Product Identifier) part which identifies the product type, example by the PID (Product Identifier) part which identifies the
or the complete "serialNumber". product type, or the complete "serialNumber".
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.
6.10.7.4. Address/Prefix Persistence 6.10.7.4. Address/Prefix Persistence
skipping to change at page 66, line 49 skipping to change at page 71, line 24
the ACP forwarding plane, especially to support devices with silicon the ACP forwarding plane, especially to support devices with silicon
forwarding planes that cannot support insertion/removal of these forwarding planes that cannot support insertion/removal of these
headers in silicon or hop-by-hop forwarding based on them. Note: headers in silicon or hop-by-hop forwarding based on them. Note:
Insertion/removal of headers by a (potentially silicon based) ACP Insertion/removal of headers by a (potentially silicon based) ACP
node would be be necessary when senders/receivers of ACP packets are node would be be necessary when senders/receivers of ACP packets are
legacy NOC devices connected via ACP connect (see Section 8.1.1 to legacy NOC devices connected via ACP connect (see Section 8.1.1 to
the ACP. Their connectivity can be handled in RPL as non-RPL-aware the ACP. Their connectivity can be handled in RPL as non-RPL-aware
leafs (or "Internet") according to the Data-Plane architecture leafs (or "Internet") according to the Data-Plane architecture
explained in [I-D.ietf-roll-useofrplinfo]. explained in [I-D.ietf-roll-useofrplinfo].
To avoid Data-Plane artefacts, the profile uses a simple destination This RPL profile avoids the use of Data-Plane artefacts (RPL data
prefix based routing/forwarding table. To achieve this, the profiles packet headers, see Section 6.11.1.13), because hardware accelerated
uses only one RPL instanceID. This single instanceID can contain forwarding planes most likely can not support them today. To achieve
only one Destination Oriented Directed Acyclic Graph (DODAG), and the this, the profile uses a simple destination prefix based routing/
routing/forwarding table can therefore only calculate a single class forwarding table. To achieve this, the profiles uses only one RPL
of service ("best effort towards the primary NOC/root") and cannot instanceID. This single instanceID can contain only one Destination
create optimized routing paths to accomplish latency or energy goals Oriented Directed Acyclic Graph (DODAG), and the routing/forwarding
between any two nodes. table can therefore only calculate a single class of service ("best
effort towards the primary NOC/root") and cannot create optimized
routing paths to accomplish latency or energy goals between any two
nodes.
Consider a network that has multiple NOCs in different locations. Consider a network that has multiple NOCs in different locations.
Only one NOC will become the DODAG root. Traffic to and from other Only one NOC will become the DODAG root. Traffic to and from other
NOCs has to be sent through the DODAG (shortest path tree) rooted in NOCs has to be sent through the DODAG (shortest path tree) rooted in
the primary NOC. Depending on topology, this can be an annoyance the primary NOC. Depending on topology, this can be an annoyance
from a latency point of view or from minimizing network path from a latency point of view or from minimizing network path
resources, but this is deemed to be acceptable given how ACP traffic resources, but this is deemed to be acceptable given how ACP traffic
is "only" network management/control traffic. is "only" network management/control traffic.
Using a single instanceID/DODAG does not introduce a single point of Using a single instanceID/DODAG does not introduce a single point of
skipping to change at page 67, line 30 skipping to change at page 72, line 7
plane forwarding failures including choosing a different root when plane forwarding failures including choosing a different root when
the primary one fails. See Appendix A.10.4 for more details. the primary one fails. See Appendix A.10.4 for more details.
The benefit of this profile, especially compared to other IGPs is The benefit of this profile, especially compared to other IGPs is
that it does not calculate routes for node reachable through the same that it does not calculate routes for node reachable through the same
interface as the DODAG root. This RPL profile can therefore scale to interface as the DODAG root. This RPL profile can therefore scale to
much larger number of ACP nodes in the same amount of compute and much larger number of ACP nodes in the same amount of compute and
memory than other routing protocols. Especially on nodes that are memory than other routing protocols. Especially on nodes that are
leafs of the topology or those close to those leafs. leafs of the topology or those close to those leafs.
The lack of RPL Packet Information (RPI, the IPv6 header for RPL The lack of RPL Packet Information (see Section 6.11.1.13), means
defined by [RFC6553]), means that the Data-Plane will have no rank that the Data-Plane will have no rank value that can be used to
value that can be used to detect loops. As a result, traffic may detect loops. As a result, traffic may loop until the time-to-live
loop until the time-to-live (TTL) of the packet reaches zero. This (TTL) of the packet reaches zero. This is the same behavior as that
is the same behavior as that of other IGPs that do not have the Data- of other IGPs that do not have the Data-Plane options of RPL.
Plane options of RPL.
Since links in the ACP are assumed to be mostly reliable (or have Since links in the ACP are assumed to be mostly reliable (or have
link layer protection against loss) and because there is no stretch link layer protection against loss) and because there is no stretch
according to Section 6.11.1.7, loops caused by RPL routing packet according to Section 6.11.1.7, loops caused by RPL routing packet
loss should be exceedingly rare. loss should be exceedingly rare.
There are a variety of mechanisms possible in RPL to further avoid There are a variety of mechanisms possible in RPL to further avoid
temporary loops: DODAG Information Objects (DIOs) SHOULD be sent temporary loops: DODAG Information Objects (DIOs) SHOULD be sent
2...3 times to inform children when losing the last parent. The 2...3 times to inform children when losing the last parent. The
technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be
skipping to change at page 70, line 4 skipping to change at page 74, line 29
whatever ACP address space that it advertises (i.e.: the /96 or whatever ACP address space that it advertises (i.e.: the /96 or
/127). This is avoid routing loops for addresses that an ACP node /127). This is avoid routing loops for addresses that an ACP node
has not (yet) used. has not (yet) used.
6.11.1.12. Administrative parameters 6.11.1.12. Administrative parameters
Administrative Preference ([RFC6550], 3.2.6 - to become root): Administrative Preference ([RFC6550], 3.2.6 - to become root):
Indicated in DODAGPreference field of DIO message. Indicated in DODAGPreference field of DIO message.
o Explicit configured "root": 0b100 o Explicit configured "root": 0b100
o ACP registrar (Default): 0b011 o ACP registrar (Default): 0b011
o ACP-connect (non-registrar): 0b010 o ACP-connect (non-registrar): 0b010
o Default: 0b001. o Default: 0b001.
6.11.1.13. RPL Data-Plane artifacts 6.11.1.13. RPL Data-Plane artifacts
RPI (RPL Packet Information [RFC6553]): Not used as there is only a RPL Packet Information (RPI) defined in [RFC6550], section 11.2
single instance, and data path validation is not being used. defines the data packet artefacts required or beneficial in
forwarding of those data packets when their routing information is
derived from RPL. This profile does not use RPI for better
compatibility with accelerated hardeware forwarding planes and
achieves this for the following reasons.
SRH (RPL Source Routing - RFC6552): Not used. Storing mode is being One RPI option is the RPL Source Routing Header (SRH) [RFC6554] which
used. is not necessary in this profile because it uses storing mode where
each hop has the necessary next-hop forwarding information.
The simpler RPL Option header [RFC6553] is also not necessary in this
profile, because it uses a single RPL instance and data path
validation is also not used.
6.11.1.14. Unknown Destinations 6.11.1.14. Unknown Destinations
Because RPL minimizes the size of the routing and forwarding table, Because RPL minimizes the size of the routing and forwarding table,
prefixes reachable through the same interface as the RPL root are not prefixes reachable through the same interface as the RPL root are not
known on every ACP node. Therefore traffic to unknown destination known on every ACP node. Therefore traffic to unknown destination
addresses can only be discovered at the RPL root. The RPL root addresses can only be discovered at the RPL root. The RPL root
SHOULD have attach safe mechanisms to operationally discover and log SHOULD have attach safe mechanisms to operationally discover and log
such packets. such packets.
skipping to change at page 71, line 15 skipping to change at page 75, line 50
from ACP at lower performance, especially if the ACP is used only for from ACP at lower performance, especially if the ACP is used only for
critical operations, e.g., when the Data-Plane is not available. The critical operations, e.g., when the Data-Plane is not available. The
design of the ACP as specified in this document is intended to design of the ACP as specified in this document is intended to
support a wide range of performance options: It is intended to allow support a wide range of performance options: It is intended to allow
software-only implementations at potentially low performance, but can software-only implementations at potentially low performance, but can
also support high performance options. See [RFC8368] for more also support high performance options. See [RFC8368] for more
details. details.
6.12.2. Addressing of Secure Channels 6.12.2. Addressing of Secure Channels
In order to be independent of the Data-Plane (routing and addressing) In order to be independent of the Data-Plane routing and addressing,
the GRASP discovered (autonomic) ACP secure channels use IPv6 link the GRASP discovered ACP secure channels use IPv6 link local
local addresses between adjacent neighbors. Note: Section 8.2 addresses between adjacent neighbors. Note: Section 8.2 specifies
specifies extensions in which secure channels are configured tunnels extensions in which secure channels are configured tunnels operating
operating over the Data-Plane, so those secure channels cannot be over the Data-Plane, so those secure channels cannot be independent
independent of the Data-Plane. of the Data-Plane.
To avoid that Data-Plane configuration can impact the operations of To avoid that Data-Plane configuration can impact the operations of
the IPv6 (link-local) interface/address used for ACP channels, the IPv6 (link-local) interface/address used for ACP channels,
appropriate implementation considerations are required. If the IPv6 appropriate implementation considerations are required. If the IPv6
interface/link-local address is shared with the Data-Plane it needs interface/link-local address is shared with the Data-Plane it needs
to be impossible to unconfigure/disable it through configuration. to be impossible to unconfigure/disable it through configuration.
Instead of sharing the IPv6 interface/link-local address, a separate Instead of sharing the IPv6 interface/link-local address, a separate
(virtual) interface with a separate IPv6 link-local address can be (virtual) interface with a separate IPv6 link-local address can be
used. For example, the ACP interface could be run over a separate used. For example, the ACP interface could be run over a separate
MAC address of an underlying L2 (Ethernet) interface. For more MAC address of an underlying L2 (Ethernet) interface. For more
details and options, see Appendix A.10.2. details and options, see Appendix A.10.2.
Note that other (non-ideal) implementation choices may introduce Note that other (non-ideal) implementation choices may introduce
additional undesired dependencies against the Data-Plane. For additional undesired dependencies against the Data-Plane. For
example shared code and configuration of the secure channel protocols example shared code and configuration of the secure channel protocols
(IPsec / DTLS). (IPsec / DTLS).
6.12.3. MTU 6.12.3. MTU
The MTU for ACP secure channels must be derived locally from the The MTU for ACP secure channels MUST be derived locally from the
underlying link MTU minus the secure channel encapsulation overhead. underlying link MTU minus the secure channel encapsulation overhead.
ACP secure Channel protocols do not need to perform MTU discovery ACP secure Channel protocols do not need to perform MTU discovery
because they are built across L2 adjacencies - the MTU on both sides because they are built across L2 adjacencies - the MTU on both sides
connecting to the L2 connection are assumed to be consistent. connecting to the L2 connection are assumed to be consistent.
Extensions to ACP where the ACP is for example tunneled need to Extensions to ACP where the ACP is for example tunneled need to
consider how to guarantee MTU consistency. This is an issue of consider how to guarantee MTU consistency. This is an issue of
tunnels, not an issue of running the ACP across a tunnel. Transport tunnels, not an issue of running the ACP across a tunnel. Transport
stacks running across ACP can perform normal PMTUD (Path MTU stacks running across ACP can perform normal PMTUD (Path MTU
Discovery). Because the ACP is meant to be prioritize reliability Discovery). Because the ACP is meant to be prioritize reliability
skipping to change at page 72, line 30 skipping to change at page 77, line 16
up with a previously unknown GRASP announcement (e.g., on a different up with a previously unknown GRASP announcement (e.g., on a different
link or with a different address announced in GRASP). link or with a different address announced in GRASP).
6.12.5. ACP interfaces 6.12.5. ACP interfaces
The ACP VRF has conceptually two type of interfaces: The "ACP The ACP VRF has conceptually two type of interfaces: The "ACP
Loopback interface(s)" to which the ACP ULA address(es) are assigned Loopback interface(s)" to which the ACP ULA address(es) are assigned
and the "ACP virtual interfaces" that are mapped to the ACP secure and the "ACP virtual interfaces" that are mapped to the ACP secure
channels. channels.
6.12.5.1. ACP loopback interfaces
The term "Loopback interface" was introduced initially to refer to an The term "Loopback interface" was introduced initially to refer to an
internal interface on a node that would allow IP traffic between internal interface on a node that would allow IP traffic between
transport endpoints on the node in the absence or failure of any or transport endpoints on the node in the absence or failure of any or
all external interfaces, see [RFC4291] section 2.5.3. all external interfaces, see [RFC4291] section 2.5.3.
Even though Loopback interfaces were originally designed to hold only Even though Loopback interfaces were originally designed to hold only
Loopback addresses not reachable from outside the node, these Loopback addresses not reachable from outside the node, these
interfaces are also commonly used today to hold addresses reachable interfaces are also commonly used today to hold addresses reachable
from the outside. They are meant to be reachable independent of any from the outside. They are meant to be reachable independent of any
external interface being operational, and therefore to be more external interface being operational, and therefore to be more
resilient. These addresses on Loopback interfaces can be thought of resilient. These addresses on Loopback interfaces can be thought of
as "node addresses" instead of "interface addresses", and that is as "node addresses" instead of "interface addresses", and that is
what ACP address(es) are. This construct makes it therefore possible what ACP address(es) are. This construct makes it therefore possible
to address ACP nodes with a well-defined set of addresses independent to address ACP nodes with a well-defined set of addresses independent
of the number of external interfaces. of the number of external interfaces.
For these reason, the ACP (ULA) address(es) are assigned to Loopback For these reason, the ACP ULA address(es) are assigned to Loopback
interface(s). interface(s).
Any type of ACP secure channels to another ACP node can be mapped to 6.12.5.2. ACP virtual interfaces
ACP virtual interfaces in following ways. This is independent of the
Any ACP secure channel to another ACP node is mapped to ACP virtual
interfaces in one of the following ways. This is independent of the
chosen secure channel protocol (IPsec, DTLS or other future protocol chosen secure channel protocol (IPsec, DTLS or other future protocol
- standards or non-standards): - standards or non-standards).
ACP point-to-point virtual interface: Note that all the considerations described here are assuming point-
to-point secure channel associations. Mapping multi-party secure
channel associations such as [RFC6407] is out of scope (but would be
easy to add).
Each ACP secure channel is mapped into a separate point-to-point ACP 6.12.5.2.1. ACP point-to-point virtual interfaces
virtual interface. If a physical subnet has more than two ACP
capable nodes (in the same domain), this implementation approach will
lead to a full mesh of ACP virtual interfaces between them.
ACP multi-access virtual interface: In this option, each ACP secure channel is mapped into a separate
point-to-point ACP virtual interface. If a physical subnet has more
than two ACP capable nodes (in the same domain), this implementation
approach will lead to a full mesh of ACP virtual interfaces between
them.
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
skipping to change at page 75, line 20 skipping to change at page 80, line 17
RPL does support operations and correct routing table construction RPL does support operations and correct routing table construction
across non-broadcast multi-access (NBMA) subnets. This is common across non-broadcast multi-access (NBMA) subnets. This is common
when using many radio technologies. When such NBMA subnets are used, when using many radio technologies. When such NBMA subnets are used,
they MUST NOT be represented as ACP multi-access virtual interfaces they MUST NOT be represented as ACP multi-access virtual interfaces
because the replication of IPv6 link-local multicast messages will because the replication of IPv6 link-local multicast messages will
not reach all NBMA subnet neighbors. In result, GRASP message not reach all NBMA subnet neighbors. In result, GRASP message
flooding would fail. Instead, each ACP secure channel across such an flooding would fail. Instead, each ACP secure channel across such an
interface MUST be represented as a ACP point-to-point virtual interface MUST be represented as a ACP point-to-point virtual
interface. See also Appendix A.10.4. interface. See also Appendix A.10.4.
Care must also be taken when creating multi-access ACP virtual Care needs to be taken when creating multi-access ACP virtual
interfaces across ACP secure channels between ACP nodes in different interfaces across ACP secure channels between ACP nodes in different
domains or routing subdomains. If for example future inter-domain domains or routing subdomains. If for example future inter-domain
ACP policies are defined as "peer-to-peer" policies, it is easier to ACP policies are defined as "peer-to-peer" policies, it is easier to
create ACP point-to-point virtual interfaces for these inter-domain create ACP point-to-point virtual interfaces for these inter-domain
secure channels. secure channels.
7. ACP support on L2 switches/ports (Normative) 7. ACP support on L2 switches/ports (Normative)
7.1. Why (Benefits of ACP on L2 switches) 7.1. Why (Benefits of ACP on L2 switches)
skipping to change at page 76, line 43 skipping to change at page 81, line 40
To support ACP on L2 switches or L2 switched ports of an L3 device, To support ACP on L2 switches or L2 switched ports of an L3 device,
it is necessary to make those L2 ports look like L3 interfaces for it is necessary to make those L2 ports look like L3 interfaces for
the ACP implementation. This primarily involves the creation of a the ACP implementation. This primarily involves the creation of a
separate DULL GRASP instance/domain on every such L2 port. Because separate DULL GRASP instance/domain on every such L2 port. Because
GRASP has a dedicated link-local IPv6 multicast address GRASP has a dedicated link-local IPv6 multicast address
(ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this (ALL_GRASP_NEIGHBORS), it is sufficient that all packets for this
address are being extracted at the port level and passed to that DULL address are being extracted at the port level and passed to that DULL
GRASP instance. Likewise the IPv6 link-local multicast packets sent GRASP instance. Likewise the IPv6 link-local multicast packets sent
by that DULL GRASP instance need to be sent only towards the L2 port by that DULL GRASP instance need to be sent only towards the L2 port
for this DULL GRASP instance. for this DULL GRASP instance (instead of being flooded across all
ports of the VLAN to which the port belongs).
If the device with L2 ports is supporting per L2 port ACP DULL GRASP When Ports/Interfaces across which the ACP is expected to operate in
as well as MLD snooping ([RFC4541]), then MLD snooping must be an ACP-aware L2-switch or L2/L3-switch/router are L2-bridged, packets
changed to never forward packets for ALL_GRASP_NEIGHBORS because that for the ALL_GRASP_NEIGHBORS multicast address MUST never be forward
would cause the problem that per L2 port ACP DULL GRASP is meant to between these ports. If MLD snooping is used, it MUST be prohibited
overcome (forwarding DULL GRASP packets across L2 ports). from bridging packets for the ALL_GRASP_NEIGHBORS IPv6 multicast
address.
The rest of ACP operations can operate in the same way as in L3 On hybrid L2/L3 switches, multiple L2 ports are assigned to a single
devices: Assume for example that the device is an L3/L2 hybrid device L3 VLAN interface. With the aforementioned changes for DULL GRASP,
where L3 interfaces are assigned to VLANs and each VLAN has ACP can simply operate on the L3 VLAN interfaces, so no further
potentially multiple ports. DULL GRASP is run as described (hardware) forwarding changes are required to make ACP operate on L2
individually on each L2 port. When it discovers a candidate ACP ports. This is possible because the ACP secure channel protocols
neighbor, it passes its IPv6 link-local address and supported secure only use link-local IPv6 unicast packets, and these packets will be
channel protocols to the ACP secure channel negotiation that can be sent to the correct L2 port towards the peer by the VLAN logic of the
bound to the L3 (VLAN) interface. It will simply use link-local IPv6 device.
multicast packets to the candidate ACP neighbor. Once a secure
channel is established to such a neighbor, the virtual interface to This is sufficient when p2p ACP virtual interfaces are established to
which this secure channel is mapped should then actually be the L2 every ACP peer. When it is desired to create multi-access ACP
port and not the L3 interface to best map the actual physical virtual interfaces (see Section 6.12.5.2.2), it is REQIURED not to
topology into the ACP virtual interfaces. See Section 6.12.5 for coalesce all the ACP secure channels on the same L3 VLAN interface,
more details about how to map secure channels into ACP virtual but only all those on the same L2 port.
interfaces. Note that a single L2 port can still have multiple ACP
neighbors if it connect for example to multiple ACP neighbors via a If VLAN tagging is used, then all the above described logic only
non-ACP enabled switch. The per L2 port ACP virtual interface can applies to untagged GRASP packets. For the purpose of ACP neighbor
therefore still be a multi-access virtual LAN. discovery via GRASP, no VLAN tagged packets SHOULD be sent or
received. In a hybrid L2/L3 switch, each VLAN would therefore only
create ACP adjacencies across those ports where the VLAN is carried
untagged.
In result, the simple logic is that ACP secure channels would operate
over the same L3 interfaces that present a single flat bridged
network across all routers, but because DULL GRASP is separated on a
per-port basis, no full mesh of ACP secure channels is created, but
only per-port ACP secure channels to per-port L2-adjacent ACP node
neighbors.
For example, in the above picture, ANswitch1 would run separate DULL For example, in the above picture, ANswitch1 would run separate DULL
GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even
though all those three ports may be in the data plane in the same though all those three ports may be in the data plane in the same
(V)LAN and perform L2 switching between these ports, ANswitch1 would (V)LAN and perform L2 switching between these ports, ANswitch1 would
perform ACP L3 routing between them. perform ACP L3 routing between them.
The description in the previous paragraph was specifically meant to The description in the previous paragraph was specifically meant to
illustrate that on hybrid L3/L2 devices that are common in illustrate that on hybrid L3/L2 devices that are common in
enterprise, IoT and broadband aggregation, there is only the GRASP enterprise, IoT and broadband aggregation, there is only the GRASP
packet extraction (by Ethernet address) and GRASP link-local packet extraction (by Ethernet address) and GRASP link-local
multicast per L2-port packet injection that has to consider L2 ports multicast per L2-port packet injection that has to consider L2 ports
at the hardware forwarding level. The remaining operations are at the hardware forwarding level. The remaining operations are
purely ACP control plane and setup of secure channels across the L3 purely ACP control plane and setup of secure channels across the L3
interface. This hopefully makes support for per-L2 port ACP on those interface. This hopefully makes support for per-L2 port ACP on those
hybrid devices easy. hybrid devices easy.
This L2/L3 optimized approach is subject to "address stealing", e.g.,
where a device on one port uses addresses of a device on another
port. This is a generic issue in L2 LANs and switches often already
have some form of "port security" to prohibit this. They rely on NDP
or DHCP learning of which port/MAC-address and IPv6 address belong
together and block duplicates. This type of function needs to be
enabled to prohibit DoS attacks. Likewise the GRASP DULL instance
needs to ensure that the IPv6 address in the locator-option matches
the source IPv6 address of the DULL GRASP packet.
In devices without such a mix of L2 port/interfaces and L3 interfaces In devices without such a mix of L2 port/interfaces and L3 interfaces
(to terminate any transport layer connections), implementation (to terminate any transport layer connections), implementation
details will differ. Logically most simply every L2 port is details will differ. Logically most simply every L2 port is
considered and used as a separate L3 subnet for all ACP operations. considered and used as a separate L3 subnet for all ACP operations.
The fact that the ACP only requires IPv6 link-local unicast and The fact that the ACP only requires IPv6 link-local unicast and
multicast should make support for it on any type of L2 devices as multicast should make support for it on any type of L2 devices as
simple as possible. simple as possible.
A generic issue with ACP in L2 switched networks is the interaction A generic issue with ACP in L2 switched networks is the interaction
with the Spanning Tree Protocol. Without further L2 enhancements, with the Spanning Tree Protocol. Without further L2 enhancements,
the ACP would run only across the active STP topology and the ACP the ACP would run only across the active STP topology and the ACP
would be interrupted and re-converge with STP changes. Ideally, ACP would be interrupted and re-converge with STP changes. Ideally, ACP
peering should be built also across ports that are blocked in STP so peering SHOULD be built also across ports that are blocked in STP so
that the ACP does not depend on STP and can continue to run that the ACP does not depend on STP and can continue to run
unaffected across STP topology changes, where re-convergence can be unaffected across STP topology changes, where re-convergence can be
quite slow. The above described simple implementation options are quite slow. The above described simple implementation options are
not sufficient to achieve this. not sufficient to achieve this.
8. Support for Non-ACP Components (Normative) 8. Support for Non-ACP Components (Normative)
8.1. ACP Connect 8.1. ACP Connect
8.1.1. Non-ACP Controller / NMS system 8.1.1. Non-ACP Controller / NMS system
The Autonomic Control Plane can be used by management systems, such The Autonomic Control Plane can be used by management systems, such
as controllers or network management system (NMS) hosts (henceforth as controllers or network management system (NMS) hosts (henceforth
called simply "NMS hosts"), to connect to devices (or other type of called simply "NMS hosts"), to connect to devices (or other type of
nodes) through it. For this, an NMS host must have access to the nodes) through it. For this, an NMS host needs to have access to the
ACP. The ACP is a self-protecting overlay network, which allows by ACP. The ACP is a self-protecting overlay network, which allows by
default access only to trusted, autonomic systems. Therefore, a default access only to trusted, autonomic systems. Therefore, a
traditional, non-ACP NMS system does not have access to the ACP by traditional, non-ACP NMS system does not have access to the ACP by
default, such as any other external node. default, such as any other external node.
If the NMS host is not autonomic, i.e., it does not support autonomic If the NMS host is not autonomic, i.e., it does not support autonomic
negotiation of the ACP, then it can be brought into the ACP by negotiation of the ACP, then it can be brought into the ACP by
explicit configuration. To support connections to adjacent non-ACP explicit configuration. To support connections to adjacent non-ACP
nodes, an ACP node must support "ACP connect" (sometimes also called nodes, an ACP node SHOULD support "ACP connect" (sometimes also
"autonomic connect"): called "autonomic connect"):
"ACP connect" is an interface level configured workaround for "ACP connect" is an interface level configured workaround for
connection of trusted non-ACP nodes to the ACP. The ACP node on connection of trusted non-ACP nodes to the ACP. The ACP node on
which ACP connect is configured is called an "ACP edge node". With which ACP connect is configured is called an "ACP edge node". With
ACP connect, the ACP is accessible from those non-ACP nodes (such as ACP connect, the ACP is accessible from those non-ACP nodes (such as
NOC systems) on such an interface without those non-ACP nodes having NOC systems) on such an interface without those non-ACP nodes having
to support any ACP discovery or ACP channel setup. This is also to support any ACP discovery or ACP channel setup. This is also
called "native" access to the ACP because to those (NOC) systems the called "native" access to the ACP because to those NOC systems the
interface looks like a normal network interface (without any interface looks like a normal network interface (without any
encryption/novel-signaling). encryption/novel-signaling).
Data-Plane "native" (no ACP) Data-Plane "native" (no ACP)
. .
+--------+ +----------------+ . +-------------+ +--------+ +----------------+ . +-------------+
| ACP | |ACP Edge Node | . | | | ACP | |ACP Edge Node | . | |
| Node | | | v | | | Node | | | v | |
| |-------|...[ACP VRF]....+-----------------| |+ | |-------|...[ACP VRF]....+-----------------| |+
| | ^ |. | | NOC Device || | | ^ |. | | NOC Device ||
skipping to change at page 79, line 28 skipping to change at page 84, line 28
+ ACP auto-negotiated . "ACP connect subnet" + ACP auto-negotiated . "ACP connect subnet"
and encrypted . and encrypted .
ACP connect interface ACP connect interface
e.g., "VRF ACP native" (config) e.g., "VRF ACP native" (config)
Figure 15: ACP connect Figure 15: ACP connect
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 must 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.
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
skipping to change at page 80, line 6 skipping to change at page 85, line 6
An ACP connect interface SHOULD use an IPv6 address/prefix from the An ACP connect interface SHOULD use an IPv6 address/prefix from the
ACP Manual Addressing Sub-Scheme (Section 6.10.4), letting the ACP Manual Addressing Sub-Scheme (Section 6.10.4), letting the
operator configure for example only the Subnet-ID and having the node operator configure for example only the Subnet-ID and having the node
automatically assign the remaining part of the prefix/address. It automatically assign the remaining part of the prefix/address. It
SHOULD NOT use a prefix that is also routed outside the ACP so that SHOULD NOT use a prefix that is also routed outside the ACP so that
the addresses clearly indicate whether it is used inside the ACP or the addresses clearly indicate whether it is used inside the ACP or
not. not.
The prefix of ACP connect subnets MUST be distributed by the ACP edge The prefix of ACP connect subnets MUST be distributed by the ACP edge
node into the ACP routing protocol (RPL). The NMS hosts MUST connect node into the ACP routing protocol RPL. The NMS hosts MUST connect
to prefixes in the ACP routing table via its ACP connect interface. to prefixes in the ACP routing table via its ACP connect interface.
In the simple case where the ACP uses only one ULA prefix and all ACP In the simple case where the ACP uses only one ULA prefix and all ACP
connect subnets have prefixes covered by that ULA prefix, NMS hosts connect subnets have prefixes covered by that ULA prefix, NMS hosts
can rely on [RFC6724] to determine longest match prefix routes can rely on [RFC6724] to determine longest match prefix routes
towards its different interfaces, ACP and data-plane. With RFC6724, towards its different interfaces, ACP and data-plane. With RFC6724,
The NMS host will select the ACP connect interface for all addresses The NMS host will select the ACP connect interface for all addresses
in the ACP because any ACP destination address is longest matched by in the ACP because any ACP destination address is longest matched by
the address on the ACP connect interface. If the NMS hosts ACP the address on the ACP connect interface. If the NMS hosts ACP
connect interface uses another prefix or if the ACP uses multiple ULA connect interface uses another prefix or if the ACP uses multiple ULA
prefixes, then the NMS hosts require (static) routes towards the ACP prefixes, then the NMS hosts require (static) routes towards the ACP
skipping to change at page 80, line 33 skipping to change at page 85, line 33
through administrative measures. through administrative measures.
To limit the security impact of ACP connect, nodes supporting it To limit the security impact of ACP connect, nodes supporting it
SHOULD implement a security mechanism to allow configuration/use of SHOULD implement a security mechanism to allow configuration/use of
ACP connect interfaces only on nodes explicitly targeted to be ACP connect interfaces only on nodes explicitly targeted to be
deployed with it (those in physically secure locations such as a deployed with it (those in physically secure locations such as a
NOC). For example, the registrar could disable the ability to enable NOC). For example, the registrar could disable the ability to enable
ACP connect on devices during enrollment and that property could only ACP connect on devices during enrollment and that property could only
be changed through re-enrollment. See also Appendix A.10.5. be changed through re-enrollment. See also Appendix A.10.5.
ACP Edge nodes SHOULD have a configurable option to filter packets
with RPI headers (xsee Section 6.11.1.13 across an ACP connect
interface. These headers are outside the scope of the RPL profile in
this specification but may be used in future extensions of this
specification.
8.1.2. Software Components 8.1.2. Software Components
The ACP connect mechanism be only be used to connect physically The previous section assumed that ACP Edge node and NOC devices are
separate physical devices and the ACP connect interface is a physical
network connection. This section discusses the implication when
these components are instead software components running on a single
physical device.
The ACP connect mechanism can not only be used to connect physically
external systems (NMS hosts) to the ACP but also other applications, external systems (NMS hosts) to the ACP but also other applications,
containers or virtual machines. In fact, one possible way to containers or virtual machines. In fact, one possible way to
eliminate the security issue of the external ACP connect interface is eliminate the security issue of the external ACP connect interface is
to collocate an ACP edge node and an NMS host by making one a virtual to collocate an ACP edge node and an NMS host by making one a virtual
machine or container inside the other; and therefore converting the machine or container inside the other; and therefore converting the
unprotected external ACP subnet into an internal virtual subnet in a unprotected external ACP subnet into an internal virtual subnet in a
single device. This would ultimately result in a fully ACP enabled single device. This would ultimately result in a fully ACP enabled
NMS host with minimum impact to the NMS hosts software architecture. NMS host with minimum impact to the NMS hosts software architecture.
This approach is not limited to NMS hosts but could equally be This approach is not limited to NMS hosts but could equally be
applied to devices consisting of one or more VNF (virtual network applied to devices consisting of one or more VNF (virtual network
skipping to change at page 84, line 13 skipping to change at page 89, line 25
software that is equally (if not better) protected, known (or software that is equally (if not better) protected, known (or
trusted) not to be malicious and accordingly designed to isolate trusted) not to be malicious and accordingly designed to isolate
access to the ACP against external equipment. 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 of the
network connection between an ACP edge node and the NMS or other host network connection between an ACP edge node and the NMS or other host
reachable via the ACP connect interface. Node integrity too is reachable via the ACP connect interface. Node integrity too is
expected to be easier because the ACP connect node, the ACP connect 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 link and the nodes connecting to it must be in a contiguous secure
location, hence assuming there can be no physical attack against the environment, hence assuming there can be no physical attack against
devices. the devices.
When using "Combined ACP and Data-Plane Interfaces", care must 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 must all use the ACP interface belong to the GRASP ACP Domain. They SHOULD all use the
IPv6 addresses of the Software/NMS Hosts. The link-local IPv6 ACP IPv6 addresses of the Software/NMS Hosts. The link-local IPv6
addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and addresses of Software/NMS Hosts (used for GRASP M_DISCOVERY and
M_FLOOD messages) are also assumed to belong to the ACP address M_FLOOD messages) are also assumed to belong to the ACP address
space. space.
8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) 8.2. Connecting ACP islands over Non-ACP L3 networks (Remote ACP
neighbors)
Not all nodes in a network may support the ACP. If non-ACP Layer-2 Not all nodes in a network may support the ACP. If non-ACP Layer-2
devices are between ACP nodes, the ACP will work across it since it devices are between ACP nodes, the ACP will work across it since it
is IP based. However, the autonomic discovery of ACP neighbors via is IP based. However, the autonomic discovery of ACP neighbors via
DULL GRASP is only intended to work across L2 connections, so it is DULL GRASP is only intended to work across L2 connections, so it is
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
skipping to change at page 87, line 24 skipping to change at page 92, line 28
implementations to require this enhancement though to keep the implementations to require this enhancement though to keep the
mandatory implementations simpler. mandatory implementations simpler.
The ACP can also sustain network partitions and mergers. Practically The ACP can also sustain network partitions and mergers. Practically
all ACP operations are link local, where a network partition has no all ACP operations are link local, where a network partition has no
impact. Nodes authenticate each other using the domain certificates impact. Nodes authenticate each other using the domain certificates
to establish the ACP locally. Addressing inside the ACP remains to establish the ACP locally. Addressing inside the ACP remains
unchanged, and the routing protocol inside both parts of the ACP will unchanged, and the routing protocol inside both parts of the ACP will
lead to two working (although partitioned) ACPs. lead to two working (although partitioned) ACPs.
There are few central dependencies: A certificate revocation list There are few central dependencies: A CRL may not be available during
(CRL) may not be available during a network partition; a suitable a network partition; a suitable policy to not immediately disconnect
policy to not immediately disconnect neighbors when no CRL is neighbors when no CRL is available can address this issue. Also, an
available can address this issue. Also, an ACP registrar or ACP registrar or Certificate Authority might not be available during
Certificate Authority might not be available during a partition. a partition. This may delay renewal of certificates that are to
This may delay renewal of certificates that are to expire in the expire in the future, and it may prevent the enrollment of new nodes
future, and it may prevent the enrollment of new nodes during the during the partition.
partition.
Highly resilient ACP designs can be built by using ACP registrars Highly resilient ACP designs can be built by using ACP registrars
with embedded sub-CA, as outlined in Section 10.2.4. As long as a with embedded sub-CA, as outlined in Section 10.2.4. As long as a
partition is left with one or more of such ACP registrars, it can partition is left with one or more of such ACP registrars, it can
continue to enroll new candidate ACP nodes as long as the ACP continue to enroll new candidate ACP nodes as long as the ACP
registrar's sub-CA certificate does not expire. Because the ACP registrar's sub-CA certificate does not expire. Because the ACP
addressing relies on unique Registrar-IDs, a later re-merge of addressing relies on unique Registrar-IDs, a later re-merge of
partitions will also not cause problems with ACP addresses assigned partitions will also not cause problems with ACP addresses assigned
during partitioning. during partitioning.
skipping to change at page 88, line 39 skipping to change at page 93, line 42
An attacker will not be able to join the ACP unless having a valid An attacker will not be able to join the ACP unless having a valid
domain certificate, also packet injection and sniffing traffic will domain certificate, also packet injection and sniffing traffic will
not be possible due to the security provided by the encryption not be possible due to the security provided by the encryption
protocol. protocol.
The ACP also serves as protection (through authentication and The ACP also serves as protection (through authentication and
encryption) for protocols relevant to OAM that may not have secured encryption) for protocols relevant to OAM that may not have secured
protocol stack options or where implementation or deployment of those protocol stack options or where implementation or deployment of those
options 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 ([RFC1886]), 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. Protection via the ACP secure hop-by-hop channels for these few. Protection via the ACP secure hop-by-hop channels for these
protocols is meant to be only a stopgap though: The ultimate goal is protocols is meant to be only a stopgap though: The ultimate goal is
for these and other protocols to use end-to-end encryption utilizing for these and other protocols to use end-to-end encryption utilizing
the domain certificate and rely on the ACP secure channels primarily the domain certificate and rely on the ACP secure channels primarily
for zero-touch reliable connectivity, but not primarily for security. for zero-touch reliable connectivity, but not primarily for security.
The remaining attack vector would be to attack the underlying ACP The remaining attack vector would be to attack the underlying ACP
protocols themselves, either via directed attacks or by denial-of- protocols themselves, either via directed attacks or by denial-of-
skipping to change at page 95, line 11 skipping to change at page 100, line 15
The components of ACP and BRSKI are designed with security in mind The components of ACP and BRSKI are designed with security in mind
but they do not attempt to provide diagnostics for building the but they do not attempt to provide diagnostics for building the
network itself. Consider two examples: network itself. Consider two examples:
1. BRSKI does not allow for a neighboring device to identify the 1. BRSKI does not allow for a neighboring device to identify the
pledges certificate (IDevID). Only the selected BRSKI registrar pledges certificate (IDevID). Only the selected BRSKI registrar
can do this, but it may be difficult to disseminate information can do this, but it may be difficult to disseminate information
about undesired pledges from those BRSKI registrars to locations/ about undesired pledges from those BRSKI registrars to locations/
nodes where information about those pledges is desired. nodes where information about those pledges is desired.
2. The Link Layer Discovery Protocol (LLDP, [LLDP]) disseminates 2. LLDP disseminates information about nodes to their immediate
information about nodes to their immediate neighbors, such as neighbors, such as node model/type/software and interface name/
node model/type/software and interface name/number of the number of the connection. This information is often helpful or
connection. This information is often helpful or even necessary even necessary in network diagnostics. It can equally considered
in network diagnostics. It can equally considered to be too to be too insecure to make this information available unprotected
insecure to make this information available unprotected to all to all possible neighbors.
possible neighbors.
An "interested adjacent party" can always determine the IDevID of a An "interested adjacent party" can always determine the IDevID of a
BRSKI pledge by behaving like a BRSKI proxy/registrar. Therefore the BRSKI pledge by behaving like a BRSKI proxy/registrar. Therefore the
IDevID of a BRSKI pledge is not meant to be protected - it just has IDevID of a BRSKI pledge is not meant to be protected - it just has
to be queried and is not signaled unsolicited (as it would be in to be queried and is not signaled unsolicited (as it would be in
LLDP) so that other observers on the same subnet can determine who is LLDP) so that other observers on the same subnet can determine who is
an "interested adjacent party". an "interested adjacent party".
10.2. ACP Registrars 10.2. ACP Registrars
skipping to change at page 96, line 19 skipping to change at page 101, line 21
(and by default should be) completely isolated from each other at the (and by default should be) completely isolated from each other at the
network level. Only applications such as the ACP registrar would network level. Only applications such as the ACP registrar would
need the ability for their transport stacks to access both. need the ability for their transport stacks to access both.
In non-autonomic enrollment options, the Data-Plane between a ACP In non-autonomic enrollment options, the Data-Plane between a ACP
registrar and the candidate ACP node needs to be configured first. registrar and the candidate ACP node needs to be configured first.
This includes the ACP registrar and the candidate ACP node. Then any This includes the ACP registrar and the candidate ACP node. Then any
appropriate set of protocols can be used between ACP registrar and appropriate set of protocols can be used between ACP registrar and
candidate ACP node to discover the other side, and then connect and candidate ACP node to discover the other side, and then connect and
enroll (configure) the candidate ACP node with an ACP domain enroll (configure) the candidate ACP node with an ACP domain
certificate. Netconf ZeroTouch ([I-D.ietf-netconf-zerotouch]) is an certificate. Netconf ZeroTouch ([RFC8572]) is an example protocol
example protocol that could be used for this. BRSKI using optional that could be used for this. BRSKI using optional discovery
discovery mechanisms is equally a possibility for candidate ACP nodes mechanisms is equally a possibility for candidate ACP nodes
attempting to be enrolled across non-ACP networks, such as the attempting to be enrolled across non-ACP networks, such as the
Internet. Internet.
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
skipping to change at page 101, line 41 skipping to change at page 106, line 43
10.3.2.2. Fast state propagation and Diagnostics 10.3.2.2. Fast state propagation and Diagnostics
"Physical down" state propagates on many interface types (e.g., "Physical down" state propagates on many interface types (e.g.,
Ethernet) to the other side. This can trigger fast L2/L3 protocol Ethernet) to the other side. This can trigger fast L2/L3 protocol
reaction on the other side and "admin down" would not have the same reaction on the other side and "admin down" would not have the same
(fast) result. (fast) result.
Bringing interfaces to "physical down" state is to the best of our Bringing interfaces to "physical down" state is to the best of our
knowledge always a result of operator action, but today, never the knowledge always a result of operator action, but today, never the
result of (autonomic) L2/L3 services running on the nodes. Therefore result of autonomic L2/L3 services running on the nodes. Therefore
one option is to change the operator action to not rely on link-state one option is to change the operator action to not rely on link-state
propagation anymore. This may not be possible when both sides are propagation anymore. This may not be possible when both sides are
under different operator control, but in that case it is unlikely under different operator control, but in that case it is unlikely
that the ACP is running across the link and actually putting the that the ACP is running across the link and actually putting the
interface into "physical down" state may still be a good option. interface into "physical down" state may still be a good option.
Ideally, fast physical state propagation is replaced by fast software Ideally, fast physical state propagation is replaced by fast software
driven state propagation. For example a DULL GRASP "admin-state" driven state propagation. For example a DULL GRASP "admin-state"
objective could be used to auto configure a Bidirectional Forwarding objective could be used to auto configure a Bidirectional Forwarding
Protocol (BFD, [RFC5880]) session between the two sides of the link Protocol (BFD, [RFC5880]) session between the two sides of the link
skipping to change at page 111, line 7 skipping to change at page 116, line 9
minimizing its dependency against any non-ACP (Data-Plane) minimizing its dependency against any non-ACP (Data-Plane)
operations/configuration on a node. See also Section 6.12.2. operations/configuration on a node. See also Section 6.12.2.
In combination with BRSKI, ACP enables a resilient, fully zero-touch In combination with BRSKI, ACP enables a resilient, fully zero-touch
network solution for short-lived certificates that can be renewed or network solution for short-lived certificates that can be renewed or
re-enrolled even after unintentional expiry (e.g., because of re-enrolled even after unintentional expiry (e.g., because of
interrupted connectivity). See Appendix A.2. interrupted connectivity). See Appendix A.2.
Because ACP secure channels can be long lived, but certificates used Because ACP secure channels can be long lived, but certificates used
may be short lived, secure channels, for example built via IPsec need may be short lived, secure channels, for example built via IPsec need
to be terminated when peer certificates expire. See Section 6.7.3. to be terminated when peer certificates expire. See Section 6.7.5.
The ACP is designed to minimize attacks from the outside by The ACP is designed to minimize attacks from the outside by
minimizing its dependency against any non-ACP (Data-Plane) minimizing its dependency against any non-ACP (Data-Plane)
operations/configuration on a node. See also Section 6.12.2. operations/configuration on a node. See also Section 6.12.2.
Section 7.2 describes how to implement a routed ACP topology
operating on what effectively is a large bridge-domain when using L3/
L2 routers that operate at L2 in the data-plane. In this case, the
ACP is subject to much higher likelyhood of attacks by other nodes
"stealing" L2 addresses than in the actual routed case. Especially
when the bridged network includes non-trusted devices such as hosts.
This is a generic issue in L2 LANs. L2/L3 devices often already have
some form of "port security" to prohibit this. They rely on NDP or
DHCP learning of which port/MAC-address and IPv6 address belong
together and block MAC/IPv6 source addresses from wrong ports. This
type of function needs to be enabled to prohibit DoS attacks and
specifically to protect the ACP. Likewise the GRASP DULL instance
needs to ensure that the IPv6 address in the locator-option matches
the source IPv6 address of the DULL GRASP packet.
12. IANA Considerations 12. IANA Considerations
This document defines the "Autonomic Control Plane". This document defines the "Autonomic Control Plane".
The IANA is requested to register the value "AN_ACP" (without quotes) The IANA is requested to register the value "AN_ACP" (without quotes)
to the GRASP Objectives Names Table in the GRASP Parameter Registry. to the GRASP Objectives Names Table in the GRASP Parameter Registry.
The specification for this value is this document, Section 6.3. The specification for this value is this document, Section 6.3.
The IANA is requested to register the value "SRV.est" (without The IANA is requested to register the value "SRV.est" (without
quotes) to the GRASP Objectives Names Table in the GRASP Parameter quotes) to the GRASP Objectives Names Table in the GRASP Parameter
skipping to change at page 115, line 19 skipping to change at page 120, line 34
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-22 14.2. draft-ietf-anima-autonomic-control-plane-23
Note: big rfcdiff of TOC is an rfcdiff bug, changes really minimal.
Review of IPsec security with Mcr and ipsec mailing list.
6.7.1 - new section: Moved general considerations for secure channel
protocols here, refined them.
6.7.2 - new section: Moved common requirements for secure channel
protocols here, refined them.
6.7.3.1.1. - improved requirements text related to RFC8221, better
explamations re. HW acceleration issues.
6.7.3.1.2. - improved requirements text related to RFC8247, (some
requirements still discussed to be redundant, will be finalized in
next weeks.
Eric Vyncke review of -21:
Only noting most important changes, long list of smaller text/
readability enhancements.
2. - New explanation of "normative" , "informational" section title
tags. alphabetic reordering of terms, refined definitions for CA,
CRL. root CA.
6.1.1. - explanation when IDevID parameters may be copied into
LDevID.
6.1.2. - Fixed hex digits in ACP domain information to lower case.
6.1.3.1. - New section on Realtime clock and Time Validation.
6.3 - Added explanation that DTLS means >= version 1.2 (not only
1.2).
6.7 - New text in this main section explaing relationship of ACP
secure channels and ACP virtual interfaces - with forward references
to virtual interface section.
6.8.2 - reordered text and picture, no text change.
6.10.7.2 - describe first how Registrar-ID can be allocted for all
type of registrars, then refined text for how to potentially use MAC
addresses on physical registrars.
6.11.1.1 - Added text how this profile does not use data-plane
artefacts (RPI) because hadware forwarding. This was previously
hidden only later in the text.
6.11.1.13. - Rewrote RPL data-plane artefact text. Provide decoder
ring for abbreviations and all relevant RFCs.
6.12.5.2. - Added more explicit text that secure channels are mapped
into virtual interfaces, moved different type of interfaces used by
ACP into seperate subsections to be able to refer to them.
7.2 - Rewrote/refined text for ACP on L2, prior text was confusing
and did not well explain why ACP for L2/L3 switches can be
implemented without any L2 (HW) changes. Also missing explanation of
only running GRASP untagged when VLANs are used.
8.1.1 - Added requirement for ACP Edge nodes to allow configurable
filtering of IPv6 RPI headers.
11. - (security section). Moved explanation of address stealing from
7.2 to here.
14.3. 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 117, line 25 skipping to change at page 124, line 17
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor-
cddl-08 (work in progress), March 2019.
[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>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005,
<https://www.rfc-editor.org/info/rfc4106>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
skipping to change at page 120, line 18 skipping to change at page 126, line 43
Payload (ESP) and Authentication Header (AH)", RFC 8221, Payload (ESP) and Authentication Header (AH)", RFC 8221,
DOI 10.17487/RFC8221, October 2017, DOI 10.17487/RFC8221, October 2017,
<https://www.rfc-editor.org/info/rfc8221>. <https://www.rfc-editor.org/info/rfc8221>.
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
"Algorithm Implementation Requirements and Usage Guidance "Algorithm Implementation Requirements and Usage Guidance
for the Internet Key Exchange Protocol Version 2 (IKEv2)", for the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8247, DOI 10.17487/RFC8247, September 2017, RFC 8247, DOI 10.17487/RFC8247, September 2017,
<https://www.rfc-editor.org/info/rfc8247>. <https://www.rfc-editor.org/info/rfc8247>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
15.2. Informative References 15.2. Informative References
[AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[CABFORUM] [CABFORUM]
CA/Browser Forum, "Certificate Contents for Baseline SSL", CA/Browser Forum, "Certificate Contents for Baseline SSL",
Nov 2019, <https://cabforum.org/baseline-requirements- Nov 2019, <https://cabforum.org/baseline-requirements-
skipping to change at page 120, line 46 skipping to change at page 127, line 33
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] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-34 (work in progress), January 2020. keyinfra-35 (work in progress), February 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-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero
Touch Provisioning (SZTP)", draft-ietf-netconf-
zerotouch-29 (work in progress), January 2019.
[I-D.ietf-roll-applicability-template] [I-D.ietf-roll-applicability-template]
Richardson, M., "ROLL Applicability Statement Template", Richardson, M., "ROLL Applicability Statement Template",
draft-ietf-roll-applicability-template-09 (work in draft-ietf-roll-applicability-template-09 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPI Robles, I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes and IPv6-in- option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", draft-ietf- IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-34 (work in progress), January 2020. roll-useofrplinfo-36 (work in progress), February 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-34 (work in progress), 1.3", draft-ietf-tls-dtls13-34 (work in progress),
November 2019. November 2019.
[IEEE-1588-2008] [IEEE-1588-2008]
IEEE, "IEEE Standard for a Precision Clock Synchronization IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
skipping to change at page 122, line 19 skipping to change at page 129, line 5
2006.html>. 2006.html>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989, RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>. <https://www.rfc-editor.org/info/rfc1112>.
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993, TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993,
<https://www.rfc-editor.org/info/rfc1492>. <https://www.rfc-editor.org/info/rfc1492>.
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, DOI 10.17487/RFC1886, December 1995,
<https://www.rfc-editor.org/info/rfc1886>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, DOI 10.17487/RFC2821, April 2001, RFC 2821, DOI 10.17487/RFC2821, April 2001,
<https://www.rfc-editor.org/info/rfc2821>. <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,
skipping to change at page 123, line 11 skipping to change at page 129, line 47
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002, DOI 10.17487/RFC3411, December 2002,
<https://www.rfc-editor.org/info/rfc3411>. <https://www.rfc-editor.org/info/rfc3411>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>.
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export
Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,
<https://www.rfc-editor.org/info/rfc3954>. <https://www.rfc-editor.org/info/rfc3954>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005, DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>. <https://www.rfc-editor.org/info/rfc4007>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
skipping to change at page 125, line 5 skipping to change at page 131, line 50
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) [RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
<https://www.rfc-editor.org/info/rfc6402>. <https://www.rfc-editor.org/info/rfc6402>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
skipping to change at page 127, line 5 skipping to change at page 134, line 11
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)", Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018, RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>. <https://www.rfc-editor.org/info/rfc8368>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
15.3. URIs 15.3. URIs
[1] https://en.wikipedia.org/wiki/Operational_Technology [1] https://en.wikipedia.org/wiki/Operational_Technology
[2] https://en.wikipedia.org/wiki/Single-root_input/ [2] https://en.wikipedia.org/wiki/Single-root_input/
output_virtualization output_virtualization
Appendix A. Background and Futures (Informative) Appendix A. Background and Futures (Informative)
The following sections discuss additional background information The following sections discuss additional background information
skipping to change at page 128, line 7 skipping to change at page 135, line 17
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. domain certificates.
A.2. BRSKI Bootstrap (ANI) A.2. BRSKI Bootstrap (ANI)
[I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes BRSKI describes how nodes with an IDevID certificate can securely and
with an IDevID certificate can securely and zero-touch enroll with a zero-touch enroll with an LDevID to support the ACP. BRSKI also
domain certificate (LDevID) to support the ACP. BRSKI also leverages leverages the ACP to enable zero-touch bootstrap of new nodes across
the ACP to enable zero-touch bootstrap of new nodes across networks networks without any configuration requirements across the transit
without any configuration requirements across the transit nodes nodes (e.g., no DHCP/DNS forwarding/server setup). This includes
(e.g., no DHCP/DNS forwarding/server setup). This includes otherwise otherwise not configured networks as described in Section 3.2.
not configured networks as described in Section 3.2. Therefore BRSKI Therefore BRSKI in conjunction with ACP provides for a secure and
in conjunction with ACP provides for a secure and zero-touch zero-touch management solution for complete networks. Nodes
management solution for complete networks. Nodes supporting such an supporting such an infrastructure (BRSKI and ACP) are called ANI
infrastructure (BRSKI and ACP) are called ANI nodes (Autonomic nodes (Autonomic Networking Infrastructure), see
Networking Infrastructure), see [I-D.ietf-anima-reference-model]. [I-D.ietf-anima-reference-model]. Nodes that do not support an
Nodes that do not support an IDevID but only an (insecure) vendor IDevID but only an (insecure) vendor specific Unique Device
specific Unique Device Identifier (UDI) or nodes whose manufacturer Identifier (UDI) or nodes whose manufacturer does not support a MASA
does not support a MASA could use some future security reduced could use some future security reduced version of BRSKI.
version of BRSKI.
When BRSKI is used to provision a domain certificate (which is called When BRSKI is used to provision a domain certificate (which is called
enrollment), the BRSKI registrar (acting as an enhanced EST server) enrollment), the BRSKI registrar (acting as an enhanced EST server)
must include the subjectAltName / rfc822Name encoded ACP address and must include the subjectAltName / rfc822Name encoded ACP address and
domain name to the enrolling node (called pledge) via its response to domain name to the enrolling node (called pledge) via its response to
the pledges EST CSR Attribute request that is mandatory in BRSKI. the pledges EST CSR Attribute request that is mandatory in BRSKI.
The Certificate Authority in an ACP network must not change the The Certificate Authority in an ACP network must not change the
subjectAltName / rfc822Name in the certificate. The ACP nodes can subjectAltName / rfc822Name in the certificate. The ACP nodes can
therefore find their ACP address and domain using this field in the therefore find their ACP address and domain using this field in the
skipping to change at page 129, line 7 skipping to change at page 136, line 17
unnecessary because the BRSKI registrar in conjunction with the CA unnecessary because the BRSKI registrar in conjunction with the CA
would not renew revoked certificates - only a "Do-not-renew" list would not renew revoked certificates - only a "Do-not-renew" list
would be necessary on BRSKI registrars/CA. would be necessary on BRSKI registrars/CA.
In the absence of BRSKI or less secure variants thereof, provisioning In the absence of BRSKI or less secure variants thereof, provisioning
of certificates may involve one or more touches or non-standardized of certificates may involve one or more touches or non-standardized
automation. Node vendors usually support provisioning of automation. Node vendors usually support provisioning of
certificates into nodes via PKCS#7 (see [RFC2315]) and may support certificates into nodes via PKCS#7 (see [RFC2315]) and may support
this provisioning through vendor specific models via Netconf this provisioning through vendor specific models via Netconf
([RFC6241]). If such nodes also support Netconf Zero-Touch ([RFC6241]). If such nodes also support Netconf Zero-Touch
([I-D.ietf-netconf-zerotouch]) then this can be combined to zero- ([RFC8572]) then this can be combined to zero-touch provisioning of
touch provisioning of domain certificates into nodes. Unless there domain certificates into nodes. Unless there are equivalent
are equivalent integration of Netconf connections across the ACP as integration of Netconf connections across the ACP as there is in
there is in BRSKI, this combination would not support zero-touch BRSKI, this combination would not support zero-touch bootstrap across
bootstrap across a not configured network though. a not configured network though.
A.3. ACP Neighbor discovery protocol selection A.3. ACP Neighbor discovery protocol selection
This section discusses why GRASP DULL was chosen as the discovery This section discusses why GRASP DULL was chosen as the discovery
protocol for L2 adjacent candidate ACP neighbors. The contenders protocol for L2 adjacent candidate ACP neighbors. The contenders
considered where GRASP, mDNS or LLDP. considered where GRASP, mDNS or LLDP.
A.3.1. LLDP A.3.1. LLDP
LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example
skipping to change at page 130, line 47 skipping to change at page 138, line 10
protocol must therefore support domains of 100,000 nodes or more, protocol must therefore support domains of 100,000 nodes or more,
ideally without the need for zoning or separation into areas. RPL ideally without the need for zoning or separation into areas. RPL
has this scale property. This is based on extensive use of has this scale property. This is based on extensive use of
default routing. default routing.
o Low resource consumption: The ACP supports traditional network o Low resource consumption: The ACP supports traditional network
infrastructure, thus runs in addition to traditional protocols. infrastructure, thus runs in addition to traditional protocols.
The ACP, and specifically the routing protocol must have low The ACP, and specifically the routing protocol must have low
resource consumption both in terms of memory and CPU requirements. resource consumption both in terms of memory and CPU requirements.
Specifically, at edge nodes, where memory and CPU are scarce, Specifically, at edge nodes, where memory and CPU are scarce,
consumption should be minimal. RPL builds a destination-oriented consumption should be minimal. RPL builds a DODAG, where the main
directed acyclic graph (DODAG), where the main resource resource consumption is at the root of the DODAG. The closer to
consumption is at the root of the DODAG. The closer to the edge the edge of the network, the less state needs to be maintained.
of the network, the less state needs to be maintained. This This adapts nicely to the typical network design. Also, all
adapts nicely to the typical network design. Also, all changes changes below a common parent node are kept below that parent
below a common parent node are kept below that parent node. node.
o Support for unstructured address space: In the Autonomic o Support for unstructured address space: In the Autonomic
Networking Infrastructure, node addresses are identifiers, and may Networking Infrastructure, node addresses are identifiers, and may
not be assigned in a topological way. Also, nodes may move not be assigned in a topological way. Also, nodes may move
topologically, without changing their address. Therefore, the topologically, without changing their address. Therefore, the
routing protocol must support completely unstructured address routing protocol must support completely unstructured address
space. RPL is specifically made for mobile ad-hoc networks, with space. RPL is specifically made for mobile ad-hoc networks, with
no assumptions on topologically aligned addressing. no assumptions on topologically aligned addressing.
o Modularity: To keep the initial implementation small, yet allow o Modularity: To keep the initial implementation small, yet allow
skipping to change at page 132, line 30 skipping to change at page 139, line 45
IGP. This would be a possible optimization in future variations of IGP. This would be a possible optimization in future variations of
the ACP that do use an LSP routing protocol. Note though that such a the ACP that do use an LSP routing protocol. Note though that such a
mechanism would not work easily for GRASP M_DISCOVERY messages which mechanism would not work easily for GRASP M_DISCOVERY messages which
are intelligently (constrained) flooded not across the whole ACP, but are intelligently (constrained) flooded not across the whole ACP, but
only up to a node where a responder is found. We do expect that many only up to a node where a responder is found. We do expect that many
future services in ASA will have only few consuming ASA, and for future services in ASA will have only few consuming ASA, and for
those cases, M_DISCOVERY is the more efficient method than flooding those cases, M_DISCOVERY is the more efficient method than flooding
across the whole domain. across the whole domain.
Because the ACP uses RPL, one desirable future extension is to use Because the ACP uses RPL, one desirable future extension is to use
RPLs existing notion of loop-free distribution trees (DODAG) to make RPLs existing notion of DODAG, which are loop-free distribution
GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See trees, to make GRASP flooding more efficient both for M_FLOOD and
Section 6.12.5 how this will be specifically beneficial when using M_DISCOVERY. See Section 6.12.5 how this will be specifically
NBMA interfaces. This is not currently specified in this document beneficial when using NBMA interfaces. This is not currently
because it is not quite clear yet what exactly the implications are specified in this document because it is not quite clear yet what
to make GRASP flooding depend on RPL DODAG convergence and how exactly the implications are to make GRASP flooding depend on RPL
difficult it would be to let GRASP flooding access the DODAG DODAG convergence and how difficult it would be to let GRASP flooding
information. access the DODAG information.
A.6. Extending ACP channel negotiation (via GRASP) A.6. Extending ACP channel negotiation (via GRASP)
[RFC Editor: This section to be removed before RFC. [RFC Editor: This section to be removed before RFC.
[This section kept for informational purposes up until the last draft [This section kept for informational purposes up until the last draft
version as that would be the version that readers interested in the version as that would be the version that readers interested in the
changelog would also go to to revisit it.] changelog would also go to to revisit it.]
The mechanism described in the normative part of this document to The mechanism described in the normative part of this document to
skipping to change at page 133, line 29 skipping to change at page 140, line 42
IKEv2 is the IETF standard protocol to negotiate network security IKEv2 is the IETF standard protocol to negotiate network security
associations. It is meant to be extensible, but it is unclear associations. It is meant to be extensible, but it is unclear
whether it would be feasible to extend IKEv2 to support possible whether it would be feasible to extend IKEv2 to support possible
future requirements for ACP secure channel negotiation: future requirements for ACP secure channel negotiation:
Consider the simple case where the use of native IPsec vs. IPsec via Consider the simple case where the use of native IPsec vs. IPsec via
GRE is to be negotiated and the objective is the maximum throughput. GRE is to be negotiated and the objective is the maximum throughput.
Both sides would indicate some agreed upon performance metric and the Both sides would indicate some agreed upon performance metric and the
preferred encapsulation is the one with the higher performance of the preferred encapsulation is the one with the higher performance of the
slower side. IKEv2 does not support negotiation with this objective. slower side. IKEv2 does not support negotiation with such
objectives.
Consider DTLS and some form of MacSec are to be added as negotiation Consider DTLS and some form of MacSec are to be added as negotiation
options - and the performance objective should work across all IPsec, options - and the performance objective should work across all IPsec,
DTLS and MacSec options. In the case of MacSEC, the negotiation DTLS and MacSec options. In the case of MacSEC, the negotiation
would also need to determine a key for the peering. It is unclear if would also need to determine a key for the peering. It is unclear if
it would be even appropriate to consider extending the scope of it would be even appropriate to consider extending the scope of
negotiation in IKEv2 to those cases. Even if feasible to define, it negotiation in IKEv2 to those cases. Even if feasible to define, it
is unclear if implementations of IKEv2 would be eager to adopt those is unclear if implementations of IKEv2 would be eager to adopt those
type of extension given the long cycles of security testing that type of extension given the long cycles of security testing that
necessarily goes along with core security protocols such as IKEv2 necessarily goes along with core security protocols such as IKEv2
skipping to change at page 134, line 43 skipping to change at page 142, line 8
A.7. CAs, domains and routing subdomains A.7. CAs, domains and routing subdomains
There is a wide range of setting up different ACP solution by There is a wide range of setting up different ACP solution by
appropriately using CAs and the domain and rsub elements in the appropriately using CAs and the domain and rsub elements in the
domain information field of the domain certificate. We summarize domain information field of the domain certificate. We summarize
these options here as they have been explained in different parts of these options here as they have been explained in different parts of
the document in before and discuss possible and desirable extensions: the document in before and discuss possible and desirable extensions:
An ACP domain is the set of all ACP nodes using certificates from one An ACP domain is the set of all ACP nodes using certificates from one
or more Trust Anchors (TA) (typically one CA) using the same domain or more Trust Anchors (typically one CA) using the same domain field.
field. GRASP inside the ACP is run across all transitively connected GRASP inside the ACP is run across all transitively connected ACP
ACP nodes in a domain. nodes in a domain.
The rsub element in the domain information field permits the use of The rsub element in the domain information field permits the use of
addresses from different ULA prefixes. One use case is to create addresses from different ULA prefixes. One use case is to create
multiple physical networks that initially may be separated with one multiple physical networks that initially may be separated with one
ACP domain but different routing subdomains, so that all nodes can ACP domain but different routing subdomains, so that all nodes can
mutual trust their ACP domain certificates (not depending on rsub) mutual trust their ACP domain certificates (not depending on rsub)
and so that they could connect later together into a contiguous ACP and so that they could connect later together into a contiguous ACP
network. 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
skipping to change at page 136, line 13 skipping to change at page 143, line 27
ACP itself. ACP itself.
For example, Intent could indicate the desire to build an ACP across For example, Intent could indicate the desire to build an ACP across
all domains that have a common parent domain (without relying on the all domains that have a common parent domain (without relying on the
rsub/routing-subdomain solution defined in this document). For rsub/routing-subdomain solution defined in this document). For
example ACP nodes with domain "example.com", "access.example.com", example ACP nodes with domain "example.com", "access.example.com",
"core.example.com" and "city.core.example.com" should all establish "core.example.com" and "city.core.example.com" should all establish
one single ACP. one single ACP.
If each domain has its own source of Intent, then the Intent would If each domain has its own source of Intent, then the Intent would
simply have to allow adding the peer domains trust anchors (CA) and simply have to allow adding the peer domains TA and domain names to
domain names to the ACP domain membership check (Section 6.1.3) so the parameters for the ACP domain membership check (Section 6.1.3) so
that nodes from those other domains are accepted as ACP peers. that nodes from those other domains are accepted as ACP peers.
If this Intent was to be originated only from one domain, it could If this Intent was to be originated only from one domain, it could
likely not be made to work because the other domains will not build likely not be made to work because the other domains will not build
any ACP connection amongst each other, whether they use the same or any ACP connection amongst each other, whether they use the same or
different CA due to the ACP domain membership check. different CA due to the ACP domain membership check.
If the domains use the same CA one could change the ACP setup to If the domains use the same CA one could change the ACP setup to
permit for the ACP to be established between two ACP nodes with permit for the ACP to be established between two ACP nodes with
different acp-domain-names, but only for the purpose of disseminating different acp-domain-names, but only for the purpose of disseminating
skipping to change at page 137, line 49 skipping to change at page 145, line 15
additional code space footprint for the ACP on those devices. Hop- additional code space footprint for the ACP on those devices. Hop-
by-hop reliability for ACP GRASP messages could be made to support by-hop reliability for ACP GRASP messages could be made to support
protocols like DTLS by adding the same type of negotiation as defined protocols like DTLS by adding the same type of negotiation as defined
in this document for ACP secure channel protocol negotiation. End- in this document for ACP secure channel protocol negotiation. End-
to-end GRASP connections can be made to select their transport to-end GRASP connections can be made to select their transport
protocol in future extensions of the ACP meant to better support protocol in future extensions of the ACP meant to better support
constrained devices by indicating the supported transport protocols constrained devices by indicating the supported transport protocols
(e.g.: TLS/DTLS) via GRASP parameters of the GRASP objective through (e.g.: TLS/DTLS) via GRASP parameters of the GRASP objective through
which the transport endpoint is discovered. which the transport endpoint is discovered.
The routing protocol chosen by the ACP design (RPL) does explicitly The routing protocol RPL used for the ACP does explicitly not
not optimize for shortest paths and fastest convergence. Variations optimize for shortest paths and fastest convergence. Variations of
of the ACP may want to use a different routing protocol or introduce the ACP may want to use a different routing protocol or introduce
more advanced RPL profiles. more advanced RPL profiles.
Variations such as what routing protocol to use, or whether to Variations such as what routing protocol to use, or whether to
instantiate an ACP in a VRF or (as suggested above) as the actual instantiate an ACP in a VRF or (as suggested above) as the actual
Data-Plane, can be automatically chosen in implementations built to Data-Plane, can be automatically chosen in implementations built to
support multiple options by deriving them from future parameters in support multiple options by deriving them from future parameters in
the certificate. Parameters in certificates should be limited to the certificate. Parameters in certificates should be limited to
those that would not need to be changed more often than certificates those that would not need to be changed more often than certificates
would need to be updated anyhow; Or by ensuring that these parameters would need to be updated anyhow; Or by ensuring that these parameters
can be provisioned before the variation of an ACP is activated in a can be provisioned before the variation of an ACP is activated in a
skipping to change at page 140, line 22 skipping to change at page 147, line 25
| | . | | .
ACP3 --------------------------- ACP4 . ACP3 --------------------------- ACP4 .
| metric 100 | | metric 100 |
| | . | | .
| | . Sites | | . Sites
ACP10 ACP11 . ACP10 ACP11 .
Figure 18: Dual NOC Figure 18: Dual NOC
The profile for RPL specified in this document builds only one The profile for RPL specified in this document builds only one
spanning-tree path set to a root (NOC). In the presence of multiple spanning-tree path set to a root, typically a registrar in one NOC.
NOCs, routing toward the non-root NOCs may be suboptimal. Figure 18 In the presence of multiple NOCs, routing toward the non-root NOCs
shows an extreme example. Assuming that node ACP1 becomes the RPL may be suboptimal. Figure 18 shows an extreme example. Assuming
root, traffic between ACP11 and NOC2 will pass through that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2
ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because
DODAG/routes are shortest paths towards the RPL root. the RPL calculated DODAG/routes are shortest paths towards the RPL
root.
To overcome these limitations, extensions/modifications to the RPL To overcome these limitations, extensions/modifications to the RPL
profile can provide optimality for multiple NOCs. This requires profile can provide optimality for multiple NOCs. This requires
utilizing Data-Plane artifact including IPinIP encap/decap on ACP utilizing Data-Plane artifact including IPinIP encap/decap on ACP
routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst)
routing table entries could be used. routing table entries could be used.
Flooding of ACP GRASP messages can be further constrained and Flooding of ACP GRASP messages can be further constrained and
therefore optimized by flooding only via links that are part of the therefore optimized by flooding only via links that are part of the
RPL DODAG. RPL DODAG.
 End of changes. 185 change blocks. 
729 lines changed or deleted 1068 lines changed or added

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