draft-ietf-anima-autonomic-control-plane-16.txt   draft-ietf-anima-autonomic-control-plane-17.txt 
ANIMA WG T. Eckert, Ed. ANIMA WG T. Eckert, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track M. Behringer, Ed. Intended status: Standards Track M. Behringer, Ed.
Expires: December 10, 2018 Expires: February 8, 2019
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
June 8, 2018 August 07, 2018
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-16 draft-ietf-anima-autonomic-control-plane-17
Abstract Abstract
Autonomic functions need a control plane to communicate, which Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Management depends on some addressing and routing. This Autonomic Management
and Control Plane should ideally be self-managing, and as independent and Control Plane should ideally be self-managing, and as independent
as possible of configuration. This document defines such a plane and as possible of configuration. This document defines such a plane and
calls it the "Autonomic Control Plane", with the primary use as a calls it the "Autonomic Control Plane", with the primary use as a
control plane for autonomic functions. It also serves as a "virtual control plane for autonomic functions. It also serves as a "virtual
out-of-band channel" for Operations Administration and Management out-of-band channel" for Operations Administration and Management
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 December 10, 2018. This Internet-Draft will expire on February 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 5
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 7 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 9 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 9
3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 14 3. Use Cases for an Autonomic Control Plane (Informative) . . . 15
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 14 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 15
3.2. Secure Bootstrap over a not configured Network . . . . . 14 3.2. Secure Bootstrap over a not configured Network . . . . . 15
3.3. Data-Plane Independent Permanent Reachability . . . . . . 15 3.3. Data-Plane Independent Permanent Reachability . . . . . . 16
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 17
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 18
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 18 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 19
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 19 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20
6.1.1. Certificate Domain Information Field . . . . . . . . 20 6.1.1. Certificate Domain Information Field . . . . . . . . 21
6.1.2. ACP domain membership check . . . . . . . . . . . . . 22 6.1.2. ACP domain membership check . . . . . . . . . . . . . 23
6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 23 6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 24
6.1.3.1. GRASP objective for EST server . . . . . . . . . 23 6.1.3.1. GRASP objective for EST server . . . . . . . . . 25
6.1.3.2. Renewal . . . . . . . . . . . . . . . . . . . . . 25 6.1.3.2. Renewal . . . . . . . . . . . . . . . . . . . . . 26
6.1.3.3. Certificate Revocation Lists (CRLs) . . . . . . . 25 6.1.3.3. Certificate Revocation Lists (CRLs) . . . . . . . 26
6.1.3.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 26 6.1.3.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 27
6.1.3.5. Re-enrollment . . . . . . . . . . . . . . . . . . 26 6.1.3.5. Re-enrollment . . . . . . . . . . . . . . . . . . 27
6.1.3.6. Failing Certificates . . . . . . . . . . . . . . 27 6.1.3.6. Failing Certificates . . . . . . . . . . . . . . 29
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 28 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 29
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 29 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 30
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 32 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 33
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 32 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 34
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 34 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 35
6.7. Security Association protocols . . . . . . . . . . . . . 34 6.7. Security Association protocols . . . . . . . . . . . . . 35
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 34 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 35
6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 34 6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 36
6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 35 6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 36
6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 36 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 37
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 36 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 37
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 36 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 38
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 37 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 38
6.8.2. ACP as the Security and Transport substrate for GRASP 37 6.8.2. ACP as the Security and Transport substrate for GRASP 38
6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 39 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 40
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 40 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 41
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 41 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 42
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 41 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 42
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 42 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 43
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 43 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 44
6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 45 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 46
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 46 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 47
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 47 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 48
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 48 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 49
6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 48 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 49
6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 48 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 49
6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 49 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 50
6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 50 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 51
6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 51 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 52
6.10.7.5. Further Details . . . . . . . . . . . . . . . . 51 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 52
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 51 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 52
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 52 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 53
6.11.1.1. Summary . . . . . . . . . . . . . . . . . . . . 52 6.11.1.1. Summary . . . . . . . . . . . . . . . . . . . . 53
6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 53 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 54
6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 53 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 54
6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 53 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 54
6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 54 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 54
6.11.1.6. Objective Function . . . . . . . . . . . . . . . 54 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 54
6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 54 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 55
6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 54 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 55
6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 54 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 55
6.11.1.10. P2P communications . . . . . . . . . . . . . . . 54 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 55
6.11.1.11. IPv6 address configuration . . . . . . . . . . . 54 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 55
6.11.1.12. Administrative parameters . . . . . . . . . . . 55 6.11.1.12. Administrative parameters . . . . . . . . . . . 56
6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 55 6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 56
6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 55 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 56
6.12. General ACP Considerations . . . . . . . . . . . . . . . 55 6.12. General ACP Considerations . . . . . . . . . . . . . . . 56
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 56 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 56
6.12.2. Addressing of Secure Channels in the Data-Plane . . 56 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 57
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 56 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 57
6.12.4. Multiple links between nodes . . . . . . . . . . . . 57 6.12.4. Multiple links between nodes . . . . . . . . . . . . 58
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 57 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 58
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 60 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 61
7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 61 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 62
8. Support for Non-ACP Components (Normative) . . . . . . . . . 63 8. Support for Non-ACP Components (Normative) . . . . . . . . . 64
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 63 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 64
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 63 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 64
8.1.2. Software Components . . . . . . . . . . . . . . . . . 65 8.1.2. Software Components . . . . . . . . . . . . . . . . . 66
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 66 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 67
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 67 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 68
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 68 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 69
8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 69 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 70
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 69 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 70
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 71 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 71
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 71 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 72
9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 71 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 72
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 71 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 72
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 73 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 73
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 73 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 73
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 74 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 74
9.3. The Administrator View . . . . . . . . . . . . . . . . . 74 9.3. The Administrator View . . . . . . . . . . . . . . . . . 75
10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 75 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 75
10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 75 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 76
10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 80 10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 80
10.2.1. Registrar interactions . . . . . . . . . . . . . . . 80 10.2.1. Registrar interactions . . . . . . . . . . . . . . . 81
10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82
10.2.3. Certificate renewal and limitations . . . . . . . . 82 10.2.3. Certificate renewal and limitations . . . . . . . . 83
10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83
10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84
10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 84 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 85
10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85
10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85
10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86
10.3.2.2. Fast state propagation and Diagnostics . . . . . 86 10.3.2.2. Fast state propagation and Diagnostics . . . . . 87
10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87
10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 88 10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 88
10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88
10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88
10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90
10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90
10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91
10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91
10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92
11. Security Considerations . . . . . . . . . . . . . . . . . . . 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 92
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 94 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 95
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 94 14.1. Initial version . . . . . . . . . . . . . . . . . . . . 95
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 95 14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 95
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 95 14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 95
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 95 14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 95
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 95 14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 95
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 96 14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 96
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 96 14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 96
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 96 14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 97
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 97 14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 97
14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 97 14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 97
14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 97 14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 98
14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 98 14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 98
14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 98 14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 99
14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 100 14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 100
14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 102 14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 102
14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 104 14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 104
14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 105 14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 106
14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 106 14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 106
14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 107 14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 107
14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 109 14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 109
14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 113 14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 113
14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 113 14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 114
14.23. wish-list . . . . . . . . . . . . . . . . . . . . . . . 114 14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 114
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 116
15.1. Normative References . . . . . . . . . . . . . . . . . . 115 15.1. Normative References . . . . . . . . . . . . . . . . . . 116
15.2. Informative References . . . . . . . . . . . . . . . . . 117 15.2. Informative References . . . . . . . . . . . . . . . . . 119
Appendix A. Background and Futures (Informative) . . . . . . . . 121 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 123
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 122 Appendix A. Background and Futures (Informative) . . . . . . . . 123
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 122 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 124
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 123 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 124
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 124 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 126
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 124 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 126
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 124 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 126
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 125 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 126
A.5. ACP Information Distribution and multicast . . . . . . . 126 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 127
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 127 A.5. ACP Information Distribution and multicast . . . . . . . 128
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 129 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 129
A.8. Adopting ACP concepts for other environments . . . . . . 130 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 131
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 132 A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 132
A.9. Adopting ACP concepts for other environments . . . . . . 133
A.10. Further options / futures . . . . . . . . . . . . . . . . 135
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 135
A.10.2. More options for avoiding IPv6 Data-Plane dependency 135
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 136
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 136
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 137
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 137
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 137
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138
1. Introduction 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 Management and Control". For
naming consistency with that prior document, this document continues naming consistency with that prior document, this document continues
to use the name ACP though. to use the name ACP though.
skipping to change at page 6, line 19 skipping to change at page 6, line 29
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 Autonomic Control Plane (ACP), which is
a virtual in-band network designed to be as independent as possible a virtual in-band network designed to be as independent as possible
of configuration, addressing and routing problems. The details how of configuration, addressing and routing problems. The details how
this achieved are defined in Section 6. The ACP is designed to this are achieved as described in Section 6. The ACP is designed to
remains operational even in the presence of configuration errors, remain operational even in the presence of configuration errors,
addressing or routing issues, or where policy could inadvertently addressing or routing issues, or where policy could inadvertently
affect connectivity of both data packets or control packets. affect 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:
1. Autonomic functions communicate over the ACP. The ACP therefore 1. Autonomic functions communicate over the ACP. The ACP therefore
supports directly Autonomic Networking functions, as described in directly supports Autonomic Networking functions, as described in
[I-D.ietf-anima-reference-model]. For example, Generic Autonomic [I-D.ietf-anima-reference-model]. For example, Generic Autonomic
Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely Signaling Protocol (GRASP - [I-D.ietf-anima-grasp]) runs securely
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 bootstrap network devices in remote locations, even if the (Data-
network in between is not yet configured; no Data-Plane dependent Plane) network in between is not yet configured; no Data-Plane
bootstrap configuration is required. An example of such a secure dependent bootstrap configuration is required. An example of
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 log into remote devices, even if the
network is misconfigured or not configured. 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, and in Section 6 the process an overview how the ACP is constructed.
is defined in detail. Section 7 defines how to support ACP on L2
switches. Section 8 explains how non-ACP nodes and networks can be
integrated.
The following sections are non-normative: Section 9 reviews benefits The normative part of this document starts with Section 6, where the
the ACP is specified. Section 7 defines normative how to support ACP
on L2 switches. Section 8 explains normative how non-ACP nodes and
networks can be integrated.
The remaining sections are non-normative: Section 9 reviews benefits
of the ACP (after all the details have been defined), Section 10 of the ACP (after all the details have been defined), Section 10
provides operational recommendations, Appendix A provides additional provides operational recommendations, Appendix A provides additional
explanations and describes additional details or future work explanations and describes additional details or future standard or
possibilities that where considered not to be appropriate for propriety extensions that were considered not to be appropriate for
standardization in this document but were considered important to standardization in this document but were considered important to
document. document. There are no dependencies against Appendix A to build a
complete working and interoperable ACP according to this document.
The ACP provides secure IPv6 connectivity, therefore it can not only The ACP provides secure IPv6 connectivity, therefore it can not only
be used as the secure connectivity for self-management as required be used as the secure connectivity for self-management as required
for the ACP in [RFC7575], but it can also be used as the secure for the ACP in [RFC7575], but it can also be used as the secure
connectivity for traditional (centralized) management. The ACP can connectivity for traditional (centralized) management. The ACP can
be implemented and operated without any other components of autonomic be implemented and operated without any other components of autonomic
networks, except for the GRASP protocol which it leverages. networks, except for the GRASP protocol which it leverages.
The document "Using Autonomic Control Plane for Stable Connectivity The document "Using Autonomic Control Plane for Stable Connectivity
of Network OAM" [RFC8368] describes how the ACP alone can be used to of Network OAM" [RFC8368] describes how the ACP alone can be used to
skipping to change at page 7, line 41 skipping to change at page 8, line 6
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" 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 fully secure zero-touch (automated) connectivity (from ACP) with fully secure zero-touch (automated)
bootstrap from BRSKI. The ANI itself does not constitute an bootstrap from BRSKI. The ANI itself does not constitute an
Autonomic Network, but it allows the building of more or less Autonomic Network, but it allows the building of more or less
autonomic networks on top of it - using either centralized, Software autonomic networks on top of it - using either centralized, Software
Defined Networking (SDN) (see [RFC7426]), style automation or Defined Networking- (SDN-)style (see [RFC7426]) automation or
distributed automation via Autonomic Service Agents (ASA) / Autonomic distributed automation via Autonomic Service Agents (ASA) / Autonomic
Functions (AF) - or a mixture of both. See Functions (AF) - or a mixture of both. See
[I-D.ietf-anima-reference-model] for more information. [I-D.ietf-anima-reference-model] for more information.
1.1. Applicability and Scope 1.1. Applicability and Scope
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 equally on ->"Operational Technology" () (OT) networks. The ACP can operate
layer 3 equipment and on layer 2 equipment such a bridges (see equally on layer 3 equipment and on layer 2 equipment such a bridges
Section 7). The encryption mechanism used by the ACP is defined to (see Section 7). The encryption mechanism used by the ACP is defined
be negotiable, therefore it can be extended to environments with to be negotiable, therefore it can be extended to environments with
different encryption protocol preferences. The minimum different encryption protocol preferences. The minimum
implementation requirements in this document attempt to achieve implementation requirements in this document attempt to achieve
maximum interoperability by requiring support for few options: IPsec, maximum interoperability by requiring support for few options: IP
DTLS - depending on type of device. security (IPsec), see [RFC4301]) and datagram Transport Layer
Security version 1.2 (DTLS), see [RFC6347]), depending on type of
device.
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 RPL routing instance of IPv6 packet forwarding and routing via the Routing
protocol ([RFC6550]) that is separate from routing and forwarding for Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that
the Data-Plane (user traffic). is separate from routing and forwarding for the Data-Plane (user
traffic).
The ACP uses only IPv6 to avoid complexity of dual-stack ACP The ACP uses only IPv6 to avoid complexity of dual-stack ACP
operations (IPv6/IPv4). Nevertheless, it can without any changes be operations (IPv6/IPv4). Nevertheless, it can without any changes be
integrated into even otherwise IPv4-only network devices. The Data- integrated into even otherwise IPv4-only network devices. The Data-
Plane itself would not need to change, it could continue to be IPv4 Plane itself would not need to change, it could continue to be IPv4
only. For such IPv4 only devices, the IPv6 protocol itself would be only. For such IPv4 only devices, the IPv6 protocol itself would be
additional implementation footprint only used for the ACP. additional implementation footprint only used for the ACP.
The protocol choices of the ACP are primarily based on wide use and The protocol choices of the ACP are primarily based on wide use and
support in networks and devices, well understood security properties support in networks and devices, well understood security properties
skipping to change at page 9, line 10 skipping to change at page 9, line 24
GRASP is the only completely novel protocol used in the ACP, and this GRASP is the only completely novel protocol used in the ACP, and this
choice was necessary because there is no existing suitable protocol choice was necessary because there is no existing suitable protocol
to provide the necessary functions to the ACP, so GRASP was developed to provide the necessary functions to the ACP, so GRASP was developed
to fill that gap. to fill that gap.
The ACP design can be applicable to (cpu, memory) constrained devices The ACP design can be applicable to (cpu, memory) constrained devices
and (bitrate, reliability) constrained networks, but this document and (bitrate, reliability) constrained networks, but this document
does not attempt to define the most constrained type of devices or does not attempt to define the most constrained type of devices or
networks to which the ACP is applicable. RPL and DTLS are two networks to which the ACP is applicable. RPL and DTLS are two
protocol choices already making ACP more applicable to constrained protocol choices already making ACP more applicable to constrained
environments. See Appendix A.8 for discussions about how variations environments. See Appendix A.9 for discussions about how future
of the ACP could be defined in the future to better meet different standards or proprietary extensions/variations variations of the ACP
expectations from those on which the current design is based. could better meet different expectations from those on which the
current design is based.
2. Acronyms and Terminology 2. Acronyms and Terminology (Informative)
[RFC Editor: WG/IETF/IESG review of the terms below asked for
references betwen these terms when they refer to each other. The
only option in RFC/XML i found to point to a hanging text acronym
definition that also displays the actual term is the format="title"
version, which leads to references such as '->"ACP domain
certificate" ()'. I found no reasonable way to eliminate the
trailing '()' generated by this type of cross references. Can you
please take care of removing these artefacts during editing (after
conversion to nroff ?). Also created ticket to ask for xml2rfc
enhancement to avoid this in the future:
https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/347.
[RFC Editor: Question: Is it possible to change the first occurences
of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC
format does not seem to offer such a format, but i did not want to
duplicate 50 first references to be duplicate - one reference for
title mentioning and one for RFC number.]
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 10, line 14 skipping to change at page 10, line 46
ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate
(LDevID) carrying the domain information field which is used by (LDevID) carrying the domain information field which is used by
the ACP to learn its address in the ACP and to derive and the ACP to learn its address in the ACP and to derive and
cryptographically assert its membership in the ACP domain. cryptographically assert its membership in the ACP domain.
domain information (field): An rfc822Name information element (e.g., domain information (field): An rfc822Name information element (e.g.,
field) in the domain certificate in which the ACP relevant field) in the domain certificate in which the ACP relevant
information is encoded: the domain name and the ACP address. information is encoded: the domain name and the ACP address.
ACP Loopback interface: The Loopback interface in the ACP VRF that ACP Loopback interface: The Loopback interface in the ACP Virtual
has the ACP address assigned to it. Routing and Forwarding (VRF) that has the ACP address assigned to
it.
ACP network: The ACP network constitutes all the nodes that have ACP network: The ACP network constitutes all the nodes that have
access to the ACP. It is the set of active and transitively access to the ACP. It is the set of active and transitively
connected nodes of an ACP domain plus all nodes that get access to connected nodes of an ACP domain plus all nodes that get access to
the ACP of that domain via ACP edge nodes. the ACP of that domain via ACP edge nodes.
ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the ACP (ULA) prefix(es): The /48 IPv6 address prefixes used across the
ACP. In the normal/simple case, the ACP has one ULA prefix, see ACP. In the normal/simple case, the ACP has one ULA prefix, see
Section 6.10. The ACP routing table may include multiple ULA Section 6.10. The ACP routing table may include multiple ULA
prefixes if the "rsub" option is used to create addresses from prefixes if the "rsub" option is used to create addresses from
more than one ULA prefix. See Section 6.1.1. The ACP may also more than one ULA prefix. See Section 6.1.1. 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 security association established hop-by-hop ACP secure channel: A cryptographically authenticated and encrypted
between adjacent ACP nodes to carry traffic of the ACP VRF data connection established between (normally) adjacent ACP nodes
separated from Data-Plane traffic in-band over the same links as to carry traffic of the ACP VRF secure and isolated from Data-
the Data-Plane. 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,
Autonomic Functions and Intent. Autonomic Functions and Intent.
(AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the (AN) Domain Name: An FQDN (Fully Qualified Domain Name) in the
domain information field of the Domain Certificate. See domain information field of the Domain Certificate. See
Section 6.1.1. Section 6.1.1.
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 products 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.
skipping to change at page 11, line 27 skipping to change at page 12, line 15
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.
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 simple ACP or ANI node, the Data-Plane is typically provisioned by
non-autonomic, for example manually (including across the ACP) or means other than autonomically, for example manually (including
via SDN controllers. In a fully Autonomic Network node, the Data- across the ACP) or via SDN controllers. In a fully Autonomic
Plane is managed autonomically via Autonomic Functions and Intent. Network node, the Data-Plane is managed autonomically via
Note that other (non-ANIMA) RFC use the Data-Plane to refer to Autonomic Functions and Intent. Note that other (non-ANIMA) RFC
what is better called the forwarding plane. This is not the way use the Data-Plane to refer to what is better called the
the term is used in this document! forwarding plane. This is not the way the term is used in this
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 and IDevID) to a network and acquires a network specific identity and
trust anchor such as an LDevID. trust anchor such as an LDevID.
EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard EST: "Enrollment over Secure Transport" ([RFC7030]). IETF standard
protocol for enrollment of a node with an LDevID. BRSKI is based protocol for enrollment of a node with an LDevID. BRSKI is based
on EST. 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 future 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 can not be used for the ACP because they are not [AR8021]. IDevID can not be used for the ACP because they are not
provisioned by the owner of the network, so they can not directly provisioned by the owner of the network, so they can not directly
indicate an ACP domain they belong to. indicate an ACP domain they belong to.
skipping to change at page 12, line 49 skipping to change at page 13, line 37
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. node: A system, e.g., supporting the ACP according to this document.
Can be virtual or physical. Physical nodes are called devices. 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 bit (see xref target="Vlong"/>) last 64 (see Section 6.10.3) or 78 bits (see Section 6.10.5) of
of the ACP address. the ACP address.
Operational Technology (OT): "https://en.wikipedia.org/wiki/
Operational_Technology" [1]: "The hardware and software dedicated
to detecting or causing changes in physical processes through
direct monitoring and/or control of physical devices such as
valves, pumps, etc". OT networks are today in most cases well
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
dedicated management ports on the primary network equipment. dedicated management ports on the primary network equipment.
Serial (console) management ports where historically most common, Serial (console) management ports were historically most common,
higher end network equipment now also has ethernet ports dedicated higher end network equipment now also has ethernet ports dedicated
only for management. An out-of-band network provides management only for management. An out-of-band network provides management
access to the primary network independent of the configuration access to the primary network independent of the configuration
state of the primary network. 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
skipping to change at page 14, line 4 skipping to change at page 14, line 46
this document to refer to an IDevID. this document to refer to an IDevID.
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 bit 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".
(ACP) VRF: The ACP is modeled in this document as a "Virtual Routing (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing
and Forwarding" instance (VRF). This means that it is based on a and Forwarding" instance (VRF). This means that it is based on a
"virtual router" consisting of a separate IPv6 forwarding table to "virtual router" consisting of a separate IPv6 forwarding table to
which the ACP virtual interfaces are attached and an associated which the ACP virtual interfaces are attached and an associated
IPv6 routing table separate from the Data-Plane. Unlike the VRFs IPv6 routing table separate from the Data-Plane. Unlike the VRFs
on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF
does not have any special "core facing" functionality or routing/ does not have any special "core facing" functionality or routing/
mapping protocols shared across multiple VRFs. In vendor products mapping protocols shared across multiple VRFs. In vendor products
a VRF such as the ACP-VRF may also be referred to as a so called a VRF such as the ACP-VRF may also be referred to as a so called
VRF-lite. VRF-lite.
(ACP) Zone: An ACP zone is a connected region of the ACP where nodes (ACP) Zone: An ACP zone is a set of ACP nodes using the same zone
derive from their non-aggregatable ACP address (identifier field value in their ACP address according to Section 6.10.3.
address) an aggregatable ACP zone address (locator address). See Zones are a mechanism to support structured addressing of ACP
the definition of the ACP Zone Addressing Sub-Scheme addresses within the same /48 bit ULA prefix.
(Section 6.10.3). The complete definition of zones is subject to
future work because this document does not describe the routing
protocols details for aggregation of ACP zone addresses, but only
their addressing scheme.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC8174] when they appear in ALL CAPS. When these words are not in 14 [RFC2119],[RFC8174] when, and only when, they appear in all
ALL CAPS (such as "should" or "Should"), they have their usual capitals, as shown here.
English meanings, and are not to be interpreted as [RFC8174] key
words.
3. Use Cases for an Autonomic Control Plane 3. Use Cases for an Autonomic Control Plane (Informative)
3.1. An Infrastructure for Autonomic Functions 3.1. An Infrastructure for Autonomic Functions
Autonomic Functions need a stable infrastructure to run on, and all Autonomic Functions need a stable infrastructure to run on, and all
autonomic functions should use the same infrastructure to minimize autonomic functions should use the same infrastructure to minimize
the complexity of the network. This way, there is only need for a the complexity of the network. In this way, there is only need for a
single discovery mechanism, a single security mechanism, and other single discovery mechanism, a single security mechanism, and single
processes that distributed functions require. instances of other processes that distributed functions require.
3.2. Secure Bootstrap over a not configured Network 3.2. Secure Bootstrap over a not configured Network
Today, bootstrapping a new node typically requires all nodes between Today, bootstrapping a new node typically requires all nodes between
a controlling node such as an SDN controller ("Software Defined a controlling node such as an SDN controller ("Software Defined
Networking", see [RFC7426]) and the new node to be completely and Networking", see [RFC7426]) and the new node to be completely and
correctly addressed, configured and secured. Bootstrapping and correctly addressed, configured and secured. Bootstrapping and
configuration of a network happens in rings around the controller - configuration of a network happens in rings around the controller -
configuring each ring of devices before the next one can be configuring each ring of devices before the next one can be
bootstrapped. Without console access (for example through an out-of- bootstrapped. Without console access (for example through an out-of-
band network) it is not possible today to make devices securely band network) it is not possible today to make devices securely
reachable before having configured the entire network leading up to reachable before having configured the entire network leading up to
them. them.
With the ACP, secure bootstrap of new devices and whole new networks With the ACP, secure bootstrap of new devices and whole new networks
can happen without requiring any configuration of unconfigured can happen without requiring any configuration of unconfigured
devices along the path: As long as all devices along the path support devices along the path: As long as all devices along the path support
ACP and a zero-touch bootstrap mechanism like BRSKI, the ACP across a ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP
whole network of unconfigured devices can be brought up without across a whole network of unconfigured devices can be brought up
operator/provisioning intervention. The ACP also provides additional without operator/provisioning intervention. The ACP also provides
security for any bootstrap mechanism, because it encrypts the traffic additional security for any bootstrap mechanism, because it encrypts
along the path hop-by-hop. the traffic along the path hop-by-hop.
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 network management
protocols are using the Data-Plane of the network. This leads to protocols are using the Data-Plane of the network. This leads to
often undesirable dependencies between control and management plane often undesirable dependencies between control and management plane
on one side and the Data-Plane on the other: Only if the forwarding on one side and the Data-Plane on the other: Only if the forwarding
and control plane of the Data-Plane are configured correctly, will and control plane of the Data-Plane are configured correctly, will
the Data-Plane and the managment plane work as expected. the Data-Plane and the management 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 16, line 5 skipping to change at page 16, line 40
or mask changes, routing changes, or security policies. Today such or mask changes, routing changes, or security policies. Today such
changes require precise hop-by-hop planning. changes require precise hop-by-hop planning.
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.
The ACP provides reachability that is independent of the Data-Plane Assuming appropriate implementation (see Section 6.12.2 for more
(except for the dependency discussed in Section 6.12.2 which can be details), the ACP provides reachability that is independent of the
removed through future work), which allows the control plane and Data-Plane. This allows the control plane and management plane to
management plane to operate more robustly: operate 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
autonomic service agents, which could affect Data-Plane autonomic service agents, which could affect Data-Plane
connectivity. connectivity.
The document "Using Autonomic Control Plane for Stable Connectivity The document "Using Autonomic Control Plane for Stable Connectivity
of Network OAM" [RFC8368] explains this use case for the ACP in of Network OAM" [RFC8368] explains this use case for the ACP in
significantly more detail and explains how the ACP can be used in significantly more detail and explains how the ACP can be used in
practical network operations. practical network operations.
4. Requirements 4. Requirements (Informative)
The Autonomic Control Plane has the following requirements: The following requirements where identified as the basis for the
design of the ACP based on the above use-cases (Section 3). These
requirements are informative for this specification because they
(merely) represent the use-case requirements. The keywords are
therefore highlighted to be different from RFC2119. The ACP as
specified in the normative parts of this document is meeting or
exceeding these use-case requirements:
ACP1: The ACP SHOULD provide robust connectivity: As far as ACP1: The ACP _SHOULD_ provide robust connectivity: As far as
possible, it should be independent of configured addressing, possible, it should be independent of configured addressing,
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, security (can block easily at edge). Data-Plane, infrastructure security (filtering based on known
address space).
ACP3: The ACP MUST use autonomically managed address space. Reason: ACP3: The ACP _MUST_ use autonomically managed address space.
easy bootstrap and setup ("autonomic"); robustness (admin Reason: easy bootstrap and setup ("autonomic"); robustness
can't mess things up so easily). This document suggests using (admin can't mess things up so easily). This document
ULA addressing for this purpose ("Unique Local Address", see suggests using ULA addressing for this purpose ("Unique Local
[RFC4193]). Address", see [RFC4193]).
ACP4: The ACP MUST be generic. Usable by all the functions and ACP4: The ACP _MUST_ be generic, that is it MUST be usable by all
protocols of the ANI. Clients of the ACP MUST NOT be tied to the functions and protocols of the ANI. Clients of the ACP
a particular application or transport protocol. MUST 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
MUST be authenticated to be from a trusted node, and SHOULD ACP MUST be authenticated to be from a trusted node, and
(very strong SHOULD) be encrypted. SHOULD (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
written ASA could potentially all communicate exclusively via GRASP written ASA could potentially all communicate exclusively via GRASP
with each other, and if that was assumed to be the only requirement with each other, and if that was assumed to be the only requirement
against the ACP, it would not need to provide IPv6 layer connectivity against the ACP, it would not need to provide IPv6 layer connectivity
between nodes, but only GRASP connectivity. Nevertheless, because between nodes, but only GRASP connectivity. Nevertheless, because
ACP also intends to support non-AN networks, it it is crucial to ACP also intends to support non-AN networks, it it is crucial to
support IPv6 layer connectivity across the ACP to support any support IPv6 layer connectivity across the ACP to support any
transport and application layer protocols. transport and application layer protocols.
Th eACP operates hop-by-hop, because this interaction can be built on The ACP operates hop-by-hop, because this interaction can be built on
IPv6 link local addressing, which is autonomic, and has no dependency IPv6 link local addressing, which is autonomic, and has no dependency
on configuration (requirement 1). It may be necessary to have ACP on configuration (requirement 1). It may be necessary to have ACP
connectivity across non-ACP nodes, for example to link ACP nodes over connectivity across non-ACP nodes, for example to link ACP nodes over
the general Internet. This is possible, but introduces a dependency the general Internet. This is possible, but introduces a dependency
against stable/resilient routing over the non-ACP hops (see against stable/resilient routing over the non-ACP hops (see
Section 8.2). Section 8.2).
5. Overview 5. Overview (Informative)
The Autonomic Control Plane is constructed in the following way (for The Autonomic Control Plane is constructed in the following way (for
details, see Section 6): details, see Section 6):
1. An ACP node creates a Virtual Routing and Forwarding (VRF) 1. An ACP node creates a Virtual Routing and Forwarding (VRF)
instance, or a similar virtual context. instance, or a similar virtual context.
2. It determines, following a policy, a candidate peer list. This 2. It determines, following a policy, a candidate peer list. This
is the list of nodes to which it should establish an Autonomic is the list of nodes to which it should establish an Autonomic
Control Plane. Default policy is: To all link-layer adjacent Control Plane. Default policy is: To all link-layer adjacent
skipping to change at page 18, line 10 skipping to change at page 19, line 6
reachability of the virtual addresses inside the ACP (see reachability of the virtual addresses inside the ACP (see
Section 6.12.5). Section 6.12.5).
Note: Note:
o Non-autonomic NMS ("Network Management Systems") or SDN o Non-autonomic NMS ("Network Management Systems") or SDN
controllers have to be explicitly configured for connection into controllers have to be explicitly configured for connection into
the ACP. the ACP.
o Connecting over non-ACP Layer-3 clouds requires explicit o Connecting over non-ACP Layer-3 clouds requires explicit
configuration. See Section 8.2. This may be automated in the configuration. See Section 8.2.
future through auto discovery mechanisms across L3.
o None of the above operations (except explicit configured ones) are o None of the above operations (except explicit configured ones) are
reflected in the configuration of the node. reflected in the configuration of the node.
The following figure illustrates the ACP. The following figure illustrates the ACP.
ACP node 1 ACP node 2 ACP node 1 ACP node 2
................... ................... ................... ...................
secure . . secure . . secure secure . . secure . . secure
channel: +-----------+ : channel : +-----------+ : channel channel: +-----------+ : channel : +-----------+ : channel
skipping to change at page 18, line 37 skipping to change at page 19, line 32
: +-----------+ : : +-----------+ : : +-----------+ : : +-----------+ :
: : : : : : : :
: Data-Plane :...............: Data-Plane : : Data-Plane :...............: Data-Plane :
: : link : : : : link : :
:.................: :.................: :.................: :.................:
Figure 1: ACP VRF and secure channels Figure 1: ACP VRF and secure channels
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. This link local addressing, which does not require any prior set-up. In
way the ACP can be built even if there is no configuration on the this way the ACP can be built even if there is no configuration on
node, or if the Data-Plane has issues such as addressing or routing the node, or if the Data-Plane has issues such as addressing or
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
Autonomic Control Plane (ACP), and highlights the key properties Autonomic Control Plane (ACP), and highlights the key properties
which make it "indestructible" against many inadvertent changes to which make it "indestructible" against many inadvertent changes to
the Data-Plane, for example caused by misconfigurations. the Data-Plane, for example caused by 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
skipping to change at page 19, line 36 skipping to change at page 20, line 34
Appendix A.2 for more information about enrollment or provisioning Appendix A.2 for more information about enrollment or provisioning
options. options.
This document uses the term ACP in many places where the Autonomic This document uses the term ACP in many places where the Autonomic
Networking reference documents [RFC7575] and Networking reference documents [RFC7575] and
[I-D.ietf-anima-reference-model] use the word autonomic. This is [I-D.ietf-anima-reference-model] use the word autonomic. This is
done because those reference documents consider (only) fully done because those reference documents consider (only) fully
autonomic networks and nodes, but support of ACP does not require autonomic networks and nodes, but support of ACP does not require
support for other components of autonomic networks. Therefore the support for other components of autonomic networks. Therefore the
word autonomic might be misleading to operators interested in only word autonomic might be misleading to operators interested in only
the ACP: the ACP.
[RFC7575] defines the term "Autonomic Domain" as a collection of [RFC7575] defines the term "Autonomic Domain" as a collection of
autonomic nodes. ACP nodes do not need to be fully autonomic, but autonomic nodes. ACP nodes do not need to be fully autonomic, but
when they are, then the ACP domain is an autonomic domain. Likewise, when they are, then the ACP domain is an autonomic domain. Likewise,
[I-D.ietf-anima-reference-model] defines the term "Domain [I-D.ietf-anima-reference-model] defines the term "Domain
Certificate" as the certificate used in an autonomic domain. The ACP Certificate" as the certificate used in an autonomic domain. The ACP
domain certificate is that domain certificate when ACP nodes are domain certificate is that domain certificate when ACP nodes are
(fully) autonomic nodes. Finally, this document uses the term ACP (fully) autonomic nodes. Finally, this document uses the term ACP
network to refer to the network created by active ACP nodes in an ACP network to refer to the network created by active ACP nodes in an ACP
domain. The ACP network itself can extend beyond ACP nodes through domain. The ACP network itself can extend beyond ACP nodes through
the mechanisms described in Section 8.1). the mechanisms described in Section 8.1.
The ACP domain certificate can and should be used for any The ACP domain certificate SHOULD be used for any authentication
authentication between ACP nodes where the required security is between nodes with ACP domain certificates (ACP nodes and NOC nodes)
domain membership. Section 6.1.2 defines this "ACP domain membership where the required condition is ACP domain membership, such as ACP
check". The uses of this check that are standardized in this node to NOC/OAM end-to-en security and ASA to ASA end-to-end
document are for the establishment of ACP secure channels security. Section 6.1.2 defines this "ACP domain membership check".
(Section 6.6) and for ACP GRASP (Section 6.8.2). Other uses are The uses of this check that are standardized in this document are for
subject to future work, but it is recommended that it is the default the establishment of ACP secure channels (Section 6.6) and for ACP
security check for any end-to-end connections between ASA. It is GRASP (Section 6.8.2).
equally useable by other functions such as legacy OAM functions.
6.1.1. Certificate Domain Information Field 6.1.1. Certificate Domain Information Field
Information about the domain MUST be encoded in the domain Information about the domain MUST be encoded in the domain
certificate in a subjectAltName / rfc822Name field according to the certificate in a subjectAltName / rfc822Name field according to the
following ABNF definition ([RFC5234]): following ABNF definition ([RFC5234]):
[RFC Editor: Please substitute SELF in all occurences of rfcSELF in [RFC Editor: Please substitute SELF in all occurences 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 = 32hex-dig acp-address = 32hex-dig | 0
hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5 rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5
routing-subdomain = [ rsub " ." ] acp-domain-name routing-subdomain = [ rsub " ." ] acp-domain-name
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 definition. extension = ; future standard definition.
; Must fit RFC5322 simple dot-atom format. ; Must fit RFC5322 simple dot-atom format.
Example: Example:
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
"acp-address" MUST be the ACP address of the node. It is optional to Nodes complying with this specification MUST be able to receive their
support variations of the ACP mechanisms, for example other means for ACP address through the domain certificate, in which case their own
nodes to assign ACP addresses to themselves. Such methods are ACP domain certificate MUST have the 32hex-dig "acp-address" field.
subject to future work though. Nodes complying with this specification MUST also be able to
authenticate nodes as ACP domain members / ACP secure channel peers
Note: "acp-address" cannot use standard IPv6 address formats because when they have an empty or 0-value acp-address field. See
it must match the simple dot-atom format of [RFC5322]. ":" are not Section 6.1.2.
allowed in that format.
"acp-domain-name" is used to indicate the ACP Domain across which all "acp-domain-name" is used to indicate the ACP Domain across which all
ACP nodes trust each other and are willing to build ACP channel to ACP nodes trust each other and are willing to build ACP channels to
each other. See Section 6.1.2. Acp-domain-name SHOULD be the FQDN each other. See Section 6.1.2. Acp-domain-name SHOULD be the FQDN
of a DNS domain owned by the operator assigning the certificate. of a DNS domain owned by the operator assigning the certificate.
This is a simple method to ensure that the domain is globally unique This is a simple method to ensure that the domain is globally unique
and collision of ACP addresses would therefore only happen due to ULA and collision of ACP addresses would therefore only happen due to ULA
hash collisions. If the operator does not own any FQDN, it should hash collisions. If the operator does not own any FQDN, it should
choose a string (in FQDN format) that intends to be equally unique. choose a string (in FQDN format) that it intends to be equally
unique.
"routing-subdomain" is the autonomic subdomain that is used to "routing-subdomain" is the autonomic subdomain composed of "rsub" and
calculate the hash for the ULA Global ID of the ACP address of the "acp-domain-name". "rsub" is optional. When not present, "routing-
node. "rsub" is optional; its syntax is defined in this document, subdomain" is the same as "acp-domain-name". "routing-subdomain"
but its semantics are for further study. Understanding the benefits determines the /48 ULA prefix for ACP addresses. "rsub" therefore
of using rsub may depend on the results of future work on enhancing allows to use multiple /48 ULA prefixes in an ACP domain. See
routing for the ACP. When "rsub" is not used, "routing-subdomain" is Appendix A.7 for example use-cases.
the same as "acp-domain-name". "rsub" needs to be in the "local-
part": If the format just had routing-subdomain as the domain part of
the domain-information, rsub and acp-domain-name could not be
separated from each other. It also makes acp-domain-name a valid
e-mail target across all routing-subdomains.
The optional "extensions" field is used for future extensions to this The optional "extensions" field is used for future standardized
specification. It MUST be ignored if present and not understood. extensions to this specification. It MUST be ignored if present and
not understood.
In this specification, the "acp-address" field is REQUIRED, but Formatting notes:
future variations (see Appendix A.8) may use local information to
derive the ACP address. In this case, "acp-address" could be empty.
Such a variation would be indicated by an appropriate "extension".
If "acp-address" is empty, and "rsub" is empty too, the "local-part"
will have the format "rfcSELF + + extension(s)". The two plus
characters are necessary so the node can unambiguously parse that
both "acp-address" and "rsub" are empty.
Note that the maximum size of "domain-information" is 254 characters o "rsub" needs to be in the "local-part": If the format just had
and the maximum size of node-info is 64 characters according to routing-subdomain as the domain part of the domain-information,
[RFC5280] that is referring to [RFC2821] (superseded by [RFC5321]). rsub and acp-domain-name could not be separated from each other.
It also makes acp-domain-name a valid e-mail target across all
routing-subdomains.
o "acp-address" cannot use standard IPv6 address formats because it
must match the simple dot-atom format of [RFC5322]. The character
":" is not allowed in that format.
o If "acp-address" is empty, and "rsub" is empty too, the "local-
part" will have the format "rfcSELF + + extension(s)". The two
plus characters are necessary so the node can unambiguously parse
that both "acp-address" and "rsub" are empty.
o The maximum size of "domain-information" is 254 characters and the
maximum size of node-info is 64 characters according to [RFC5280]
that is referring to [RFC2821] (superseded by [RFC5321]).
The subjectAltName / rfc822Name encoding of the ACP domain name and The subjectAltName / rfc822Name encoding of the ACP domain name and
ACP address is used for the following reasons: ACP address is used for the following reasons:
o It should be possible to share the LDevID with other uses beside o It should be possible to share the LDevID with other uses beside
the ACP. Therefore, the information element required for the ACP the ACP. Therefore, the information element required for the ACP
should be encoded so that it minimizes the possibility of creating should be encoded so that it minimizes the possibility of creating
incompatibilities with such other uses. incompatibilities with such other uses.
o The information for the ACP should not cause incompatibilities o The information for the ACP should not cause incompatibilities
skipping to change at page 22, line 27 skipping to change at page 23, line 25
that would fail to work correctly. For example, the address could that would fail to work correctly. For example, the address could
be interpreted to be an address of the node which does not belong be interpreted to be an address of the node which does not belong
to the ACP VRF. to the ACP VRF.
o At minimum, both the AN domain name and the non-domain name o At minimum, both the AN domain name and the non-domain name
derived part of the ACP address need to be encoded in one or more derived part of the ACP address need to be encoded in one or more
appropriate fields of the certificate, so there are not many appropriate fields of the certificate, so there are not many
alternatives with pre-existing fields where the only possible alternatives with pre-existing fields where the only possible
conflicts would likely be beneficial. conflicts would likely be beneficial.
o rfc822Name encoding is quite flexible. We choose to encode the o rfc822Name encoding is quite flexible. The ACP information field
full ACP address AND the domain name with sub part into a single encodes the full ACP address AND the domain name with rsub part,
rfc822Name information element it, so that it is easier to so that it is easier to examine/use the "domain information
examine/use the "domain information field". field".
o The format of the rfc822Name is chosen so that an operator can set o The format of the rfc822Name is chosen so that an operator can set
up a mailbox called rfcSELF@<domain> that would receive emails up a mailbox called rfcSELF@<domain> that would receive emails
sent towards the rfc822Name of any node inside a domain. This is sent towards the rfc822Name of any node inside a domain. This is
possible because in many modern mail systems, components behind a possible because in many modern mail systems, components behind a
"+" character are considered part of a single mailbox. In other "+" character are considered part of a single mailbox. In other
words, it is not necessary to set up a separate mailbox for every words, it is not necessary to set up a separate mailbox for every
ACP node, but only one for the whole domain. ACP node, but only one for the whole domain.
o In result, if any unexpected use of the ACP addressing information o In result, if any unexpected use of the ACP addressing information
in a certificate happens, it is benign and detectable: it would be in a certificate happens, it is benign and detectable: it would be
mail to that mailbox. mail to that 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.2. ACP domain membership check 6.1.2. 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
possible peer certificate, independent of the protocol used: candidate peer certificate, independent of the protocol used:
o The peer certificate is valid (lifetime). 1: The peer certificate is valid (lifetime).
o The peer has proved ownership of the private key associated with 2: The peer has proved ownership of the private key associated with
the certifictes public key. the certifictes public key.
o The peer's certificate is signed by one of the trust anchors 3: The peer's certificate is signed by one of the trust anchors
associated with the ACP domain certificate. associated with the ACP domain certificate.
o If the node certificates 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 peers 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. must not be listed in the CRL retrieved from the CDP.
o The peers certificate has a syntactically valid domain information 5: The peer's certificate has a syntactically valid ACP domain
field (subjectAltName / rfc822Name) and the acp-domain-name in information field (encoded as subjectAltName / rfc822Name) and the
that peers domain information field is the same as in this ACP acp-domain-name in that peer's domain information field is the
node certificate. Note that future Intent rules may modify this. same as in this ACP node's certificate.
See Appendix A.7.
Only when checking a candidate peer's certificate for the purpose of
establishing an ACP secure channel, one additional check is
performed:
6: The candidate peer certificate's ACP domain information field
has a non-empty acp-address field (either 32hex-dig or 0,
according to Figure 2).
Rule 6: for the establishment of ACP secure channels ensures that
they will only be built between nodes which indicate through the acp-
address in their ACP domain certificate indicate ability and
permission by the Registrar to participate in ACP secure-channels.
Nodes without an empty acp-adress field can only use it for non-ACP-
secure channel authentication purposes. The special value 0 in an
ACP certificates acp-address field is used for nodes that can and
should determine their ACP address through other mechanisms than
learning it through their ACP domain certificate, but which are still
permitted to establish ACP secure channels. Mechanisms for those
nodes to determine their ACP address are outside the scope of this
specification.
6.1.3. Certificate Maintenance 6.1.3. Certificate Maintenance
ACP nodes MUST support certificate renewal via EST ("Enrollment over ACP nodes MUST support certificate renewal via EST ("Enrollment over
Secure Transport", see [RFC7030]) and MAY support other mechanisms. Secure Transport", see [RFC7030]) and MAY support other mechanisms.
An ACP network MUST have at least one ACP node supporting EST server An ACP network MUST have at least one ACP node supporting EST server
functionality across the ACP so that EST renewal is useable. functionality across the ACP so that EST renewal is useable.
ACP nodes SHOULD be able to remember the EST server from which they ACP nodes SHOULD be able to remember the EST server from which they
last renewed their ACP domain certificate and SHOULD provide the last renewed their ACP domain certificate and SHOULD provide the
skipping to change at page 24, line 27 skipping to change at page 25, line 44
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
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
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 255 ; recommended loop-count = 255 ; recommended
objective-value = ; Not used (yet) objective-value = any ; Not used (yet)
Figure 4: GRASP SRV.est definition Figure 4: GRASP SRV.est definition
The objective value "SRV.est" indicates that the objective is an The objective value "SRV.est" indicates that the objective is an
[RFC7030] compliant EST server because "est" is an [RFC6335] [RFC7030] compliant EST server because "est" is an [RFC6335]
registered service name for [RFC7030]. Future backward compatible registered service name for [RFC7030]. Objective-value MUST be
extensions/alternatives to [RFC7030] may be indicated through ignored if present. Backward compatible extensions to [RFC7030] MAY
objective-value. Future non-backward compatible certificate renewal be indicated through objective-value. Non [RFC7030] compatible
options must use a different objective-name. certificate renewal options MUST use a different objective-name.
The M_FLOOD message MUST be sent periodically. The default SHOULD be The M_FLOOD message MUST be sent periodically. The default SHOULD be
60 seconds, the value SHOULD be operator configurable but SHOULD be 60 seconds, the value SHOULD be operator configurable but SHOULD be
not smaller than 60 seconds. The frequency of sending MUST be such not smaller than 60 seconds. The frequency of sending MUST be such
that the aggregate amount of periodic M_FLOODs from all flooding that the aggregate amount of periodic M_FLOODs from all flooding
sources causes only negligible traffic across the ACP. The ttl sources causes only negligible traffic across the ACP. The time-to-
parameter SHOULD be 3.5 times the period so that up to three live (ttl) parameter SHOULD be 3.5 times the period so that up to
consecutive messages can be dropped before considering an three consecutive messages can be dropped before considering an
announcement expired. In the example above, the ttl is 210000 msec, announcement expired. In the example above, the ttl is 210000 msec,
3.5 times 60 seconds. When a service announcer using these 3.5 times 60 seconds. When a service announcer using these
parameters unexpectedly dies immediately after sending the M_FLOOD, parameters unexpectedly dies immediately after sending the M_FLOOD,
receivers would consider it expired 210 seconds later. When a receivers would consider it expired 210 seconds later. When a
receiver tries to connect to this dead service before this timeout, receiver tries to connect to this dead service before this timeout,
it will experience a failing connection and use that as an indication it will experience a failing connection and use that as an indication
that the service is dead and select another instance of the same that the service is dead and select another instance of the same
service instead. service instead.
6.1.3.2. Renewal 6.1.3.2. Renewal
skipping to change at page 26, line 49 skipping to change at page 28, line 17
Please refer to Section 6.10.7 for explanations about ACP registrars Please refer to Section 6.10.7 for explanations about ACP registrars
and vouchers as used in the following text. and vouchers as used in the following text.
When BRSKI is used (aka: on ACP nodes that are ANI nodes), the re- When BRSKI is used (aka: on ACP nodes that are ANI nodes), the re-
enrolling candidate ACP node would attempt to enroll like a candidate enrolling candidate ACP node would attempt to enroll like a candidate
ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID, ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID,
it SHOULD first attempt to use its ACP domain certificate in the it SHOULD first attempt to use its ACP domain certificate in the
BRSKI TLS authentication. The BRSKI registrar MAY honor this BRSKI TLS authentication. The BRSKI registrar MAY honor this
certificate beyond its expiration date purely for the purpose of re- certificate beyond its expiration date purely for the purpose of re-
enrollment. Using the ACP nodes domain certificate allows the BRSKI enrollment. Using the ACP node's domain certificate allows the BRSKI
registrar to learn that nodes ACP domain information field, so that registrar to learn that nodes ACP domain information field, so that
the BRSKI registrar can re-assign the same ACP address information to the BRSKI registrar can re-assign the same ACP address information to
the ACP node in the new ACP domain certificate. the ACP node in the new ACP domain certificate.
If the BRSKI registrar denies the use of the old ACP domain If the BRSKI registrar denies the use of the old ACP domain
certificate, the re-enrolling candidate ACP node MUST re-attempt re- certificate, the re-enrolling candidate ACP node MUST re-attempt re-
enrollment using its IDevID as defined in BRSKI during the TLS enrollment using its IDevID as defined in BRSKI during the TLS
connection setup. connection setup.
Both when the BRSKI connection is attempted with the old ACP domain Both when the BRSKI connection is attempted with the old ACP domain
skipping to change at page 28, line 50 skipping to change at page 30, line 19
The adjacency table MAY contain information about the validity and The adjacency table MAY contain information about the validity and
trust of the adjacent ACP node's certificate. However, subsequent trust of the adjacent ACP node's certificate. However, subsequent
steps MUST always start with authenticating the peer. steps MUST always start with authenticating the peer.
The adjacency table contains information about adjacent ACP nodes in The adjacency table contains information about adjacent ACP nodes in
general, independently of their domain and trust status. The next general, independently of their domain and trust status. The next
step determines to which of those ACP nodes an ACP connection should step determines to which of those ACP nodes an ACP connection should
be established. be established.
Interaction between ACP and other autonomic elements like GRASP (see
below) or ASAs should be via an API that allows (appropriately access
controlled) read/write access to the ACP Adjacency Table.
Specification of such an API is subject to future work.
6.3. Neighbor Discovery with DULL GRASP 6.3. Neighbor Discovery with DULL GRASP
[RFC Editor: GRASP draft is in RFC editor queue, waiting for [RFC Editor: GRASP draft is in RFC editor queue, waiting for
dependencies, including ACP. Please ensure that references to I- dependencies, including ACP. Please ensure that references to I-
D.ietf-anima-grasp that include section number references (throughout D.ietf-anima-grasp that include section number references (throughout
this document) will be updated in case any last-minute changes in this document) will be updated in case any last-minute changes in
GRASP would make those section references change. GRASP would make those section references change.
DULL GRASP is a limited subset of GRASP intended to operate across an DULL GRASP is a limited subset of GRASP intended to operate across an
insecure link-local scope. See section 2.5.2 of insecure link-local scope. See section 2.5.2 of
[I-D.ietf-anima-grasp] for its formal definition. The ACP uses one [I-D.ietf-anima-grasp] for its formal definition. The ACP uses one
instance of DULL GRASP for every L2 interface of the ACP node to instance of DULL GRASP for every L2 interface of the ACP node to
discover link level adjacent candidate ACP neighbors. Unless discover link level adjacent candidate ACP neighbors. Unless
modified by policy as noted earlier (Section 5 bullet point 2.), modified by policy as noted earlier (Section 5 bullet point 2.),
native interfaces (e.g., physical interfaces on physical nodes) native interfaces (e.g., physical interfaces on physical nodes)
SHOULD be initialized automatically to a state in which ACP discovery SHOULD be initialized automatically to a state in which ACP discovery
can be performed and any native interfaces with ACP neighbors can can be performed and any native interfaces with ACP neighbors can
then be brought into the ACP even if the interface is otherwise not then be brought into the ACP even if the interface is otherwise not
configured. Reception of packets on such otherwise not configured configured. Reception of packets on such otherwise not configured
interfaces MUST be limited so that at first only IPv6 State Less interfaces MUST be limited so that at first only IPv6 StateLess
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
skipping to change at page 30, line 41 skipping to change at page 32, line 15
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]
objective-flags = sync-only ; as in the GRASP specification objective-flags = sync-only ; as in the GRASP specification
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; limit to link-local operation loop-count = 1 ; limit to link-local operation
objective-value = method objective-value = method
method = "IKEv2" / "DTLS" ; or future methods method = "IKEv2" / "DTLS" ; or future standard methods
Figure 6: GRASP AN_ACP definition Figure 6: GRASP AN_ACP definition
The objective-flags field is set to indicate synchronization. The objective-flags field is set to indicate synchronization.
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
skipping to change at page 31, line 24 skipping to change at page 32, line 45
The 'objective-value' parameter is a string indicating the secure The 'objective-value' parameter is a string indicating the secure
channel protocol available at the specified or implied locator. channel protocol available at the specified or implied locator.
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 abbreviation for "Internet Key Exchange protocol
version 2", as defined in [RFC7296]. It is the main protocol used by version 2", as defined in [RFC7296]. It is the main protocol used by
the Internet IP security architecture ("IPsec", see [RFC4301]). We the Internet IP security architecture (IPsec). We therefore use the
therefore use the term "IKEv2" and not "IPsec" in the GRASP term "IKEv2" and not "IPsec" in the GRASP definitions and example
definitions and example above. "IKEv2" has a well-defined port above. "IKEv2" has a well-defined port number 500, but in the above
number 500, but in the above example, the candidate ACP neighbor is example, the candidate ACP neighbor is offering ACP secure channel
offering ACP secure channel negotiation via IKEv2 on port 15000 (for negotiation via IKEv2 on port 15000 (for the sake of creating a non-
the sake of creating a non-standard example). standard example).
"DTLS" indicates datagram Transport Layer Security version 1.2.
There is no default UDP port, it must always be locally assigned by
the node. See Section 6.7.2.
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 objective The secure channel methods defined in this document use the objective
values of "IKEv2" and "DTLS". There is no distinction between IKEv2 values of "IKEv2" and "DTLS". There is no distinction between IKEv2
native and GRE-IKEv2 because this is purely negotiated via IKEv2. native and GRE-IKEv2 because this is purely negotiated via IKEv2.
A node that supports more than one secure channel protocol method A node that supports more than one secure channel protocol method
skipping to change at page 32, line 14 skipping to change at page 33, line 40
standard port they are running on). It is stored in the ACP standard port they are running on). It is stored in the ACP
Adjacency Table, see Section 6.2 which then drives the further Adjacency Table, see Section 6.2 which then drives the further
building of the ACP to that neighbor. building of the ACP to that neighbor.
6.4. Candidate ACP Neighbor Selection 6.4. Candidate ACP Neighbor Selection
An ACP node must determine to which other ACP nodes in the adjacency An ACP node must determine to which other ACP nodes in the adjacency
table it should build an ACP connection. This is based on the table it should build an ACP connection. This is based on the
information in the ACP Adjacency table. information in the ACP Adjacency table.
The ACP is by default established exclusively between nodes in the The ACP is established exclusively between nodes in the same domain.
same domain. This includes all routing subdomains. Appendix A.7 This includes all routing subdomains. Appendix A.7 explains how ACP
explains how ACP connections across multiple routing subdomains are connections across multiple routing subdomains are special.
special.
Future extensions to this document including Intent can change this
default behavior. Examples include:
o Build the ACP across all domains that have a common parent domain.
For example ACP nodes with domain "example.com", nodes of
"example.com", "access.example.com", "core.example.com" and
"city.core.example.com" could all establish one single ACP.
o ACP connections across domains with different Certificate
Authorities (CA) could establish a common ACP by installing the
alternate domains' CA into the trusted anchor store. This is an
executive management action that could easily be accomplished
through the control channel created by the ACP.
Since Intent is transported over the ACP, the first ACP connection a
node establishes is always following the default behavior. See
Appendix A.7 for more details.
The result of the candidate ACP neighbor selection process is a list The result of the candidate ACP neighbor selection process is a list
of adjacent or configured autonomic neighbors to which an ACP channel of adjacent or configured autonomic neighbors to which an ACP channel
should be established. The next step begins that channel should be established. The next step begins that channel
establishment. establishment.
6.5. Channel Selection 6.5. Channel Selection
To avoid attacks, initial discovery of candidate ACP peers cannot To avoid attacks, initial discovery of candidate ACP peers cannot
include any non-protected negotiation. To avoid re-inventing and include any non-protected negotiation. To avoid re-inventing and
skipping to change at page 33, line 12 skipping to change at page 34, line 21
first to establish a security association with that neighbor using a first to establish a security association with that neighbor using a
well-known security association method. well-known security association method.
At this time in the lifecycle of ACP nodes, it is unclear whether it At this time in the lifecycle of ACP nodes, it is unclear whether it
is feasible to even decide on a single MTI (mandatory to implement) is feasible to even decide on a single MTI (mandatory to implement)
security association protocol across all ACP nodes. security association protocol across all ACP nodes.
From the use-cases it seems clear that not all type of ACP nodes can From the use-cases it seems clear that not all type of ACP nodes can
or need to connect directly to each other or are able to support or or need to connect directly to each other or are able to support or
prefer all possible mechanisms. For example, code space limited IoT prefer all possible mechanisms. For example, code space limited IoT
devices may only support DTLS ("datagram Transport Layer Security devices may only support DTLS because that code exists already on
version 1.2", see [RFC6347]) because that code exists already on them them for end-to-end security, but low-end in-ceiling L2 switches may
for end-to-end security, but low-end in-ceiling L2 switches may only only want to support Media Access Control Security (MacSec, see
want to support Media Access Control Security (MacSec, see 802.1AE 802.1AE ([MACSEC]) because that is also supported in their chips.
([MACSEC]) because that is also supported in their chips. Only a Only a flexible gateway device may need to support both of these
flexible gateway device may need to support both of these mechanisms mechanisms and potentially more.
and potentially more.
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 MTI protocol, ACP nodes must try all the ACP secure
channel protocols it supports and that are feasible because the channel protocols it supports and that are feasible because the
candidate ACP neighbor also announced them via its AN_ACP GRASP candidate ACP neighbor also announced them via its AN_ACP GRASP
parameters (these are called the "feasible" ACP secure channel parameters (these are called the "feasible" ACP secure channel
protocols). 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
skipping to change at page 37, line 23 skipping to change at page 38, line 26
The ACP does not use IP multicast routing nor does it provide generic The ACP does not use IP multicast routing nor does it provide generic
IP multicast services (the handling of GRASP link-local multicast IP multicast services (the handling of GRASP link-local multicast
messages is explained in Section 6.8.2). Instead, the ACP provides messages is explained in Section 6.8.2). Instead, the ACP provides
service discovery via the objective discovery/announcement and service discovery via the objective discovery/announcement and
negotiation mechanisms of the ACP GRASP instance (services are a form negotiation mechanisms of the ACP GRASP instance (services are a form
of objectives). These mechanisms use hop-by-hop reliable flooding of of objectives). These mechanisms use hop-by-hop reliable flooding of
GRASP messages for both service discovery (GRASP M_DISCOVERY GRASP messages for both service discovery (GRASP M_DISCOVERY
messages) and service announcement (GRASP M_FLOOD messages). messages) and service announcement (GRASP M_FLOOD messages).
See Appendix A.5 for more discussion about this design choice of the See Appendix A.5 for discussion about this design choice of the ACP.
ACP and considerations for possible future variations.
6.8.2. ACP as the Security and Transport substrate for GRASP 6.8.2. ACP as the Security and Transport substrate for GRASP
In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the
security and transport substrate for the GRASP instance run inside security and transport substrate for the GRASP instance run inside
the ACP ("ACP GRASP"). the ACP ("ACP GRASP").
This means that the ACP is responsible for ensuring that this This means that the ACP is responsible for ensuring that this
instance of GRASP is only sending messages across the ACP GRASP instance of GRASP is only sending messages across the ACP GRASP
virtual interfaces. Whenever the ACP adds or deletes such an virtual interfaces. Whenever the ACP adds or deletes such an
skipping to change at page 40, line 18 skipping to change at page 41, line 18
identity) about the other side which would allow them to distinguish identity) about the other side which would allow them to distinguish
a benevolent from a compromised peer. The compromised ACP node would a benevolent from a compromised peer. The compromised ACP node would
simply announce the objective as well, potentially filter the simply announce the objective as well, potentially filter the
original objective in GRASP when it is a MITM and act as an original objective in GRASP when it is a MITM and act as an
application level proxy. This of course requires that the application level proxy. This of course requires that the
compromised ACP node understand the semantics of the GRASP compromised ACP node understand the semantics of the GRASP
negotiation to an extent that allows it to proxy it without being negotiation to an extent that allows it to proxy it without being
detected, but in an ACP environment this is quite likely public detected, but in an ACP environment this is quite likely public
knowledge or even standardized. knowledge or even standardized.
The GRASP TLS connections are run like any other ACP traffic through The GRASP TLS connections are run the same as any other ACP traffic
the ACP secure channels. This leads to double authentication/ through the ACP secure channels. This leads to double
encryption. Future work optimizations could avoid this but it is authentication/encryption, which has the following benefits:
unclear how beneficial/feasible this is:
o The security considerations for GRASP change against attacks from o Secure channel methods such as IPsec may provide protecation
non-ACP (e.g., "outside") nodes: TLS is subject to reset attacks against additional attacks from such as reset-attacks.
while secure channel protocols may be not (e.g., IPsec is not).
o The secure channel method may leverage hardware acceleration and o The secure channel method may leverage hardware acceleration and
there may be little or no gain in eliminating it. there may be little or no gain in eliminating it.
o The GRASP TLS connections need to implement any additional o There is no different security model for ACP GRASP from other ACP
security options that are required for secure channels. For traffic. Instead, there is just another layer of protection
example the closing of connections when the peers certificate has against certain attacks from the inside which is important due to
expired. 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 so called Virtual routing
and forwarding instance (VRF) is one logical implementation option and forwarding instance (VRF) is one logical implementation option
for the ACP. If possible by the systems software architecture, for the ACP. If possible by the systems software architecture,
skipping to change at page 45, line 7 skipping to change at page 46, line 7
design of ASAs, which is outside the scope of this specification, design of ASAs, which is outside the scope of this specification,
they may use the V:0 or V:1 address. they may use the V:0 or V:1 address.
The location of the V bit(s) at the end of the address allows the The location of the V bit(s) at the end of the address allows the
announcement of a single prefix for each ACP node. For example, in a announcement of a single prefix for each ACP node. For example, in a
network with 20,000 ACP nodes, this avoid 20,000 additional routes in network with 20,000 ACP nodes, this avoid 20,000 additional routes in
the routing table. the routing table.
6.10.3.1. Usage of the Zone-ID Field 6.10.3.1. Usage of the Zone-ID Field
The Zone-ID allows for the introduction of structure in the The Zone-ID allows for the introduction of route prefixes in the
addressing scheme. addressing scheme.
Zone-ID = 0 is the default addressing scheme in an ACP domain. Every Zone-ID = 0 is the default addressing scheme in an ACP domain. Every
ACP node with a Zone Addressing Sub-Scheme address MUST respond to ACP node with a Zone Addressing Sub-Scheme address MUST respond to
its ACP address with Zone-ID = 0. Used on its own this leads to a its ACP address with Zone-ID = 0. Used on its own this leads to a
non-hierarchical address scheme, which is suitable for networks up to non-hierarchical address scheme, which is suitable for networks up to
a certain size. Zone-ID = 0 addresses act as identifiers for the a certain size. Zone-ID = 0 addresses act as identifiers for the
nodes, and aggregation of these address in the ACP routing table is nodes, and aggregation of these address in the ACP routing table is
not possible. not possible.
If aggregation is required, the 13 bit Zone-ID value allows for up to If aggregation is required, the 13 bit Zone-ID value allows for up to
8191 zones. The allocation of Zone-ID's may either happen 8191 zones. The allocation of Zone-ID's may either happen
automatically through a to-be-defined algorithm; or it could be automatically through a to-be-defined algorithm; or it could be
configured and maintained explicitly. configured and maintained explicitly.
If a node learns through a future autonomic method or through If a node learns (see Appendix A.10.1) that it is part of a zone, it
configuration that it is part of a zone, it MUST also respond to its MUST also respond to its ACP address with that Zone-ID. In this case
ACP address with that Zone-ID. In this case the ACP Loopback is the ACP Loopback is configured with two ACP addresses: One for Zone-
configured with two ACP addresses: One for Zone-ID = 0 and one for ID = 0 and one for the assigned Zone-ID. This method allows for a
the assigned Zone-ID. This method allows for a smooth transition smooth transition between a flat addressing scheme and a hierarchical
between a flat addressing scheme and an hierarchical one. one.
A node knowing it is in a zone MUST also use that Zone-ID != 0 A node knowing it is in a zone MUST also use that Zone-ID != 0
address in GRASP locator fields. This eliminates the use of the address in GRASP locator fields. This eliminates the use of the
identifier address (Zone-ID = 0) in forwarding and the need for identifier address (Zone-ID = 0) in forwarding and the need for
network wide reachability of those non-aggregatable identifier network wide reachability of those non-aggregatable identifier
addresses. Zone-ID != 0 addresses are assumed to be aggregatable in addresses. Zone-ID != 0 addresses are assumed to be aggregatable in
routing/forwarding based on how they are allocated in the ACP routing/forwarding based on how they are allocated in the ACP
topology (subject to future work). topology.
Note: Theoretically, the 13 bits for the Zone-ID would allow also for
two levels of zones, introducing a sub-hierarchy. We do not think
this is required at this point, but a new type could be used in the
future to support such a scheme.
Note: The Zone-ID is one method to introduce structure or hierarchy Note: The Zone-ID is one method to introduce structure or hierarchy
into the ACP. Another way is the use of the routing subdomain field into the ACP. Another way is the use of the routing subdomain field
in the ACP that leads to multiple /48 Global IDs within an ACP in the ACP that leads to multiple /48 Global IDs within an ACP
domain. This gives future work two options to consider. domain.
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
skipping to change at page 46, line 35 skipping to change at page 47, line 33
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
(unless some anycast setup is done). Future work may define (unless some anycast setup is done).
mechanisms for auto-coordination between ACP nodes and auto-
allocation of Subnet-IDs between them.
The Z bit field was added to distinguish Zone addressing and manual The Z bit field was added to distinguish Zone addressing and manual
addressing sub-schemes without requiring one more bit in the base addressing sub-schemes without requiring one more bit in the base
scheme and therefore allowing for the Vlong scheme (described below) scheme and therefore allowing for the Vlong scheme (described below)
to have one more bit available. to have one more bit available.
Manual addressing sub-scheme addresses SHOULD only be used in domain Manual addressing sub-scheme addresses SHOULD NOT be used in ACP
certificates assigned to nodes that cannot fully participate in the domain certificates. Any node capable to build ACP secure channels
automatic establishment of ACP secure channels or ACP routing. The and permitted by Registrar policy to participate in building ACP
intended use are nodes connecting to the ACP via an ACP edge node and secure channels SHOULD receive an ACP address (prefix) from one of
ACP connect interfaces (see Section 8.1) - such as legacy NOC the other ACP addressing sub-schemes. Nodes not capable (or
equipment. They would not use their domain certificate for ACP permitted) to participate in ACP secure channels can connect to the
secure channel creation and therefore do not need to participate in ACP via ACP connect interfaces of ACP edge nodes (see xref
ACP routing either. They would use the certificate for target="ACPconnect"/>), without setting up an ACP secure channel.
authentication of any transport services. The value of the Interface Their ACP domain certificate MUST include an empty acp-address to
Identifier is left for future definitions. indicate that their ACP domain certificate is only usable for non-
ACP secure channel authentication, such as end-to-end transport
connections across the ACP or Data-Plane.
Address management of ACP connect subnets is done using traditional
assignment methods and existing IPv6 protocols. See Section 8.1.3
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 The sub-scheme defined here is defined by the Type value 01b (one) in
the base scheme. the base scheme.
50 78 50 78
+---------------------++-----------------------------+----------+ +---------------------++-----------------------------+----------+
| (base scheme) || Node-ID | | (base scheme) || Node-ID |
| || Registrar-ID | Node-Number| V | | || Registrar-ID | Node-Number| V |
skipping to change at page 49, line 49 skipping to change at page 51, line 5
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.1) with the appropriate gets a domain information field (Section 6.1.1) 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 information field to the registrar uses BRSKI, it signals the ACP information field to the
Pledge via the EST /csraddrs command (see Pledge via the EST /csraddrs command (see
[I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR
Attributes"). Attributes").
[RFC editor: please update reference to section 5.8.2 accordingly [RFC Editor: please update reference to section 5.8.2 accordingly
with latest BRSKI draft at time of publishing, or RFC] with latest BRSKI draft at time of publishing, or RFC]
6.10.7.3. Addressing Sub-Scheme Policies 6.10.7.3. Addressing Sub-Scheme Policies
The ACP registrar selects for the candidate ACP node a unique address The ACP registrar selects for the candidate ACP node a unique address
prefix from an appropriate ACP addressing sub-scheme, either a zone prefix from an appropriate ACP addressing sub-scheme, either a zone
addressing sub-scheme prefix (see Section 6.10.3), or a Vlong addressing sub-scheme prefix (see Section 6.10.3), or a Vlong
addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP addressing sub-scheme prefix (see Section 6.10.5). The assigned ACP
address prefix encoded in the domain information field of the ACP address prefix encoded in the domain information field of the ACP
domain certificate indicates to the ACP node its ACP address domain certificate indicates to the ACP node its ACP address
information. The sub-addressing scheme indicates the prefix length: information. The sub-addressing scheme indicates the prefix length:
/126 for zone address sub-scheme, /120 or /112 for Vlong address sub- /127 for zone address sub-scheme, /120 or /112 for Vlong address sub-
scheme. The first address of the prefix is the ACP address, all scheme. The first address of the prefix is the ACP address, all
other addresses in the prefix are for other uses by the ACP node as other addresses in the prefix are for other uses by the ACP node as
described in the zone and Vlong addressing sub scheme sections. The described in the zone and Vlong addressing sub scheme sections. The
ACP address prefix itself is then signaled by the ACP node into the ACP address prefix itself is then signaled by the ACP node into the
ACP routing protocol (see Section 6.11) to establish IPv6 ACP routing protocol (see Section 6.11) to establish IPv6
reachability across the ACP. reachability across the ACP.
The choice of addressing sub-scheme and prefix-length in the Vlong The choice of addressing sub-scheme and prefix-length in the Vlong
address sub-scheme is subject to ACP registrar policy. It could be address sub-scheme is subject to ACP registrar policy. It could be
an ACP domain wide policy, or a per ACP node or per ACP node type an ACP domain wide policy, or a per ACP node or per ACP node type
skipping to change at page 52, line 14 skipping to change at page 53, line 14
6.11.1. RPL Profile 6.11.1. RPL Profile
The following is a description of the RPL profile that ACP nodes need The following is a description of the RPL profile that ACP nodes need
to support by default. The format of this section is derived from to support by default. The format of this section is derived from
draft-ietf-roll-applicability-template. draft-ietf-roll-applicability-template.
6.11.1.1. Summary 6.11.1.1. Summary
In summary, the profile chosen for RPL is one that expects a fairly In summary, the profile chosen for RPL is one that expects a fairly
reliable network reasonably fast links so that RPL convergence will reliable network with reasonably fast links so that RPL convergence
be triggered immediately upon recognition of link failure/recovery. will be triggered immediately upon recognition of link failure/
recovery.
The key limitation of the chosen profile is that it is designed to The key limitation of the chosen profile is that it is designed to
not require any Data-Plane artifacts (such as [RFC6553]). While the not require any Data-Plane artifacts (such as [RFC6553]). While the
senders/receivers of ACP packets can be legacy NOC devices connected senders/receivers of ACP packets can be legacy NOC devices connected
via ACP connect (see Section 8.1.1 to the ACP, their connectivity can via ACP connect (see Section 8.1.1 to the ACP, their connectivity can
be handled as non-RPL-aware leafs (or "Internet") according to the be handled as non-RPL-aware leafs (or "Internet") according to the
Data-Plane architecture explained in [I-D.ietf-roll-useofrplinfo]. Data-Plane architecture explained in [I-D.ietf-roll-useofrplinfo].
This non-artifact profile is largely driven by the desire to avoid This non-artifact profile is largely driven by the desire to avoid
introducing the required Hop-by-Hop headers into the ACP forwarding introducing the required Hop-by-Hop headers into the ACP forwarding
plane, especially to support devices with silicon forwarding planes plane, especially to support devices with silicon forwarding planes
skipping to change at page 52, line 40 skipping to change at page 53, line 41
consequence of supporting only a single instanceID that is containing consequence of supporting only a single instanceID that is containing
one Destination Oriented Directed Acyclic Graph (DODAG), the ACP will one Destination Oriented Directed Acyclic Graph (DODAG), the ACP will
only accommodate only a single class of routing table and cannot only accommodate only a single class of routing table and cannot
create optimized routing paths to accomplish latency or energy goals. create optimized routing paths to accomplish latency or energy goals.
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. Other NOCs will have to Only one NOC will become the DODAG root. Other NOCs will have to
send traffic through the DODAG (tree) rooted in the primary NOC. send traffic through the DODAG (tree) rooted in the primary NOC.
Depending on topology, this can be an annoyance from a latency point Depending on topology, this can be an annoyance from a latency point
of view, but it does not represent a single point of failure, as the of view, but it does not represent a single point of failure, as the
DODAG can reconfigure itself when it detects data plane forwarding DODAG will reconfigure itself when it detects data plane forwarding
failures. failures. See Appendix A.10.4 for more details.
The lack of RPL Packet Information (RPI, the IPv6 header for RPL The lack of RPL Packet Information (RPI, the IPv6 header for RPL
defined by [RFC6553]), means that the Data-Plane will have no rank defined by [RFC6553]), means that the Data-Plane will have no rank
value that can be used to detect loops. As a result, traffic may value that can be used to detect loops. As a result, traffic may
loop until the TTL of the packet reaches zero. This the same loop until the time-to-live (TTL) of the packet reaches zero. This
behavior as that of other IGPs that do not have the Data-Plane the same behavior as that of other IGPs that do not have the Data-
options as RPL. Plane options as 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 should be exceedingly rare according to Section 6.11.1.7, loops should be exceedingly rare
though. though.
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 53, line 22 skipping to change at page 54, line 22
local connectivity. Nodes SHOULD select more than one parent, at local connectivity. Nodes SHOULD select more than one parent, at
least 3 if possible, and send Destination Advertisement Objects least 3 if possible, and send Destination Advertisement Objects
(DAO)s to all of then in parallel. (DAO)s to all of then in parallel.
Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer
Detection (which can function as a replacement for a Low-power and Detection (which can function as a replacement for a Low-power and
Lossy Networks' (LLN's) Expected Transmission Count (ETX). A failure Lossy Networks' (LLN's) Expected Transmission Count (ETX). A failure
of an ACP tunnel should signal the RPL control plane to pick a of an ACP tunnel should signal the RPL control plane to pick a
different parent. different parent.
Future Extensions to this RPL profile can provide optimality for
multiple NOCs. This requires utilizing Data-Plane artifact including
IPinIP encap/decap on ACP routers and processing of IPv6 RPI headers.
Alternatively, (Src,Dst) routing table entries could be used. A
decision for the preferred technology would have to be done when such
extension is defined.
6.11.1.2. RPL Instances 6.11.1.2. RPL Instances
Single RPL instance. Default RPLInstanceID = 0. Single RPL instance. Default RPLInstanceID = 0.
6.11.1.3. Storing vs. Non-Storing Mode 6.11.1.3. Storing vs. Non-Storing Mode
RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of RPL Mode of Operations (MOP): MUST support mode 2 - "Storing Mode of
Operations with no multicast support". Implementations MAY support Operations with no multicast support". Implementations MAY support
mode 3 ("... with multicast support" as that is a superset of mode mode 3 ("... with multicast support" as that is a superset of mode
2). Note: Root indicates mode in DIO flow. 2). Note: Root indicates mode in DIO flow.
skipping to change at page 55, line 46 skipping to change at page 56, line 38
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.
6.12. General ACP Considerations 6.12. General ACP Considerations
Since channels are by default established between adjacent neighbors, Since channels are by default established between adjacent neighbors,
the resulting overlay network does hop by hop encryption. Each node the resulting overlay network does hop-by-hop encryption. Each node
decrypts incoming traffic from the ACP, and encrypts outgoing traffic decrypts incoming traffic from the ACP, and encrypts outgoing traffic
to its neighbors in the ACP. Routing is discussed in Section 6.11. to its neighbors in the ACP. Routing is discussed in Section 6.11.
6.12.1. Performance 6.12.1. Performance
There are no performance requirements against ACP implementations There are no performance requirements against ACP implementations
defined in this document because the performance requirements depend defined in this document because the performance requirements depend
on the intended use case. It is expected that full autonomic node on the intended use case. It is expected that full autonomic node
with a wide range of ASA can require high forwarding plane with a wide range of ASA can require high forwarding plane
performance in the ACP, for example for telemetry, but that performance in the ACP, for example for telemetry. Implementations
determination is for future work. Implementations of ACP to solely of ACP to solely support traditional/SDN style use cases can benefit
support traditional/SDN style use cases can benefit from ACP at lower from ACP at lower performance, especially if the ACP is used only for
performance, especially if the ACP is used only for critical critical operations, e.g., when the Data-Plane is not available. The
operations, e.g., when the Data-Plane is not available. See design of the ACP as specified in this document is intended to
[RFC8368] for more details. support a wide range of performance options: It is intended to allow
software-only implementations at potentially low performance, but can
also support high performance options. See [RFC8368] for more
details.
6.12.2. Addressing of Secure Channels in the Data-Plane 6.12.2. Addressing of Secure Channels
In order to be independent of the Data-Plane configuration of global In order to be independent of the Data-Plane (routing and addressing)
IPv6 subnet addresses (that may not exist when the ACP is brought the GRASP discovered (autonomic) ACP secure channels use IPv6 link
up), Link-local secure channels MUST use IPv6 link local addresses local addresses between adjacent neighbors. Note: Section 8.2
between adjacent neighbors. The fully autonomic mechanisms in this specifies extensions in which secure channels are configured tunnels
document only specify these link-local secure channels. Section 8.2 operating over the Data-Plane, so those secure channels can not be
specifies extensions in which secure channels are tunnels. For independent of the Data-Plane.
those, this requirement does not apply.
The Link-local secure channels specified in this document therefore To avoid that Data-Plane configuration can impact the operations of
depend on basic IPv6 link-local functionality to be auto-enabled by the IPv6 (link-local) interface/address used for ACP channels,
the ACP and prohibiting the Data-Plane from disabling it. The ACP appropriate implementation considerations are required. If the IPv6
also depends on being able to operate the secure channel protocol interface/link-local address is shared with the Data-Plane it needs
(e.g., IPsec / DTLS) across IPv6 link-local addresses, something that to be impossible to unconfigure/disable it through configuration.
may be an uncommon profile. Functionally, these are the only Instead of sharing the IPv6 interface/link-local address, a separate
interactions with the Data-Plane that the ACP needs to have. (virtual) interface with a separate IPv6 link-local addresss can be
used. For example, the ACP interface could be run over a separate
MAC addres of an underlying L2 (Ethernet) interface. For more
details and options, see Appendix A.10.2.
To mitigate these interactions with the Data-Plane, extensions to Note that other (non-ideal) implementation choices may introduce
this document may specify additional layer 2 or layer encapsulations additional undesired dependencies against the Data-Plane. For
for ACP secure channels as well as other protocols to auto-discover example shared code and configuration of the secure channel protocols
peer endpoints for such encapsulations (e.g., tunneling across L3 or (IPsec / DTLS).
use of L2 only encapsulations).
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
skipping to change at page 58, line 5 skipping to change at page 58, line 47
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).
ACP secure channels, e.g., IPsec, DTLS or other future security Any type of ACP secure channels to another ACP node can be mapped to
associations with neighboring ACP nodes can be mapped to ACP virtual ACP virtual interfaces in tollowing ways. This is independent of the
interfaces in different ways: choosen secure channel protocol (IPsec, DTLS or other future protocol
- standards or non-standards):
ACP point-to-point virtual interface: ACP point-to-point virtual interface:
Each ACP secure channel is mapped into a separate point-to-point ACP Each ACP secure channel is mapped into a separate point-to-point ACP
virtual interface. If a physical subnet has more than two ACP virtual interface. If a physical subnet has more than two ACP
capable nodes (in the same domain), this implementation approach will capable nodes (in the same domain), this implementation approach will
lead to a full mesh of ACP virtual interfaces between them. lead to a full mesh of ACP virtual interfaces between them.
ACP multi-access virtual interface: ACP multi-access virtual interface:
skipping to change at page 60, line 18 skipping to change at page 61, line 13
for more details. for more details.
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. These requirements can be avoided by coupling the ACP interface. See also Appendix A.10.4.
flooding mechanism for GRASP messages directly to RPL (flood GRASP
across DODAG), but such an enhancement is subject for future work.
Care must also be taken when creating multi-access ACP virtual Care must also 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. The policies to be negotiated may be domains or routing subdomains. The policies to be negotiated may be
described as peer-to-peer policies in which case it is easier to described as peer-to-peer policies in which case it is easier to
create ACP point-to-point virtual interfaces for these secure create ACP point-to-point virtual interfaces for these secure
channels. channels.
7. ACP support on L2 switches/ports (Normative) 7. ACP support on L2 switches/ports (Normative)
skipping to change at page 61, line 5 skipping to change at page 61, line 44
topology of L2 switches. Examples include large enterprise campus topology of L2 switches. Examples include large enterprise campus
networks with an L2 core, IoT networks or broadband aggregation networks with an L2 core, IoT networks or broadband aggregation
networks which often have even a multi-level L2 switched topology. networks which often have even a multi-level L2 switched topology.
If the discovery protocol used for the ACP is operating at the subnet If the discovery protocol used for the ACP is operating at the subnet
level, every ACP router will see all other ACP routers on the LAN as level, every ACP router will see all other ACP routers on the LAN as
neighbors and a full mesh of ACP channels will be built. If some or neighbors and a full mesh of ACP channels will be built. If some or
all of the AN switches are autonomic with the same discovery all of the AN switches are autonomic with the same discovery
protocol, then the full mesh would include those switches as well. protocol, then the full mesh would include those switches as well.
A full mesh of ACP connections like this can creates fundamental A full mesh of ACP connections can create fundamental scale
scale challenges. The number of security associations of the secure challenges. The number of security associations of the secure
channel protocols will likely not scale arbitrarily, especially when channel protocols will likely not scale arbitrarily, especially when
they leverage platform accelerated encryption/decryption. Likewise, they leverage platform accelerated encryption/decryption. Likewise,
any other ACP operations (such as routing) needs to scale to the any other ACP operations (such as routing) needs to scale to the
number of direct ACP neighbors. An ACP router with just 4 physical number of direct ACP neighbors. An ACP router with just 4 physical
interfaces might be deployed into a LAN with hundreds of neighbors interfaces might be deployed into a LAN with hundreds of neighbors
connected via switches. Introducing such a new unpredictable scaling connected via switches. Introducing such a new unpredictable scaling
factor requirement makes it harder to support the ACP on arbitrary factor requirement makes it harder to support the ACP on arbitrary
platforms and in arbitrary deployments. platforms and in arbitrary deployments.
Predictable scaling requirements for ACP neighbors can most easily be Predictable scaling requirements for ACP neighbors can most easily be
achieved if in topologies like these, ACP capable L2 switches can achieved if in topologies such as these, ACP capable L2 switches can
ensure that discovery messages terminate on them so that neighboring ensure that discovery messages terminate on them so that neighboring
ACP routers and switches will only find the physically connected ACP ACP routers and switches will only find the physically connected ACP
L2 switches as their candidate ACP neighbors. With such a discovery L2 switches as their candidate ACP neighbors. With such a discovery
mechanism in place, the ACP and its security associations will only mechanism in place, the ACP and its security associations will only
need to scale to the number of physical interfaces instead of a need to scale to the number of physical interfaces instead of a
potentially much larger number of "LAN-connected" neighbors. And the potentially much larger number of "LAN-connected" neighbors. And the
ACP topology will follow directly the physical topology, something ACP topology will follow directly the physical topology, something
which can then also be leveraged in management operations or by ASAs. which can then also be leveraged in management operations or by ASAs.
In the example above, consider ANswitch1 and ANswitchM are ACP In the example above, consider ANswitch1 and ANswitchM are ACP
skipping to change at page 63, line 7 skipping to change at page 63, line 48
enabled to prohibit DoS attacks. Likewise the GRASP DULL instance enabled to prohibit DoS attacks. Likewise the GRASP DULL instance
needs to ensure that the IPv6 address in the locator-option matches needs to ensure that the IPv6 address in the locator-option matches
the source IPv6 address of the DULL GRASP packet. 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, but the need to support secure channel protocols simple as possible.
may be a limiting factor to supporting ACP on such devices. Future
options such as MacSec could improve that situation.
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. Ideally, the ACP should be built with the Spanning Tree Protocol. Ideally, the ACP should be built
also across ports that are blocked in STP so that the ACP does not also across ports that are blocked in STP so that the ACP does not
depend on STP and can continue to run unaffected across STP topology depend on STP and can continue to run unaffected across STP topology
changes (where re-convergence can be quite slow). The above changes (where re-convergence can be quite slow). The above
described simple implementation options are not sufficient for this. described simple implementation options are not sufficient for this.
Instead they would simply have the ACP run across the active STP Instead they would simply have the ACP run across the active STP
topology and the ACP would equally be interrupted and re-converge topology and the ACP would equally be interrupted and re-converge
with STP changes. with STP changes.
skipping to change at page 63, line 34 skipping to change at page 64, line 25
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 must 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, just like 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 must support "ACP connect" (sometimes also called
"autonomic connect"): "autonomic connect"):
"ACP connect" is a function on an autonomic node that is called an "ACP connect" is a function on an autonomic node that is called an
"ACP edge node". With "ACP connect", interfaces on the node can be "ACP edge node". With "ACP connect", interfaces on the node can be
configured to be put into the ACP VRF. The ACP is then accessible to configured to be put into the ACP VRF. The ACP is then accessible to
skipping to change at page 64, line 21 skipping to change at page 65, line 21
| | ^ |. | | NOC Device || | | ^ |. | | NOC Device ||
| | . | .[Data-Plane]..+-----------------| "NMS hosts" || | | . | .[Data-Plane]..+-----------------| "NMS hosts" ||
| | . | [ ] | . ^ | || | | . | [ ] | . ^ | ||
+--------+ . +----------------+ . . +-------------+| +--------+ . +----------------+ . . +-------------+|
. . . +-------------+ . . . +-------------+
. . . . . .
Data-Plane "native" . ACP "native" (unencrypted) Data-Plane "native" . ACP "native" (unencrypted)
+ 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 13: ACP connect Figure 13: 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 must 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
skipping to change at page 65, line 25 skipping to change at page 66, line 25
interface. interface.
ACP Edge Nodes MUST only forward IPv6 packets received from an ACP ACP Edge Nodes MUST only forward IPv6 packets received from an ACP
connect interface into the ACP that has an IPv6 address from the ACP connect interface into the ACP that has an IPv6 address from the ACP
prefix assigned to this interface (sometimes called "RPF filtering"). prefix assigned to this interface (sometimes called "RPF filtering").
This MAY be changed through administrative measures. This MAY be changed 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 (such as those physically secure locations like a deployed with it (those in physically secure locations such as a
NOC). For example, the certificate of such node could include an NOC). For example, the registrar could disable the ability to enable
extension required to permit configuration of ACP connect interfaces. ACP connect on devices during enrollment and that property could only
This prohibits that a random ACP node with easy physical access that be changed through re-enrollment. See also Appendix A.10.5.
is not meant to run ACP connect could start leaking the ACP when it
becomes compromised and the intruder configures ACP connect on it.
The full workflow including the mechanism by which an ACP registrar
would select which node to give such a certificate to is subject to
future work.
8.1.2. Software Components 8.1.2. Software Components
The ACP connect mechanism be only be used to connect physically The ACP connect mechanism be 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
skipping to change at page 66, line 21 skipping to change at page 67, line 17
correct security model: It is not necessary to rely on unprovable correct security model: It is not necessary to rely on unprovable
external physical security mechanisms as in the case of external NMS external physical security mechanisms as in the case of external NMS
hosts. Instead, the orchestration of the ACP, the virtual subnets hosts. Instead, the orchestration of the ACP, the virtual subnets
and the software components can be done by trusted software that and the software components can be done by trusted software that
could be considered to be part of the ANI (or even an extended ACP). could be considered to be part of the ANI (or even an extended ACP).
This software component is responsible for ensuring that only trusted This software component is responsible for ensuring that only trusted
software components will get access to that virtual subnet and that software components will get access to that virtual subnet and that
only even more trusted software components will get access to both only even more trusted software components will get access to both
the ACP virtual subnet and the Data-Plane (because those ACP users the ACP virtual subnet and the Data-Plane (because those ACP users
could leak traffic between ACP and Data-Plane). This trust could be could leak traffic between ACP and Data-Plane). This trust could be
established for example through cryptographic means such signed established for example through cryptographic means such as signed
software packages. The specification of these mechanisms is subject software packages.
to future work.
Note that ASA (Autonomic Software Agents) could also be software
components as described in this section, but further details of ASAs
are subject to future work.
8.1.3. Auto Configuration 8.1.3. Auto Configuration
ACP edge nodes, NMS hosts and software components that as described ACP edge nodes, NMS hosts and software components that as described
in the previous section are meant to be composed via virtual in the previous section are meant to be composed via virtual
interfaces SHOULD support on the ACP connect subnet StateLess Address interfaces SHOULD support on the ACP connect subnet StateLess Address
Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration Autoconfiguration (SLAAC - [RFC4862]) and route auto configuration
according to [RFC4191]. according to [RFC4191].
The ACP edge node acts as the router on the ACP connect subnet, The ACP edge node acts as the router on the ACP connect subnet,
skipping to change at page 69, line 9 skipping to change at page 69, line 48
GRASP can and should be possible to use across ACP connect GRASP can and should be possible to use across ACP connect
interfaces, especially in the architectural correct solution when it interfaces, especially in the architectural correct solution when it
is used as a mechanism to connect Software (e.g., ASA or legacy NMS is used as a mechanism to connect Software (e.g., ASA or legacy NMS
applications) to the ACP. Given how the ACP is the security and applications) to the ACP. Given how the ACP is the security and
transport substrate for GRASP, the trustworthiness of nodes/software transport substrate for GRASP, the trustworthiness of nodes/software
allowed to participate in the ACP GRASP domain is one of the main allowed to participate in the ACP GRASP domain is one of the main
reasons why the ACP section describes no solution with non-ACP reasons why the ACP section describes no solution with non-ACP
routers participating in the ACP routing table. routers participating in the ACP routing table.
ACP connect interfaces can be dealt with in the GRASP ACP domain like ACP connect interfaces can be dealt with in the GRASP ACP domain the
any other ACP interface assuming that any physical ACP connect same as any other ACP interface assuming that any physical ACP
interface is physically protected from attacks and that the connected connect interface is physically protected from attacks and that the
Software or NMS Hosts are equally trusted as that on other ACP nodes. connected Software or NMS Hosts are equally trusted as that on other
ACP edge nodes SHOULD have options to filter GRASP messages in and ACP nodes. ACP edge nodes SHOULD have options to filter GRASP
out of ACP connect interfaces (permit/deny) and MAY have more fine- messages in and out of ACP connect interfaces (permit/deny) and MAY
grained filtering (e.g., based on IPv6 address of originator or have more fine-grained filtering (e.g., based on IPv6 address of
objective). originator or objective).
When using "Combined ACP and Data-Plane Interfaces", care must be When using "Combined ACP and Data-Plane Interfaces", care must 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 must all use the ACP
skipping to change at page 69, line 45 skipping to change at page 70, line 35
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
On the ACP node, remote ACP neighbors are configured explicitly. The On the ACP node, remote ACP neighbors are configured explicitly. The
parameters of such a "connection" are described in the following parameters of such a "connection" are described in the following
ABNF. Future work could transform this into a YANG ([RFC7950]) data ABNF.
model.
connection = [ method , local-addr, remote-addr, ?pmtu ] connection = [ method , local-addr, remote-addr, ?pmtu ]
method = [ "IKEv2" , ?port ] method = [ "IKEv2" , ?port ]
method //= [ "DTLS", port ] method //= [ "DTLS", port ]
local-addr = [ address , ?vrf ] local-addr = [ address , ?vrf ]
remote-addr = [ address ] remote-addr = [ address ]
address = ("any" | ipv4-address | ipv6-address ) address = ("any" | ipv4-address | ipv6-address )
vrf = tstr ; Name of a VRF on this node with local-address vrf = tstr ; Name of a VRF on this node with local-address
ABNF for parameters of explicitly configured remote ACP neighbors Figure 15: Parameters for remote ACP neighbors
Explicit configuration of a remote-peer according to this ABNF Explicit configuration of a remote-peer according to this ABNF
provides all the information to build a secure channel without provides all the information to build a secure channel without
requiring a tunnel to that peer and running DULL GRASP inside of it. requiring a tunnel to that peer and running DULL GRASP inside of it.
The configuration includes the parameters otherwise signaled via DULL The configuration includes the parameters otherwise signaled via DULL
GRASP: local address, remote (peer) locator and method. The GRASP: local address, remote (peer) locator and method. The
differences over DULL GRASP local neighbor discovery and secure differences over DULL GRASP local neighbor discovery and secure
channel creation are as follows: channel creation are as follows:
o The local and remote address can be IPv4 or IPv6 and are typically o The local and remote address can be IPv4 or IPv6 and are typically
global scope addresses. global scope addresses.
o The vrf across which the connection is built (and in which local- o The VRF across which the connection is built (and in which local-
addr exists) can to be specified. If vrf is not specified, it is addr exists) can to be specified. If vrf is not specified, it is
the default vrf on the node. In DULL GRASP the VRF is implied by the default VRF on the node. In DULL GRASP the VRF is implied by
the interface across which DULL GRASP operates. the interface across which DULL GRASP operates.
o If local address is "any", the local address used when initiating o If local address is "any", the local address used when initiating
a secure channel connection is decided by source address selection a secure channel connection is decided by source address selection
([RFC6724] for IPv6). As a responder, the connection listens on ([RFC6724] for IPv6). As a responder, the connection listens on
all addresses of the node in the selected vrf. all addresses of the node in the selected VRF.
o Configuration of port is only required for methods where no o Configuration of port is only required for methods where no
defaults exist (e.g., "DTLS"). defaults exist (e.g., "DTLS").
o If remote address is "any", the connection is only a responder. o If remote address is "any", the connection is only a responder.
It is a "hub" that can be used by multiple remote peers to connect It is a "hub" that can be used by multiple remote peers to connect
simultaneously - without having to know or configure their simultaneously - without having to know or configure their
addresses. Example: Hub site for remote "spoke" sites reachable addresses. Example: Hub site for remote "spoke" sites reachable
over the Internet. over the Internet.
skipping to change at page 71, line 38 skipping to change at page 72, line 22
than L2 adjacent ACP neighbors based on link local addressing, since than L2 adjacent ACP neighbors based on link local addressing, since
they depend on more correct Data-Plane operations, such as routing they depend on more correct Data-Plane operations, such as routing
and global addressing. and global addressing.
Nevertheless, these options may be crucial to incrementally deploy Nevertheless, these options may be crucial to incrementally deploy
the ACP, especially if it is meant to connect islands across the the ACP, especially if it is meant to connect islands across the
Internet. Implementations SHOULD support at least Tunneled Remote Internet. Implementations SHOULD support at least Tunneled Remote
ACP Neighbors via GRE tunnels - which is likely the most common ACP Neighbors via GRE tunnels - which is likely the most common
router-to-router tunneling protocol in use today. router-to-router tunneling protocol in use today.
Future work could envisage an option where the edge nodes of the L3
cloud is configured to automatically forward ACP discovery messages
to the right exit point. This optimization is not considered in this
document.
9. Benefits (Informative) 9. Benefits (Informative)
9.1. Self-Healing Properties 9.1. Self-Healing Properties
The ACP is self-healing: The ACP is self-healing:
o New neighbors will automatically join the ACP after successful o New neighbors will automatically join the ACP after successful
validation and will become reachable using their unique ULA validation and will become reachable using their unique ULA
address across the ACP. address across the ACP.
skipping to change at page 73, line 24 skipping to change at page 73, line 52
down action (with default RPL routing used, packet forwarding will be down action (with default RPL routing used, packet forwarding will be
symmetric, so this is actually possible to check). symmetric, so this is actually possible to check).
9.2. Self-Protection Properties 9.2. Self-Protection Properties
9.2.1. From the outside 9.2.1. From the outside
As explained in Section 6, the ACP is based on secure channels built As explained in Section 6, the ACP is based on secure channels built
between nodes that have mutually authenticated each other with their between nodes that have mutually authenticated each other with their
domain certificates. The channels themselves are protected using domain certificates. The channels themselves are protected using
standard encryption technologies like DTLS or IPsec which provide standard encryption technologies such as DTLS or IPsec which provide
additional authentication during channel establishment, data additional authentication during channel establishment, data
integrity and data confidentiality protection of data inside the ACP integrity and data confidentiality protection of data inside the ACP
and in addition, provide replay protection. and in addition, provide replay protection.
An attacker will not be able to join the ACP unless having a valid 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
skipping to change at page 74, line 34 skipping to change at page 75, line 14
security in mind than with legacy software based systems where the security in mind than with legacy software based systems where the
ACP is added on as another feature. ACP is added on as another feature.
As explained above, traffic across the ACP SHOULD still be end-to-end As explained above, traffic across the ACP SHOULD still be end-to-end
encrypted whenever possible. This includes traffic such as GRASP, encrypted whenever possible. This includes traffic such as GRASP,
EST and BRSKI inside the ACP. This minimizes man in the middle EST and BRSKI inside the ACP. This minimizes man in the middle
attacks by compromised ACP group members. Such attackers cannot attacks by compromised ACP group members. Such attackers cannot
eavesdrop or modify communications, they can just filter them (which eavesdrop or modify communications, they can just filter them (which
is unavoidable by any means). is unavoidable by any means).
Further security can be achieved by constraining communication
patterns inside the ACP, for example through roles that could be
encoded into the domain certificates. This is subject for future
work.
9.3. The Administrator View 9.3. The Administrator View
An ACP is self-forming, self-managing and self-protecting, therefore An ACP is self-forming, self-managing and self-protecting, therefore
has minimal dependencies on the administrator of the network. has minimal dependencies on the administrator of the network.
Specifically, since it is independent of configuration, there is no Specifically, since it is independent of configuration, there is no
scope for configuration errors on the ACP itself. The administrator scope for configuration errors on the ACP itself. The administrator
may have the option to enable or disable the entire approach, but may have the option to enable or disable the entire approach, but
detailed configuration is not possible. This means that the ACP must detailed configuration is not possible. This means that the ACP must
not be reflected in the running configuration of nodes, except a not be reflected in the running configuration of nodes, except a
possible on/off switch. possible on/off switch.
skipping to change at page 75, line 23 skipping to change at page 75, line 46
without a valid domain certificate cannot connect to it. This means without a valid domain certificate cannot connect to it. This means
that by default a traditional controller or network management system that by default a traditional controller or network management system
cannot connect to an ACP. See Section 8.1.1 for more details on how cannot connect to an ACP. See Section 8.1.1 for more details on how
to connect an NMS host into the ACP. to connect an NMS host into the ACP.
10. ACP Operations (Informative) 10. ACP Operations (Informative)
The following sections document important operational aspects of the The following sections document important operational aspects of the
ACP. They are not normative because they do not impact the ACP. They are not normative because they do not impact the
interoperability between components of the ACP, but they include interoperability between components of the ACP, but they include
recommendations/requirements for possible followup standards work recommendations/requirements for the internal operational model
such as operational YANG model definitions: beneficial or necessary to achieve the desired use-case benefits of
the ACP (see Section 3).
o Section 10.1 describes recommended operator diagnostics o Section 10.1 describes recommended operator diagnostics
capabilities of ACP nodes. The have been derived from diagnostic capabilities of ACP nodes. The have been derived from diagnostic
of a commercially available ACP implementation. of a commercially available ACP implementation.
o Section 10.2 describes high level how an ACP registrar needs to o Section 10.2 describes high level how an ACP registrar needs to
work, what its configuration parameters are and specific issues work, what its configuration parameters are and specific issues
impacting the choices of deployment design due to renewal and impacting the choices of deployment design due to renewal and
revocation issues. It describes a model where ACP Registrars have revocation issues. It describes a model where ACP Registrars have
their own sub-CA to provide the most disributed deployment option their own sub-CA to provide the most disributed deployment option
skipping to change at page 76, line 29 skipping to change at page 77, line 7
neighboring node?" neighboring node?"
In current network management approaches, the logic to answer these In current network management approaches, the logic to answer these
questions is most often built as centralized diagnostics software questions is most often built as centralized diagnostics software
that leverages the above mentioned data models. While this approach that leverages the above mentioned data models. While this approach
is feasible for components utilizing the ANI, it is not sufficient to is feasible for components utilizing the ANI, it is not sufficient to
diagnose the ANI itself: diagnose the ANI itself:
o Developing the logic to identify common issues requires o Developing the logic to identify common issues requires
operational experience with the components of the ANI. Letting operational experience with the components of the ANI. Letting
each management system define its own analysis is inefficient. As each management system define its own analysis is inefficient.
much as possible, future work should attempt to standardize data
models that support common error diagnostic.
o When the ANI is not operating correctly, it may not be possible to o When the ANI is not operating correctly, it may not be possible to
run diagnostics from remote because of missing connectivity. The run diagnostics from remote because of missing connectivity. The
ANI should therefore have diagnostic capabilities available ANI should therefore have diagnostic capabilities available
locally on the nodes themselves. locally on the nodes themselves.
o Certain operations are difficult or impossible to monitor in real- o Certain operations are difficult or impossible to monitor in real-
time, such as initial bootstrap issues in a network location where time, such as initial bootstrap issues in a network location where
no capabilities exist to attach local diagnostics. Therefore it no capabilities exist to attach local diagnostics. Therefore it
is important to also define means of capturing (logging) is important to also define means of capturing (logging)
diagnostics locally for later retrieval. Ideally, these captures diagnostics locally for later retrieval. Ideally, these captures
are also non-volatile so that they can survive extended power-off are also non-volatile so that they can survive extended power-off
conditions - for example when a device that fails to be brought up conditions - for example when a device that fails to be brought up
zero-touch is being sent back for diagnostics at a more zero-touch is being sent back for diagnostics at a more
appropriate location. appropriate location.
The most simple form of diagnostics answering questions like the The most simple form of diagnostics answering questions such as the
above is to represent the relevant information sequentially in above is to represent the relevant information sequentially in
dependency order, so that the first non-expected/non-operational item dependency order, so that the first non-expected/non-operational item
is the most likely root cause. Or just log/highlight that item. For is the most likely root cause. Or just log/highlight that item. For
example: example:
Q: Is ACP operational to accept neighbor connections: Q: Is ACP operational to accept neighbor connections:
o Check if any potentially necessary configuration to make ACP/ANI o Check if any potentially necessary configuration to make ACP/ANI
operational are correct (see Section 10.3 for a discussion of such operational are correct (see Section 10.3 for a discussion of such
commands). commands).
skipping to change at page 80, line 17 skipping to change at page 80, line 47
insecure to make this information available unprotected to all insecure to make this information available unprotected 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".
Desirable options for additional diagnostics subject to future work
include:
1. Determine if LLDP should be a recommended functionality for ANI
devices to improve diagnostics, and if so, which information
elements it should signal (insecure).
2. In alternative to LLDP, A DULL GRASP diagnostics objective could
be defined to carry these information elements.
3. The IDevID of BRSKI pledges should be included in the selected
insecure diagnostics option.
4. A richer set of diagnostics information should be made available
via the secured ACP channels, using either single-hop GRASP or
network wide "topology discovery" mechanisms.
10.2. ACP Registrars 10.2. ACP Registrars
As described in Section 6.10.7, the ACP addressing mechanism is As described in Section 6.10.7, the ACP addressing mechanism is
designed to enable lightweight, distributed and uncoordinated ACP designed to enable lightweight, distributed and uncoordinated ACP
registrars that are providing ACP address prefixes to candidate ACP registrars that are providing ACP address prefixes to candidate ACP
nodes by enrolling them with an ACP domain certificate into an ACP nodes by enrolling them with an ACP domain certificate into an ACP
domain via any appropriate mechanism/protocol, automated or not. domain via any appropriate mechanism/protocol, automated or not.
This section discusses informatively more details and options for ACP This section discusses informatively more details and options for ACP
registrars. registrars.
skipping to change at page 81, line 18 skipping to change at page 81, line 31
registrar can rely on the ACP and use Proxies to reach the candidate registrar can rely on the ACP and use Proxies to reach the candidate
ACP node, therefore allowing minimum pre-existing (auto-)configured ACP node, therefore allowing minimum pre-existing (auto-)configured
network services on the candidate ACP node. BRSKI defines the BRSKI network services on the candidate ACP node. BRSKI defines the BRSKI
proxy, a design that can be adopted for various protocols that proxy, a design that can be adopted for various protocols that
Pledges/candidate ACP nodes could want to use, for example BRSKI over Pledges/candidate ACP nodes could want to use, for example BRSKI over
CoAP (Constrained Application Protocol), or proxying of Netconf. CoAP (Constrained Application Protocol), or proxying of Netconf.
To reach a trust anchor unaware of the ACP, the ACP registrar would To reach a trust anchor unaware of the ACP, the ACP registrar would
use the Data-Plane. ACP and Data-Plane in an ACP registrar could use the Data-Plane. ACP and Data-Plane in an ACP registrar could
(and by default should be) completely isolated from each other at the (and by default should be) completely isolated from each other at the
network level. Only applications like the ACP registrar would need network level. Only applications such as the ACP registrar would
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 ([I-D.ietf-netconf-zerotouch]) is an
example protocol that could be used for this. BRSKI using optional example protocol that could be used for this. BRSKI using optional
discovery mechanisms is equally a possibility for candidate ACP nodes discovery 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, like BRSKI Pledges, When candidate ACP nodes have secure bootstrap, such as BRSKI
they will not trust to be configured/enrolled across the network, Pledges, they will not trust to be configured/enrolled across the
unless being presented with a voucher (see [RFC8366]) authorizing the network, unless being presented with a voucher (see [RFC8366])
network to take possession of the node. An ACP registrar will then authorizing the network to take possession of the node. An ACP
need a method to retrieve such a voucher, either offline, or online registrar will then need a method to retrieve such a voucher, either
from a MASA (Manufacturer Authorized Signing Authority). BRSKI and offline, or online from a MASA (Manufacturer Authorized Signing
Netconf ZeroTouch are two protocols that include capabilities to Authority). BRSKI and Netconf ZeroTouch are two protocols that
present the voucher to the candidate ACP node. include capabilities to present the voucher to the candidate ACP
node.
An ACP registrar could operate EST for ACP certificate renewal and/or An ACP registrar could operate EST for ACP certificate renewal and/or
act as a CRL Distribution point. A node performing these services act as a CRL Distribution point. A node performing these services
does not need to support performing (initial) enrollment, but it does does not need to support performing (initial) enrollment, but it does
require the same above described connectivity as an ACP registrar: require the same above described connectivity as an ACP registrar:
via the ACP to ACP nodes and via the Data-Plane to the trust anchor via the ACP to ACP nodes and via the Data-Plane to the trust anchor
and other sources of CRL information. and other sources of CRL information.
10.2.2. Registrar Parameter 10.2.2. Registrar Parameter
skipping to change at page 84, line 34 skipping to change at page 84, line 49
specific address prefix to assign to a candidate ACP node. specific address prefix to assign to a candidate ACP node.
These and other operations could be introduced more easily by These and other operations could be introduced more easily by
introducing a centralized Policy Management System (PMS) and introducing a centralized Policy Management System (PMS) and
modifying ACP registrar behavior so that it queries the PMS for any modifying ACP registrar behavior so that it queries the PMS for any
policy decision occuring during the candidate ACP node enrollment policy decision occuring during the candidate ACP node enrollment
process and/or the ACP node certificate renewal process. For process and/or the ACP node certificate renewal process. For
example, which ACP address prefix to assign. Likewise the ACP example, which ACP address prefix to assign. Likewise the ACP
registrar would report any relevant state change information to the registrar would report any relevant state change information to the
PMS as well, for example when a certificate was successfully enrolled PMS as well, for example when a certificate was successfully enrolled
onto a candidate ACP node. Such an ACP registrar PMS interface onto a candidate ACP node.
definition is subject to future work.
10.3. Enabling and disabling ACP/ANI 10.3. Enabling and disabling ACP/ANI
Both ACP and BRSKI require interfaces to be operational enough to Both ACP and BRSKI require interfaces to be operational enough to
support sending/receiving their packets. In node types where support sending/receiving their packets. In node types where
interfaces are by default (e.g., without operator configuration) interfaces are by default (e.g., without operator configuration)
enabled, such as most L2 switches, this would be less of a change in enabled, such as most L2 switches, this would be less of a change in
behavior than in most L3 devices (e.g.: routers), where interfaces behavior than in most L3 devices (e.g.: routers), where interfaces
are by default disabled. In almost all network devices it is common are by default disabled. In almost all network devices it is common
though for configuration to change interfaces to a physically though for configuration to change interfaces to a physically
skipping to change at page 92, line 33 skipping to change at page 92, line 42
Disabling "ACP/ANI enable" global and per-interface should have Disabling "ACP/ANI enable" global and per-interface should have
additional checks to minimize undesired breakage of ACP. The degree additional checks to minimize undesired breakage of ACP. The degree
of control could be a domain wide parameter in the domain of control could be a domain wide parameter in the domain
certificates. certificates.
11. Security Considerations 11. Security Considerations
An ACP is self-protecting and there is no need to apply configuration An ACP is self-protecting and there is no need to apply configuration
to make it secure. Its security therefore does not depend on to make it secure. Its security therefore does not depend on
configuration. configuration. See Section 9.2 for details of how the ACP protects
itself against attacks from the outside and to a more limited degree
from the inside as well.
However, the security of the ACP depends on a number of other However, the security of the ACP depends on a number of other
factors: factors:
o The usage of domain certificates depends on a valid supporting PKI o The usage of domain certificates depends on a valid supporting PKI
infrastructure. If the chain of trust of this PKI infrastructure infrastructure. If the chain of trust of this PKI infrastructure
is compromised, the security of the ACP is also compromised. This is compromised, the security of the ACP is also compromised. This
is typically under the control of the network administrator. is typically under the control of the network administrator.
o Security can be compromised by implementation errors (bugs), as in o Security can be compromised by implementation errors (bugs), as in
skipping to change at page 93, line 12 skipping to change at page 93, line 25
Fundamentally, security depends on correct operation, implementation Fundamentally, security depends on correct operation, implementation
and architecture. Autonomic approaches such as the ACP largely and architecture. Autonomic approaches such as the ACP largely
eliminate the dependency on correct operation; implementation and eliminate the dependency on correct operation; implementation and
architectural mistakes are still possible, as in all networking architectural mistakes are still possible, as in all networking
technologies. technologies.
Many details of ACP are designed with security in mind and discussed Many details of ACP are designed with security in mind and discussed
elsewhere in the document: elsewhere in the document:
IPv6 addresses used by nodes in the ACP are covered as part of the IPv6 addresses used by nodes in the ACP are covered as part of the
nodes domain certificate as described in Section 6.1.1. This allows node's domain certificate as described in Section 6.1.1. This allows
even verification of ownership of a peers IPv6 address when using a even verification of ownership of a peers IPv6 address when using a
connection authenticated with the domain certificate. connection authenticated with the domain certificate.
The ACP acts as a security (and transport) substrate for GRASP inside The ACP acts as a security (and transport) substrate for GRASP inside
the ACP such that GRASP is not only protected by attacks from the the ACP such that GRASP is not only protected by attacks from the
outside, but also by attacks from compromised inside attackers - by outside, but also by attacks from compromised inside attackers - by
relying not only on hop-by-hop security of ACP secure channels, but relying not only on hop-by-hop security of ACP secure channels, but
adding end-to-end security for those GRASP messages. See adding end-to-end security for those GRASP messages. See
Section 6.8.2. Section 6.8.2.
ACP provides for secure, resilient zero-touch discovery of EST ACP provides for secure, resilient zero-touch discovery of EST
servers for certificate renewal. See Section 6.1.3. servers for certificate renewal. See Section 6.1.3.
ACP provides extensible, auto-configuring hop-by-hop protection of ACP provides extensible, auto-configuring hop-by-hop protection of
the ACP infrastructure via the negotiation of hop-by-hop secure the ACP infrastructure via the negotiation of hop-by-hop secure
channel protocols. See Section 6.5 and Appendix A.6. channel protocols. See Section 6.5 and Appendix A.6.
The ACP is designed to minimize attacks from the outside by The ACP is designed to minimize attacks from the outside by
minimizing its dependency against any non-ACP operations on a node. minimizing its dependency against any non-ACP (Data-Plane)
The only dependency in the specification in this document is the need operations/configuration on a node. See also Section 6.12.2.
to share link-local addresses for the ACP secure channel
encapsulation with the Data-Plane. See Section 6.12.2.
In combination with BRSKI, ACP enables a resilient, fully zero-touch In combination with BRSKI, ACP enables a resilient, fully zero-touch
network solution for short-lived certificates that can be renewed or network solution for short-lived certificates that can be renewed or
re-enrolled even after unintentional expiry (e.g., because of re-enrolled even after unintentional expiry (e.g., because of
interrupted connectivity). See Appendix A.2. interrupted connectivity). See Appendix A.2.
12. IANA Considerations 12. IANA Considerations
This document defines the "Autonomic Control Plane". This document defines the "Autonomic Control Plane".
skipping to change at page 114, line 37 skipping to change at page 114, line 46
Fixed up domain information field ABNF to eliminate confusion that Fixed up domain information field ABNF to eliminate confusion that
rsub is not an FQDN but only a prefix to routing-subdomain. rsub is not an FQDN but only a prefix to routing-subdomain.
Corrected certcheck to separate out cert verification into lifetime Corrected certcheck to separate out cert verification into lifetime
validity and proof of ownership of private key. validity and proof of ownership of private key.
Fixed pagination for "ACP as security and transport substrate for Fixed pagination for "ACP as security and transport substrate for
GRASP" picture. GRASP" picture.
14.23. wish-list 14.23. draft-ietf-anima-autonomic-control-plane-17
From -13 review from Pascal Thubert: Picture to show dual-NOC routing Review Alissa Cooper:
limitation.
[RFC Editor: Question: Is it possible to change the first occurences Main discuss point fixed by untangling two specific node type cases:
of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC
format does not seem to offer such a format, but i did not want to NOC nodes have ACP domain cert without acp-address field. Are ACP
duplicate 50 first references to be duplicate - one reference for domain members, but can not build ACP secure channels (just end-to-
title mentioning and one for RFC number.] end or nay other authentications.
ACP nodes may have other methods to assign ACP address than getting
it through the cert. This is indicated through new vlue 0 for acp-
address in certificate.
Accordingly modified texts in ABNF/explanation and Cert-Check
section.
Other:
Better separation of normative text and considerations for "future"
work:
- Marked missing chapters as Informative. Reworded requirements
section to indicate its informative nature, changed reqirements to
_MUST_/_SHOULD_ to indicate these are not RFC2119 requirements but
that this requirements section is really just in place of a separate
solutions requirements document (that ANIMA was not allowed to
produce).
- removed ca. 20 instances of "futures" in normative part of
document.
- moved important instances of "futures" into new section A.10 (last
section of appendix). These serve as reminder os work discussed
dduring WG but not able to finish specifying it.
Eliminated perception that "rsub" (routing subdomain) is only
beneficial with future work. Example in A.7.
Added RFC-editor note re formatting of references to terms defined in
terminology section.
Using now correct RFC 8174 boilerplate.
Clarified semantic and use of manual ACP sub-scheme. Not used in
certificates, only assigned via traditional methods. Use for ACP-
connect subnets or the like.
Corrected text about Data-Plane dependencies of ACP. Appropriate
implementations can be fully data-plane independent (without more
spec work) if not sharing link-local address with Data-Plane. 6.12.2
text updated to discuss those (MAC address), A.10.2 discusses options
that would require new standards work.
Moved all text about Intent into A.8 to clearl mark it as futures.
Changed suggestion of future insecure ACP option to future "end-to-
end-security-only" option.
Various textual fixes.
Gen-ART review by Elwyn Davies:
Some fixes also mentioned by Alissa.
Added reference for OT.
Fixed notion that secure channel is not only a security association.
>20 good textual fixes. Thanks!
Other:
Added picture requested by Pascal Thubert about Dual-NOC (A.10.4).
Moved RFC-editor request for better first RFC reference closer to the
top of the document.
Fixed typo /126 -> 127 for prefix length with zone address scheme.
Overlooked early SecDir review from frank.xialiang@huawei.com:
most issues fixed through other review in -16. Added reference to
self-protection section 9.2 into security considerations section.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
skipping to change at page 115, line 14 skipping to change at page 116, line 48
15.1. Normative References 15.1. Normative References
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR data structures", draft-ietf-cbor-cddl-02 express CBOR data structures", draft-ietf-cbor-cddl-03
(work in progress), February 2018. (work in progress), July 2018.
[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>.
skipping to change at page 117, line 30 skipping to change at page 119, line 20
[AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and [AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-15 (work in progress), April 2018. keyinfra-16 (work in progress), June 2018.
[I-D.ietf-anima-prefix-management] [I-D.ietf-anima-prefix-management]
Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic
IPv6 Edge Prefix Management in Large-scale Networks", IPv6 Edge Prefix Management in Large-scale Networks",
draft-ietf-anima-prefix-management-07 (work in progress), draft-ietf-anima-prefix-management-07 (work in progress),
December 2017. December 2017.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
skipping to change at page 118, line 10 skipping to change at page 120, line 5
[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, "When to use Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-23 (work in progress), May 2018. useofrplinfo-23 (work in progress), May 2018.
[IEEE-802.1X]
IEEE SA-Standards Board, "IEEE Standard for Local and
Metropolitan Area Networks: Port-Based Network Access
Control", February 2010,
<http://standards.ieee.org/findstds/
standard/802.1X-2010.html>.
[LLDP] IEEE SA-Standards Board, "IEEE Standard for Local and [LLDP] IEEE SA-Standards Board, "IEEE Standard for Local and
Metropolitan Area Networks: Station and Media Access Metropolitan Area Networks: Station and Media Access
Control Connectivity Discovery", June 2016, Control Connectivity Discovery", June 2016,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/802.1AB-2016.html>. standard/802.1AB-2016.html>.
[MACSEC] IEEE SA-Standards Board, "IEEE Standard for Local and [MACSEC] IEEE SA-Standards Board, "IEEE Standard for Local and
Metropolitan Area Networks: Media Access Control (MAC) Metropolitan Area Networks: Media Access Control (MAC)
Security", June 2006, Security", June 2006,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
skipping to change at page 121, line 41 skipping to change at page 123, line 41
"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>.
15.3. URIs
[1] https://en.wikipedia.org/wiki/Operational_Technology
[2] https://en.wikipedia.org/wiki/Single-root_input/
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
about aspects of the normative parts of this document or associated about aspects of the normative parts of this document or associated
mechanisms such as BRSKI (such as why specific choices where made by mechanisms such as BRSKI (such as why specific choices where made by
the ACP) and they provide discussion about possble future variations the ACP) and they provide discussion about possble future variations
of the ACP. of the ACP.
A.1. ACP Address Space Schemes A.1. ACP Address Space Schemes
skipping to change at page 129, line 32 skipping to change at page 131, line 38
domain information field of the domain certificate. We summarize domain information field of the domain certificate. We summarize
these options here as they have been explained in different parts of these options here as they have been explained in different parts of
the document in before and discuss possible and desirable extensions: the document in before and discuss possible and desirable extensions:
An ACP domain is the set of all ACP nodes using certificates from the An ACP domain is the set of all ACP nodes using certificates from the
same CA using the same domain field. GRASP inside the ACP is run same CA using the same domain field. GRASP inside the ACP is run
across all transitively connected ACP nodes in a domain. across all transitively connected ACP nodes in a domain.
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 networks that initially may be separated, but where it multiple physical networks that initially may be separated with one
should be possible to connect them without further extensions to ACP ACP domain but different routing subdomains, so that all nodes can
when necessary. mutual trust their ACP domain certificates (not depending on rsub)
and so that they could connect later together into a contiguous ACP
network.
Another use case for routing subdomains is as the starting point for One instance of such a use case is an ACP for regions interconnected
structuring routing inside an ACP. For example, different routing via a non-ACP enabled core, for example due to the absence of product
subdomains could run different routing protocols or different support for ACP on the core nodes. ACP connect configurations as
instances of RPL and auto-aggregation / distribution of routes could defined in this document can be used to extend and interconnect those
be done across inter routing subdomain ACP channels based on ACP islands to the NOC and merge them into a single ACP when later
negotiation (e.g., via GRASP). This is subject for further work. that product support gap is closed.
RPL scales very well. It is not necessary to use multiple routing Note that RPL scales very well. It is not necessary to use multiple
subdomains to scale ACP domains in a way it would be possible if routing subdomains to scale ACP domains in a way it would be possible
other routing protocols where used. They exist only as options for if other routing protocols where used. They exist only as options
the above mentioned reasons. for the above mentioned reasons.
If different ACP domains are to be created that should not allow to If different ACP domains are to be created that should not allow to
connect to each other by default, these ACP domains simply need to connect to each other by default, these ACP domains simply need to
have different domain elements in the domain information field. have different domain elements in the domain information field.
These domain elements can be arbitrary, including subdomains of one These domain elements can be arbitrary, including subdomains of one
another: Domains "example.com" and "research.example.com" are another: Domains "example.com" and "research.example.com" are
separate domains if both are domain elements in the domain separate domains if both are domain elements in the domain
information element of certificates. information element of certificates.
It is not necessary to have a separate CA for different ACP domains: It is not necessary to have a separate CA for different ACP domains:
skipping to change at page 130, line 21 skipping to change at page 132, line 32
If multiple independent networks choose the same domain name but had If multiple independent networks choose the same domain name but had
their own CA, these would not form a single ACP domain because of CA their own CA, these would not form a single ACP domain because of CA
mismatch. Therefore there is no problem in choosing domain names mismatch. Therefore there is no problem in choosing domain names
that are potentially also used by others. Nevertheless it is highly that are potentially also used by others. Nevertheless it is highly
recommended to use domain names that one can have high probability to recommended to use domain names that one can have high probability to
be unique. It is recommended to use domain names that start with a be unique. It is recommended to use domain names that start with a
DNS domain names owned by the assigning organization and unique DNS domain names owned by the assigning organization and unique
within it. For example "acp.example.com" if you own "example.com". within it. For example "acp.example.com" if you own "example.com".
Future extensions, primarily through intent can create more flexible A.8. Intent for the ACP
options how to build ACP domains.
Intent could modify the ACP connection check to permit connections Intent is the architecture component of autonomic networks according
between different domains. to [I-D.ietf-anima-reference-model] that allows operators to issue
policies to the network. In a simple instance, Intent could simply
be policies flooded across ACP GRASP and interpreted on every ACP
node.
If different domains use the same CA one would change the ACP setup One concern for future definitions of Intent solutions is the problem
to permit for the ACP to be established between the two ACP nodes, of circular dependencies when expressing Intent policies about the
but no routing nor ACP GRASP to be built across this adjacency. The ACP itself.
main difference over routing subdomains is to not permit for the ACP
GRASP instance to be built across the adjacency. Instead, one would
only build a point to point GRASP instance between those peers to
negotiate what type of exchanges are desired across that connection.
This would include routing negotiation, how much GRASP information to
transit and what Data-Plane forwarding should be done. This approach
could also allow for Intent to only be injected into the network from
one side and propagate via this GRASP connection.
If different domains have different CAs, they should start to trust For example, Intent could indicate the desire to build an ACP across
each other by intent injected into both domains that would add the all domains that have a common parent domain (without relying on the
other domains CA as a trust point during the ACP connection setup - rsub/routing-subdomain solution defined in this document). For
and then following up with the previous point of inter-domain example ACP nodes with domain "example.com", nodes of "example.com",
connections across domains with the same CA (e.g., GRASP "access.example.com", "core.example.com" and "city.core.example.com"
negotiation). should all establish one single ACP.
A.8. Adopting ACP concepts for other environments 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
domain names to the ACP domain membership check (Section 6.1.2) so
that nodes from those other nodes are accepted as ACP peers.
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
any ACP connection amongst each other, whether they use the same or
different CA due to the ACP domain membership check.
If the domains use the same CA one could change the ACP setup to
permit for the ACP to be established between the two ACP nodes even
when the acp-domain-names of the peers are different, but only for
the purpose of disseminating limited information, such as Intent, but
not to set up full ACP connectivity, specifically not RPL routing and
passing of arbitrary GRASP information. Unless the Intent policies
permit this to happen across domain boundaries.
This type of approach where the ACP first allows Intent to operate
and only then sets up the rest of ACP connectivity based on Intent
policy could also be used to enable Intent policies that would limit
functionality across the ACP inside a domain, as long as no policy
would disturb the operations of Intent. For example to limit
reachability across the ACP to certain type of nodes or locations of
nodes.
A.9. Adopting ACP concepts for other environments
The ACP as specified in this document is very explicit about the The ACP as specified in this document is very explicit about the
choice of options to allow interoperable implementations. The choice of options to allow interoperable implementations. The
choices made may not be the best for all environments, but the choices made may not be the best for all environments, but the
concepts used by the ACP can be used to build derived solutions: concepts used by the ACP can be used to build derived solutions:
The ACP specifies the use of ULA and deriving its prefix from the The ACP specifies the use of ULA and deriving its prefix from the
domain name so that no address allocation is required to deploy the domain name so that no address allocation is required to deploy the
ACP. The ACP will equally work not using ULA but any other /50 IPv6 ACP. The ACP will equally work not using ULA but any other /48 IPv6
prefix. This prefix could simply be a configuration of the ACP prefix. This prefix could simply be a configuration of the ACP
registrars (for example when using BRSKI) to enroll the domain registrars (for example when using BRSKI) to enroll the domain
certificates - instead of the ACP registrar deriving the /50 ULA certificates - instead of the ACP registrar deriving the /48 ULA
prefix from the AN domain name. prefix from the AN domain name.
Some solutions may already have an auto-addressing scheme, for Some solutions may already have an auto-addressing scheme, for
example derived from existing unique device identifiers (e.g., MAC example derived from existing unique device identifiers (e.g., MAC
addresses). In those cases it may not be desirable to assign addresses). In those cases it may not be desirable to assign
addresses to devices via the ACP address information field in the way addresses to devices via the ACP address information field in the way
described in this document. The certificate may simply serve to described in this document. The certificate may simply serve to
identify the ACP domain, and the address field could be empty/unused. identify the ACP domain, and the address field could be empty/unused.
The only fix required in the remaining way the ACP operate is to The only fix required in the remaining way the ACP operate is to
define another element in the domain certificate for the two peers to define another element in the domain certificate for the two peers to
skipping to change at page 132, line 26 skipping to change at page 135, line 8
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
node. Using BRSKI, this could be done for example as additional node. Using BRSKI, this could be done for example as additional
follow-up signaling directly after the certificate enrollment, still follow-up signaling directly after the certificate enrollment, still
leveraging the BRSKI TLS connection and therefore not introducing any leveraging the BRSKI TLS connection and therefore not introducing any
additional connectivity requirements. additional connectivity requirements.
Last but not least, secure channel protocols including their Last but not least, secure channel protocols including their
encapsulation are easily added to ACP solutions. Secure channels may encapsulation are easily added to ACP solutions. ACP hop-by-hop
even be replaced by simple neighbor authentication to create network layer secure channels could also be replaced by end-to-end
simplified ACP variations for environments where no real security is security plus other means for infrastructure protection. Any future
required but just protection against non-malicious misconfiguration. network OAM should always use end-to-end security anyhow and can
Or for environments where all traffic is known or forced to be end- leverage the domain certificates and is therefore not dependent on
to-end protected and other means for infrastructure protection are security to be provided for by ACP secure channels.
used. Any future network OAM should always use end-to-end security
anyhow and can leverage the domain certificates and is therefore not A.10. Further options / futures
dependent on security to be provided for by ACP secure channels.
A.10.1. Auto-aggregation of routes
Routing in the ACP according to this specification only leverages the
standard RPL mechanism of route optimization, e.g. keeping only
routes that are not towards the RPL root. This is known to scale to
networks with 20,000 or more nodes. There is no auto-aggregation of
routes for /48 ULA prefixes (when using rsub in the domain
information field) and/or Zone-ID based prefixes.
Automatic assignment of Zone-ID and auto-aggregation of routes could
be achieved for example by configuring zone-boundaries, announcing
via GRASP into the zones the zone parameters (zone-ID and /48 ULA
prefix) and auto-aggrating routes on the zone-boundaries. Nodes
would assign their Zone-ID and potentially even /48 prefix based on
the GRASP announcements.
A.10.2. More options for avoiding IPv6 Data-Plane dependency
As described in Section 6.12.2, the ACP depends on the Data-Plane to
establish IPv6 link-local addressing on interfaces. Using a separate
MAC address for the ACP allows to fully isolate the ACP from the data
plane in a way that is compatible with this specification. It is
also an ideal option when using Single-root input/output
virtualization (SR-IOV) in an implementation to isolate the ACP
(https://en.wikipedia.org/wiki/Single-root_input/
output_virtualization [2]) because different SR-IOV interfaces use
different MAC addresses.
When additional MAC address(es) are not available to the ACP,
separation of the ACP could be done at different demux points. The
same subnet interface could have a separate IPv6 IPv6 interface for
the ACP and Data-Plane and therefore separate link-local addresses
for both, where the ACP interface is non-configurable on the data-
plane. This too would be compatible with this specification and not
impact interoperability.
An option that would require additional specification is to use a
different Ethertype from 0x86DD (IPv6) to encapsulate IPv6 packets
for the ACP. This would be a similar approach as used for IP
authentication packets in [IEEE-802.1X] that they use the Extensible
Authentication Protocol over Local Area Network (EAPoL) ethertype
(0x88A2).
Note that in the case of ANI nodes, all the above considerations
equally apply to the encapsulation of BRSKI packets including GRASP
used for BRSKI.
A.10.3. ACP APIs and operational models (YANG)
Future work should define YANG ([RFC7950]) data model and/or node
internal APIs to monitor and manage the ACP.
The elements to include into this model/API include the ACP Adjacency
Table (Section 6.2) and ACP GRASP.
A.10.4. RPL enhancements
..... USA ...... ..... Europe ......
NOC1 NOC2
| |
| metric 100 |
ACP1 --------------------------- ACP2 .
| | . WAN
| metric 10 metric 20 | . Core
| | .
ACP3 --------------------------- ACP4 .
| metric 100 |
| | .
| | . Sites
ACP10 ACP11 .
Figure 16: Dual NOC
The profile for RPL specified in this document builds only one
spanning-tree pathset to a root (NOC). In the presence of multiple
NOCs, routing toward the non-root NOCs may be suboptimal. Figure 16
shows an extreme example. Assuming that node ACP1 becomes the RPL
root, traffic between ACP11 and NOC2 will pass through
ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated
DODAG/routes are shortest paths towards the RPL root.
To overcome these limitations, extensions/modifications to the RPL
profile can provide optimality for multiple NOCs. This requires
utilizing Data-Plane artifact including IPinIP encap/decap on ACP
routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst)
routing table entries could be used.
Flooding of ACP GRASP messages can be further constrained and
therefore optimized by flooding only via links that are part of the
RPL DODAG.
A.10.5. Role assignments
ACP connect is an explicit mechanism to "leak" ACP traffic explicitly
(for example in a NOC). It is therefore also a possible security gap
when it is easy to enable ACP connect on arbitrary compromised ACP
nodes.
One simple solution is to define an extension in the ACP certificates
ACP information field indicating the permission for ACP connect to be
configured on that ACP node. This could similarily be done to decide
whether a node is permitted to be a registrar or not.
Tying the permitted "roles" of an ACP node to the ACP domain
certificate provides fairly strong protection against
misconfiguration, but is still subject to code modifications.
Another interesting role to assign to certificates is that of a NOC
node. This would allow to limit certain type of connections such as
OAM TLS connections to only NOC initiator or responders.
A.10.6. Autonomic L3 transit
In this specification, the ACP can only establish autonomic
connectivity across L2 hops and only explicitly confiured options to
tunnel across L3. Future work should specify mechanisms to
automatically tunnel ACP across L3 networks. A hub&spoke option
would allow to tunnel across the Internet to a cloud or central
instance of the ACP, a peer-to-peer tunneling mechanism could tunnel
ACP islands across an L3VPN infrastructure.
A.10.7. Diagnostics
Section 10.1 describes diagnostics options that can be done without
changing the external, interoperability affecting characteristics of
ACP implementation.
Even better diagnostics of ACP operations is possible with additional
signaling extensions, such as:
1. Consider if LLDP should be a recommended functionality for ANI
devices to improve diagnostics, and if so, which information
elements it should signal (insecure). Includes potentially new
information elements.
2. In alternative to LLDP, A DULL GRASP diagnostics objective could
be defined to carry these information elements.
3. The IDevID of BRSKI pledges should be included in the selected
insecure diagnostics option.
4. A richer set of diagnostics information should be made available
via the secured ACP channels, using either single-hop GRASP or
network wide "topology discovery" mechanisms.
Authors' Addresses Authors' Addresses
Toerless Eckert (editor) Toerless Eckert (editor)
Huawei USA - Futurewei Technologies Inc. Huawei USA - Futurewei Technologies Inc.
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara 95050
USA USA
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
 End of changes. 164 change blocks. 
571 lines changed or deleted 826 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/