draft-ietf-anima-autonomic-control-plane-18.txt   draft-ietf-anima-autonomic-control-plane-19.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: February 8, 2019 Expires: September 12, 2019
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
August 07, 2018 March 11, 2019
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-18 draft-ietf-anima-autonomic-control-plane-19
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
(OAM) communications over a network that is secure and reliable even (OAM) communications over a network that provides automatically
when the network is not configured, or misconfigured. configured hop-by-hop authenticated and encrypted communications via
automatically configured IPv6 even when the network is not
configured, or misconfigured.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 8, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction (Informative) . . . . . . . . . . . . . . . . . 5 1. Introduction (Informative) . . . . . . . . . . . . . . . . . 5
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 8
2. Acronyms and Terminology (Informative) . . . . . . . . . . . 9 2. Acronyms and Terminology (Informative) . . . . . . . . . . . 9
3. Use Cases for an Autonomic Control Plane (Informative) . . . 15 3. Use Cases for an Autonomic Control Plane (Informative) . . . 15
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 15 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 15
3.2. Secure Bootstrap over a not configured Network . . . . . 15 3.2. Secure Bootstrap over a not configured Network . . . . . 16
3.3. Data-Plane Independent Permanent Reachability . . . . . . 16 3.3. Data-Plane Independent Permanent Reachability . . . . . . 16
4. Requirements (Informative) . . . . . . . . . . . . . . . . . 17 4. Requirements (Informative) . . . . . . . . . . . . . . . . . 17
5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 18 5. Overview (Informative) . . . . . . . . . . . . . . . . . . . 18
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 19 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 20
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 20
6.1.1. Certificate Domain Information Field . . . . . . . . 21 6.1.1. Certificate ACP Domain Information Field . . . . . . 21
6.1.2. ACP domain membership check . . . . . . . . . . . . . 23 6.1.2. ACP domain membership check . . . . . . . . . . . . . 24
6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 24 6.1.3. Trust Points and Trust Anchors . . . . . . . . . . . 26
6.1.3.1. GRASP objective for EST server . . . . . . . . . 25 6.1.4. Certificate and Trust Point Maintenance . . . . . . . 27
6.1.3.2. Renewal . . . . . . . . . . . . . . . . . . . . . 26 6.1.4.1. GRASP objective for EST server . . . . . . . . . 27
6.1.3.3. Certificate Revocation Lists (CRLs) . . . . . . . 26 6.1.4.2. Renewal . . . . . . . . . . . . . . . . . . . . . 29
6.1.3.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 27 6.1.4.3. Certificate Revocation Lists (CRLs) . . . . . . . 29
6.1.3.5. Re-enrollment . . . . . . . . . . . . . . . . . . 27 6.1.4.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 30
6.1.3.6. Failing Certificates . . . . . . . . . . . . . . 29 6.1.4.5. Re-enrollment . . . . . . . . . . . . . . . . . . 30
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 29 6.1.4.6. Failing Certificates . . . . . . . . . . . . . . 31
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 30 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 32
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 33 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 33
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 34 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 36
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 35 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 36
6.7. Security Association protocols . . . . . . . . . . . . . 35 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 39
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 35 6.7. Security Association protocols . . . . . . . . . . . . . 39
6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 36 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 39
6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 36 6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 39
6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 37 6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 40
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 37 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 40
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 38 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 41
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 38 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 42
6.8.2. ACP as the Security and Transport substrate for GRASP 38 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 42
6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 40 6.8.2. ACP as the Security and Transport substrate for GRASP 42
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 41 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 45
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 42
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 42
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 43
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 44
6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 46
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 47
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 48
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 49
6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 49
6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 49
6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 50
6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 51
6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 52
6.10.7.5. Further Details . . . . . . . . . . . . . . . . 52
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 52
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 53
6.11.1.1. Summary . . . . . . . . . . . . . . . . . . . . 53
6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 54
6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 54
6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 54
6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 54
6.11.1.6. Objective Function . . . . . . . . . . . . . . . 54
6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 55
6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 55
6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 55
6.11.1.10. P2P communications . . . . . . . . . . . . . . . 55
6.11.1.11. IPv6 address configuration . . . . . . . . . . . 55
6.11.1.12. Administrative parameters . . . . . . . . . . . 56
6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 56
6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 56
6.12. General ACP Considerations . . . . . . . . . . . . . . . 56
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 56
6.12.2. Addressing of Secure Channels . . . . . . . . . . . 57
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 57
6.12.4. Multiple links between nodes . . . . . . . . . . . . 58
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 58
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 61
7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 62
8. Support for Non-ACP Components (Normative) . . . . . . . . . 64
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 64
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 64
8.1.2. Software Components . . . . . . . . . . . . . . . . . 66
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 67
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 68
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 69
8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 70
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 70
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 71
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 72
9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 72 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 46
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 72 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 47
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 73 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 47
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 73 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 48
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 74 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 50
9.3. The Administrator View . . . . . . . . . . . . . . . . . 75 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 51
10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 75 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 52
10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 76 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 53
10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 80 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 54
10.2.1. Registrar interactions . . . . . . . . . . . . . . . 81 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 55
10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 55
10.2.3. Certificate renewal and limitations . . . . . . . . 83 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 56
10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 56
10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 57
10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 84 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 58
10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 58
10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 58
10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86 6.11.1.1. Overview . . . . . . . . . . . . . . . . . . . . 58
10.3.2.2. Fast state propagation and Diagnostics . . . . . 87 6.11.1.2. RPL Instances . . . . . . . . . . . . . . . . . 60
10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87 6.11.1.3. Storing vs. Non-Storing Mode . . . . . . . . . . 60
10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 88 6.11.1.4. DAO Policy . . . . . . . . . . . . . . . . . . . 60
10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88 6.11.1.5. Path Metric . . . . . . . . . . . . . . . . . . 60
10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88 6.11.1.6. Objective Function . . . . . . . . . . . . . . . 61
10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90 6.11.1.7. DODAG Repair . . . . . . . . . . . . . . . . . . 61
10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90 6.11.1.8. Multicast . . . . . . . . . . . . . . . . . . . 61
10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91 6.11.1.9. Security . . . . . . . . . . . . . . . . . . . . 61
10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91 6.11.1.10. P2P communications . . . . . . . . . . . . . . . 61
10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92 6.11.1.11. IPv6 address configuration . . . . . . . . . . . 61
11. Security Considerations . . . . . . . . . . . . . . . . . . . 92 6.11.1.12. Administrative parameters . . . . . . . . . . . 62
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 6.11.1.13. RPL Data-Plane artifacts . . . . . . . . . . . . 62
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94 6.11.1.14. Unknown Destinations . . . . . . . . . . . . . . 62
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 94 6.12. General ACP Considerations . . . . . . . . . . . . . . . 62
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 94 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 63
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 95 6.12.2. Addressing of Secure Channels . . . . . . . . . . . 63
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 95 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 63
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 95 6.12.4. Multiple links between nodes . . . . . . . . . . . . 64
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 95 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 64
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 96 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 67
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 96 7.1. Why (Benefits of ACP on L2 switches) . . . . . . . . . . 67
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 96 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 68
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 97 8. Support for Non-ACP Components (Normative) . . . . . . . . . 70
14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 97 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 70
14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 97 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 70
14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 98 8.1.2. Software Components . . . . . . . . . . . . . . . . . 72
14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 98 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 73
14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 100 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 74
14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 102 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 75
14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 104 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 76
14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 105 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 76
14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 106 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 77
14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 107 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 78
14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 109 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 78
14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 113 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 78
14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 113 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 80
14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 114 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 80
14.24. draft-ietf-anima-autonomic-control-plane-18 . . . . . . 116 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 80
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 9.3. The Administrator View . . . . . . . . . . . . . . . . . 81
15.1. Normative References . . . . . . . . . . . . . . . . . . 116 10. ACP Operations (Informative) . . . . . . . . . . . . . . . . 82
15.2. Informative References . . . . . . . . . . . . . . . . . 118 10.1. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 82
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 123 10.2. ACP Registrars . . . . . . . . . . . . . . . . . . . . . 87
Appendix A. Background and Futures (Informative) . . . . . . . . 123 10.2.1. Registrar interactions . . . . . . . . . . . . . . . 87
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 123 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 88
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 124 10.2.3. Certificate renewal and limitations . . . . . . . . 89
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 125 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 90
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 125 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 90
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 126 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 91
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 126 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 91
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 126 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 92
A.5. ACP Information Distribution and multicast . . . . . . . 128 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 93
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 129 10.3.2.2. Fast state propagation and Diagnostics . . . . . 93
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 131 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 94
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 132 10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 94
A.9. Adopting ACP concepts for other environments . . . . . . 133 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 95
A.10. Further options / futures . . . . . . . . . . . . . . . . 134 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 95
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 134 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 96
A.10.2. More options for avoiding IPv6 Data-Plane dependency 135 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 97
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 135 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 97
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 136 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 98
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 136 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 98
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 137 10.4. Configuration and the ACP (summary) . . . . . . . . . . 99
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 137 11. Security Considerations . . . . . . . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 102
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 103
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 104
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 104
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 104
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 104
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 104
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 104
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 105
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 105
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 106
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 106
14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 106
14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 107
14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 107
14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 108
14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 109
14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 111
14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 113
14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 115
14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 115
14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 116
14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 118
14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 122
14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 123
14.23. draft-ietf-anima-autonomic-control-plane-17 . . . . . . 123
14.24. draft-ietf-anima-autonomic-control-plane-18 . . . . . . 125
14.25. draft-ietf-anima-autonomic-control-plane-19 . . . . . . 125
14.26. Open Issues in -19 . . . . . . . . . . . . . . . . . . . 128
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 128
15.1. Normative References . . . . . . . . . . . . . . . . . . 128
15.2. Informative References . . . . . . . . . . . . . . . . . 130
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Appendix A. Background and Futures (Informative) . . . . . . . . 137
A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 137
A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 138
A.3. ACP Neighbor discovery protocol selection . . . . . . . . 139
A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 139
A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 139
A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 140
A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 140
A.5. ACP Information Distribution and multicast . . . . . . . 142
A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 143
A.7. CAs, domains and routing subdomains . . . . . . . . . . . 144
A.8. Intent for the ACP . . . . . . . . . . . . . . . . . . . 145
A.9. Adopting ACP concepts for other environments . . . . . . 146
A.10. Further options / futures . . . . . . . . . . . . . . . . 148
A.10.1. Auto-aggregation of routes . . . . . . . . . . . . . 148
A.10.2. More options for avoiding IPv6 Data-Plane dependency 149
A.10.3. ACP APIs and operational models (YANG) . . . . . . . 149
A.10.4. RPL enhancements . . . . . . . . . . . . . . . . . . 149
A.10.5. Role assignments . . . . . . . . . . . . . . . . . . 150
A.10.6. Autonomic L3 transit . . . . . . . . . . . . . . . . 151
A.10.7. Diagnostics . . . . . . . . . . . . . . . . . . . . 151
A.10.8. Avoiding and dealing with compromised ACP nodes . . 151
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 153
1. Introduction (Informative) 1. Introduction (Informative)
Autonomic Networking is a concept of self-management: Autonomic Autonomic Networking is a concept of self-management: Autonomic
functions self-configure, and negotiate parameters and settings functions self-configure, and negotiate parameters and settings
across the network. [RFC7575] defines the fundamental ideas and across the network. [RFC7575] defines the fundamental ideas and
design goals of Autonomic Networking. A gap analysis of Autonomic design goals of Autonomic Networking. A gap analysis of Autonomic
Networking is given in [RFC7576]. The reference architecture for Networking is given in [RFC7576]. The reference architecture for
Autonomic Networking in the IETF is specified in the document Autonomic Networking in the IETF is specified in the document
[I-D.ietf-anima-reference-model]. [I-D.ietf-anima-reference-model].
skipping to change at page 7, line 33 skipping to change at page 7, line 40
The remaining sections are non-normative: Section 9 reviews benefits 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 standard or explanations and describes additional details or future standard or
propriety extensions that were considered not to be appropriate for propriety extensions that were considered not to be appropriate for
standardization in this document but were considered important to standardization in this document but were considered important to
document. There are no dependencies against Appendix A to build a document. There are no dependencies against Appendix A to build a
complete working and interoperable ACP according to this document. complete working and interoperable ACP according to this document.
The ACP provides secure IPv6 connectivity, therefore it cannot only The ACP provides secure IPv6 connectivity, therefore it can be used
be used as the secure connectivity for self-management as required not only 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. ACP relies on per-link DULL
GRASP (see Section 6.3) to autodiscover ACP neighbors, and includes
the ACP GRASP instance to provide service discovery for clients of
the ACP (see Section 6.8) including for its own maintenance of ACP
certificates.
The document "Using Autonomic Control Plane for Stable Connectivity The document "Using Autonomic Control Plane for Stable Connectivity
of Network OAM" [RFC8368] describes how the ACP alone can be used to of Network OAM" [RFC8368] describes how the ACP alone can be used to
provide secure and stable connectivity for autonomic and non- provide secure and stable connectivity for autonomic and non-
autonomic Operations Administration and Management (OAM) autonomic Operations Administration and Management (OAM)
applications. That document also explains how existing management applications. That document also explains how existing management
solutions can leverage the ACP in parallel with traditional solutions can leverage the ACP in parallel with traditional
management models, when to use the ACP and how to integrate with management models, when to use the ACP and how to integrate with
potentially IPv4 only OAM backends. potentially IPv4 only OAM backends.
skipping to change at page 8, line 23 skipping to change at page 8, line 34
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 ->"Operational Technology" () (OT) networks. The ACP can operate
equally on layer 3 equipment and on layer 2 equipment such a bridges equally on layer 3 equipment and on layer 2 equipment such as bridges
(see Section 7). The encryption mechanism used by the ACP is defined (see Section 7). The hop-by-hop authentication and confidentiality
to be negotiable, therefore it can be extended to environments with mechanism used by the ACP is defined to be negotiable, therefore it
different encryption protocol preferences. The minimum can be extended to environments with different protocol preferences.
implementation requirements in this document attempt to achieve The minimum implementation requirements in this document attempt to
maximum interoperability by requiring support for few options: IP achieve maximum interoperability by requiring support for multiple
security (IPsec), see [RFC4301]) and datagram Transport Layer options depending on the type of device: IPsec, see [RFC4301], and
Security version 1.2 (DTLS), see [RFC6347]), depending on type of datagram Transport Layer Security version 1.2 (DTLS), see [RFC6347]).
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 Routing instance of IPv6 packet forwarding and routing via the Routing
Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that Protocol for Low-power and Lossy Networks (RPL), see [RFC6550], that
is separate from routing and forwarding for the Data-Plane (user is separate from routing and forwarding for the Data-Plane (user
traffic). traffic).
skipping to change at page 9, line 24 skipping to change at page 9, line 35
plane software requirement. plane software requirement.
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 for ACP secure
protocol choices already making ACP more applicable to constrained channels are two protocol choices already making ACP more applicable
environments. See Appendix A.9 for discussions about how future to constrained environments. Support for constrained devices in this
standards or proprietary extensions/variations of the ACP could specification is opportunistic, but not complete, because the
better meet different expectations from those on which the current reliable transport for GRASP (see Section 6.8.2) only specifies TCP/
design is based. TLS). See Appendix A.9 for discussions about how future standards or
proprietary extensions/variations of the ACP could better meet
different expectations from those on which the current design is
based including supporting constrained devices better.
2. Acronyms and Terminology (Informative) 2. Acronyms and Terminology (Informative)
[RFC Editor: WG/IETF/IESG review of the terms below asked for [RFC Editor: WG/IETF/IESG review of the terms below asked for
references between these terms when they refer to each other. The references between these terms when they refer to each other. The
only option I could fin RFC/XML to point to a hanging text acronym only option I could fin RFC/XML to point to a hanging text acronym
definition that also displays the actual term is the format="title" definition that also displays the actual term is the format="title"
version, which leads to references such as '->"ACP domain version, which leads to references such as '->"ACP domain
certificate" ()'. I found no reasonable way to eliminate the certificate" ()'. I found no reasonable way to eliminate the
trailing '()' generated by this type of cross references. Can you trailing '()' generated by this type of cross references. Can you
skipping to change at page 12, line 19 skipping to change at page 12, line 32
([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 by simple ACP or ANI node, the Data-Plane is typically provisioned by
means other than autonomically, for example manually (including means other than autonomically, for example manually (including
across the ACP) or via SDN controllers. In a fully Autonomic across the ACP) or via SDN controllers. In a fully Autonomic
Network node, the Data-Plane is managed autonomically via Network node, the Data-Plane is managed autonomically via
Autonomic Functions and Intent. Note that other (non-ANIMA) RFC Autonomic Functions and Intent. Note that other (non-ANIMA) RFCs
use the Data-Plane to refer to what is better called the use the Data-Plane to refer to what is better called the
forwarding plane. This is not the way the term is used in this forwarding plane. This is not the way the term is used in this
document! document!
device: A physical system, or physical node. device: A physical system, or physical node.
Enrollment: The process where a node presents identification (for Enrollment: The process where a node presents identification (for
example through keying material such as the private key of an example through keying material such as the private key of an
IDevID) to a network and acquires a network specific identity 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 track protocol for enrollment of a node with an LDevID. BRSKI is
on EST. based on EST.
GRASP: "Generic Autonomic Signaling Protocol". An extensible GRASP: "Generic Autonomic Signaling Protocol". An extensible
signaling protocol required by the ACP for ACP neighbor discovery. signaling protocol required by the ACP for ACP neighbor discovery.
The ACP also provides the "security and transport substrate" for The ACP also provides the "security and transport substrate" for
the "ACP instance of GRASP". This instance of GRASP runs across the "ACP instance of GRASP". This instance of GRASP runs across
the ACP secure channels to support BRSKI and other NOC/OAM or the ACP secure channels to support BRSKI and other NOC/OAM or
Autonomic Functions. See [I-D.ietf-anima-grasp]. Autonomic Functions. See [I-D.ietf-anima-grasp].
IDevID: An "Initial Device IDentity" X.509 certificate installed by IDevID: An "Initial Device IDentity" X.509 certificate installed by
the vendor on new equipment. Contains information that the vendor on new equipment. Contains information that
establishes the identity of the node in the context of its vendor/ establishes the identity of the node in the context of its vendor/
manufacturer such as device model/type and serial number. See manufacturer such as device model/type and serial number. See
[AR8021]. IDevID cannot be used for the ACP because they are not [AR8021]. IDevID cannot be used for the ACP because they are not
skipping to change at page 14, line 31 skipping to change at page 14, line 48
used as part of the BRSKI protocol. used as part of the BRSKI protocol.
(ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software (ACP/ANI/BRSKI) Registrar: An ACP registrar is an entity (software
and/or person) that is orchestrating the enrollment of ACP nodes and/or person) that is orchestrating the enrollment of ACP nodes
with the ACP domain certificate. ANI nodes use BRSKI, so ANI with the ACP domain certificate. ANI nodes use BRSKI, so ANI
registrars are also called BRSKI registrars. For non-ANI ACP registrars are also called BRSKI registrars. For non-ANI ACP
nodes, the registrar mechanisms are undefined by this document. nodes, the registrar mechanisms are undefined by this document.
See Section 6.10.7. Renewal and other maintenance (such as See Section 6.10.7. Renewal and other maintenance (such as
revocation) of ACP domain certificates may be performed by other revocation) of ACP domain certificates may be performed by other
entities than registrars. EST must be supported for ACP domain entities than registrars. EST must be supported for ACP domain
certificate renewal (see Section 6.1.3). BRSKI is an extension of certificate renewal (see Section 6.1.4). BRSKI is an extension of
EST, so ANI/BRSKI registrars can easily support ACP domain EST, so ANI/BRSKI registrars can easily support ACP domain
certificate renewal in addition to initial enrollment. certificate renewal in addition to initial enrollment.
sUDI: "secured Unique Device Identifier". Another term not used in sUDI: "secured Unique Device Identifier". Another term not used in
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.
skipping to change at page 16, line 4 skipping to change at page 16, line 24
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 such as BRSKI, the ACP ACP and a zero-touch bootstrap mechanism such as BRSKI, the ACP
across a whole network of unconfigured devices can be brought up across a whole network of unconfigured devices can be brought up
without operator/provisioning intervention. The ACP also provides without operator/provisioning intervention. The ACP also provides
additional security for any bootstrap mechanism, because it encrypts additional security for any bootstrap mechanism, because it can
the traffic along the path hop-by-hop. provide encrypted discovery (via ACP GRASP) of registrars or other
bootstrap servers by bootstrap proxies connecting to nodes that are
to be bootstrapped and the ACP encryption hides the identities of the
communicating entities (pledge and registrar), making it more
difficult to learn which network node might be attackable. The ACP
domain certificate can also be used to end-to-end encrypt the
bootstrap communication between such proxies and server. Note that
bootstrapping here includes not only the first step that can be
provided by BRSKI (secure keys), but also later stages where
configuration is bootstrapped.
3.3. Data-Plane Independent Permanent Reachability 3.3. Data-Plane Independent Permanent Reachability
Today, most critical control plane protocols and network management Today, most critical control plane protocols and 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 management plane work as expected. the Data-Plane and the management plane work as expected.
skipping to change at page 17, line 16 skipping to change at page 17, line 45
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 (Informative) 4. Requirements (Informative)
The following requirements were identified as the basis for the The following requirements were identified for the design of the ACP
design of the ACP based on the above use-cases (Section 3). These based on the above use-cases (Section 3). These requirements are
requirements are informative for this specification because they informative. The ACP as specified in the normative parts of this
(merely) represent the use-case requirements. The keywords are document is meeting or exceeding these use-case requirements:
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, infrastructure security (filtering based on known Data-Plane, infrastructure security (filtering based on known
address space). address space).
ACP3: The ACP _MUST_ use autonomically managed address space. ACP3: The ACP must use autonomically managed address space. Reason:
Reason: easy bootstrap and setup ("autonomic"); robustness easy bootstrap and setup ("autonomic"); robustness (admin
(admin can't mess things up so easily). This document cannot break network easily). This document suggests using
suggests using ULA addressing for this purpose ("Unique Local ULA addressing for this purpose ("Unique Local Address", see
Address", see [RFC4193]). [RFC4193]).
ACP4: The ACP _MUST_ be generic, that is it MUST be usable by all ACP4: The ACP must be generic, that is it must be usable by all the
the functions and protocols of the ANI. Clients of the ACP functions and protocols of the ANI. Clients of the ACP must
MUST NOT be tied to a particular application or transport not be tied to a particular application or transport protocol.
protocol.
ACP5: The ACP _MUST_ provide security: Messages coming through the ACP5: The ACP must provide security: Messages coming through the ACP
ACP MUST be authenticated to be from a trusted node, and must be authenticated to be from a trusted node, and should
SHOULD (very strong SHOULD) be encrypted. (very strong should) be encrypted.
Explanation for ACP4: In a fully autonomic network (AN), newly Explanation for ACP4: In a fully autonomic network (AN), newly
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 is crucial to support ACP also intends to support non-AN networks, it is crucial to support
IPv6 layer connectivity across the ACP to support any transport and IPv6 layer connectivity across the ACP to support any transport and
application layer protocols. application layer protocols.
skipping to change at page 18, line 32 skipping to change at page 19, line 11
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
nodes supporting ACP. nodes supporting ACP.
3. For each node in the candidate peer list, it authenticates that 3. For each node in the candidate peer list, it authenticates that
node and negotiates a mutually acceptable channel type. node (according to Section 6.1.2) and negotiates a mutually
acceptable channel type.
4. For each node in the candidate peer list, it then establishes a 4. For each node in the candidate peer list, it then establishes a
secure tunnel of the negotiated type. The resulting tunnels are secure tunnel of the negotiated type. The resulting tunnels are
then placed into the previously set up VRF. This creates an then placed into the previously set up VRF. This creates an
overlay network with hop-by-hop tunnels. overlay network with hop-by-hop tunnels.
5. Inside the ACP VRF, each node assigns its ULA IPv6 address to a 5. Inside the ACP VRF, each node assigns its ULA IPv6 address to a
Loopback interface assigned to the ACP VRF. Loopback interface assigned to the ACP VRF.
6. Each node runs a lightweight routing protocol, to announce 6. Each node runs a lightweight routing protocol, to announce
skipping to change at page 21, line 7 skipping to change at page 21, line 44
The ACP domain certificate SHOULD be used for any authentication The ACP domain certificate SHOULD be used for any authentication
between nodes with ACP domain certificates (ACP nodes and NOC nodes) between nodes with ACP domain certificates (ACP nodes and NOC nodes)
where the required condition is ACP domain membership, such as ACP where the required condition is ACP domain membership, such as ACP
node to NOC/OAM end-to-end security and ASA to ASA end-to-end node to NOC/OAM end-to-end security and ASA to ASA end-to-end
security. Section 6.1.2 defines this "ACP domain membership check". security. Section 6.1.2 defines this "ACP domain membership check".
The uses of this check that are standardized in this document are for The uses of this check that are standardized in this document are for
the establishment of ACP secure channels (Section 6.6) and for ACP the establishment of ACP secure channels (Section 6.6) and for ACP
GRASP (Section 6.8.2). GRASP (Section 6.8.2).
6.1.1. Certificate Domain Information Field 6.1.1. Certificate ACP 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 occurrences of rfcSELF in [RFC Editor: Please substitute SELF in all occurrences of rfcSELF in
this document with the RFC number assigned to this document and this document with the RFC number assigned to this document and
remove this comment line] remove this comment line]
domain-information = local-part "@" acp-domain-name domain-information = local-part "@" acp-domain-name
local-part = key [ "." local-info ] local-part = key [ "." local-info ]
key = "rfcSELF" key = "rfcSELF"
local-info = [ acp-address ] [ "+" rsub extensions ] local-info = [ acp-address ] [ "+" rsub extensions ]
acp-address = 32hex-dig | 0 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 standard 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
skipping to change at page 22, line 4 skipping to change at page 22, line 39
authenticate nodes as ACP domain members / ACP secure channel peers authenticate nodes as ACP domain members / ACP secure channel peers
when they have an empty or 0-value acp-address field. See when they have an empty or 0-value acp-address field. See
Section 6.1.2. Section 6.1.2.
"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 channels 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 (see Section 6.10.2). If the operator does not own
choose a string (in FQDN format) that it intends to be equally any FQDN, it should choose a string (in FQDN format) that it intends
unique. to be equally unique.
"routing-subdomain" is the autonomic subdomain composed of "rsub" and "routing-subdomain" is the autonomic subdomain composed of "rsub" and
"acp-domain-name". "rsub" is optional. When not present, "routing- "acp-domain-name". "rsub" is optional. When not present, "routing-
subdomain" is the same as "acp-domain-name". "routing-subdomain" subdomain" is the same as "acp-domain-name". "routing-subdomain"
determines the /48 ULA prefix for ACP addresses. "rsub" therefore determines the /48 ULA prefix for ACP addresses. "rsub" therefore
allows to use multiple /48 ULA prefixes in an ACP domain. See allows to use multiple /48 ULA prefixes in an ACP domain. See
Appendix A.7 for example use-cases. Appendix A.7 for example use-cases.
The optional "extensions" field is used for future standardized The optional "extensions" field is used for future standardized
extensions to this specification. It MUST be ignored if present and extensions to this specification. It MUST be ignored if present and
skipping to change at page 22, line 32 skipping to change at page 23, line 22
routing-subdomain as the domain part of the domain-information, routing-subdomain as the domain part of the domain-information,
rsub and acp-domain-name could not be separated from each other. rsub and acp-domain-name could not be separated from each other.
It also makes acp-domain-name a valid e-mail target across all It also makes acp-domain-name a valid e-mail target across all
routing-subdomains. routing-subdomains.
o "acp-address" cannot use standard IPv6 address formats because it o "acp-address" cannot use standard IPv6 address formats because it
must match the simple dot-atom format of [RFC5322]. The character must match the simple dot-atom format of [RFC5322]. The character
":" is not allowed in that format. ":" is not allowed in that format.
o If "acp-address" is empty, and "rsub" is empty too, the "local- o If "acp-address" is empty, and "rsub" is empty too, the "local-
part" will have the format "rfcSELF + + extension(s)". The two part" will have the format "rfcSELF++extension(s)". The two plus
plus characters are necessary so the node can unambiguously parse characters are necessary so the node can unambiguously parse that
that both "acp-address" and "rsub" are empty. both "acp-address" and "rsub" are empty.
o The maximum size of "domain-information" is 254 characters and the o The maximum size of "domain-information" is 254 characters and the
maximum size of node-info is 64 characters according to [RFC5280] maximum size of node-info is 64 characters according to [RFC5280]
that is referring to [RFC2821] (superseded by [RFC5321]). 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
skipping to change at page 23, line 12 skipping to change at page 23, line 50
introduction of a novel information element because that could introduction of a novel information element because that could
require extensions to such pre-existing ASN.1 parsers. require extensions to such pre-existing ASN.1 parsers.
o subjectAltName / rfc822Name is a pre-existing element that must be o subjectAltName / rfc822Name is a pre-existing element that must be
supported by all existing ASN.1 parsers for LDevID. supported by all existing ASN.1 parsers for LDevID.
o The element required for the ACP should not be misinterpreted by o The element required for the ACP should not be misinterpreted by
any other uses of the LDevID. If the element used for the ACP is any other uses of the LDevID. If the element used for the ACP is
interpreted by other uses, the impact should be benign. interpreted by other uses, the impact should be benign.
o The element should not require additional ASN.1 en/decoding,
because it is unclear if all, especially embedded devices
certificate libraries would support extensible ASN.1
functionality.
o Using an IP address format encoding could result in non-benign o Using an IP address format encoding could result in non-benign
misinterpretation of the domain information field; other uses misinterpretation of the domain information field; other uses
unaware of the ACP could try to do something with the ACP address unaware of the ACP could try to do something with the ACP address
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. The ACP information field o rfc822Name encoding is very flexible. It allows to encode all the
encodes the full ACP address AND the domain name with rsub part, different fields of information required for the ACP.
so that it is easier to examine/use the "domain information
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
skipping to change at page 24, line 8 skipping to change at page 24, line 48
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
candidate peer certificate, independent of the protocol used: candidate peer certificate, independent of the protocol used:
1: The peer certificate is valid (lifetime). 1: The peer certificate is valid (lifetime).
2: The peer has proved ownership of the private key associated with 2: The peer has proved ownership of the private key associated with
the certificate's public key. the certificate's public key.
3: The peer's certificate is signed by one of the trust anchors 3: The peer's certificate passes certificate path validation as
associated with the ACP domain certificate. defined in [RFC5280] against one of the Trust Anchors associated
with the ACP nodes ACP domain certificate (see Section 6.1.3
below).
4: If the node certificate indicates a Certificate Revocation List 4: If the node certificate indicates a Certificate Revocation List
(CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or
Online Certificate Status Protocol (OCSP) responder ([RFC5280], Online Certificate Status Protocol (OCSP) responder ([RFC5280],
section 4.2.2.1), then the peer's certificate must be valid section 4.2.2.1), then the peer's certificate must be valid
according to those criteria: An OCSP check for the peer's according to those criteria: An OCSP check for the peer's
certificate across the ACP must succeed or the peer certificate certificate across the ACP must succeed or the peer certificate
must not be listed in the CRL retrieved from the CDP. must not be listed in the CRL retrieved from the CDP. This rule
has to be skipped for ACP secure channel peer authentication when
the node has no ACP or non-ACP connectivity to retrieve current
CRL or access an OCSP responder (see below).
5: The peer's certificate has a syntactically valid ACP domain 5: The peer's certificate has a syntactically valid ACP domain
information field (encoded as subjectAltName / rfc822Name) and the information field (encoded as subjectAltName / rfc822Name) and the
acp-domain-name in that peer's domain information field is the acp-domain-name in that peer's domain information field is the
same as in this ACP node's certificate. same as in this ACP node's certificate (lowercase normalized).
When an ACP node learns later via OCSP/CRL that an ACP peers
certificate for which rule 4 had to be skipped during ACP secure
channel establishment is invalid, then the ACP secure channel to that
peer SHOULD be closed even if this peer is the only connectivity to
access CRL/OCSP. The ACP secure channel connection MUST be retried
periodically to support the case that the neighbor aquires a new,
valid certificate.
Only when checking a candidate peer's certificate for the purpose of Only when checking a candidate peer's certificate for the purpose of
establishing an ACP secure channel, one additional check is establishing an ACP secure channel, one additional check is
performed: performed:
6: The candidate peer certificate's ACP domain information field 6: The candidate peer certificate's ACP domain information field
has a non-empty acp-address field (either 32hex-dig or 0, has a non-empty acp-address field (either 32hex-dig or 0,
according to Figure 2). according to Figure 2).
Rule 6: for the establishment of ACP secure channels ensures that Rule 6 for the establishment of ACP secure channels ensures that they
they will only be built between nodes which indicate through the acp- will only be built between nodes which indicate through the acp-
address in their ACP domain certificate the ability and permission by address in their ACP domain certificate the ability and permission by
the Registrar to participate in ACP secure-channels. the Registrar to participate in ACP secure-channels.
Nodes with an empty acp-address field can only use their ACP domain Nodes with an empty acp-address field can only use their ACP domain
certificate for non-ACP-secure channel authentication purposes. certificate for non-ACP-secure channel authentication purposes.
The special value 0 in an ACP certificates acp-address field is used The special value 0 in an ACP certificates acp-address field is used
for nodes that can and should determine their ACP address through for nodes that can and should determine their ACP address through
other mechanisms than learning it through their ACP domain other mechanisms than learning it through the acp-address field in
certificate. These ACP nodes are permitted to establish ACP secure their ACP domain certificate. These ACP nodes are permitted to
channels. Mechanisms for those nodes to determine their ACP address establish ACP secure channels. Mechanisms for those nodes to
are outside the scope of this specification. determine their ACP address are outside the scope of this
specification.
6.1.3. Certificate Maintenance Formally, the ACP domain membership check includes both the
authentication of the peers certificate (steps 1...4) and a check
authorizing this node and the peer to establish an ACP connection
and/or any other secure connection across ACP or data-plane end to
end. Step 5 authorizes to build any non-ACP secure connection
between members of the same ACP domain, step 5 and 6 are required to
build an ACP secure channel. For brevity, the remainder of this
document refers to this process only as authentication instead of as
authentication and authorization.
ACP nodes MUST support certificate renewal via EST ("Enrollment over 6.1.3. Trust Points and Trust Anchors
Secure Transport", see [RFC7030]) and MAY support other mechanisms.
An ACP network MUST have at least one ACP node supporting EST server ACP nodes need Trust Point (TP) certificates to perform certificate
functionality across the ACP so that EST renewal is useable. path validation as required by Section 6.1.2, rule 3. Trust Point(s)
must be provisioned to an ACP node (together with its ACP domain
certificate) by an ACP Registrar during initial enrolment of a
candidate ACP node. ACP nodes MUST also support renewal of TPs via
EST as described below in Section 6.1.4.
Trust Point is the term used in this document for a certificate
authority (CA) and its associated set of certificates. Multiple
certificates are required for a CA to deal with CA certificate
renewals as explained in Section 4.4 of CMP ([RFC4210]).
A certificate path is a chain of certificates starting at a self-
signed certificate of a so called root-CA or Trust Anchor, followed
by zero or more intermediate Trust Point or sub-CA certificates and
ending with an ACP certificate. Certificate path validation
authenticates that the ACP certificate is signed by a Trust Anchor,
directly or indirectly via one or more intermediate Trust Points.
Note that different ACP nodes may have different Trust Points and
even different Trust Anchors in their certificate path, as long as
the set of Trust Points for all ACP node includes the same set of
Trust Anchors (usually 1), and each ACP nodes set of Trust Anchors
includes the intermediate Trust Points for its own ACP domain
certificate. The protocols through which ACP domain membership check
rules 1-4 are performed therefore need to support the exchange not
only of the ACP nodes certificates, but also their intermediate Trust
Points.
ACP nodes MUST support for the ACP domain membership check the
certificate path validation with 0 or 1 intermediate Trust Points.
They SHOULD support 2 intermediate Trust Points and two Trust Anchors
(to permit migration to different root-CAs).
Trust Points for ACP domain certificates must be trusted to sign
certificates with valid ACP domain information fields only for
trusted ACP registrars of that domain. This can be achieved by using
Trust Anchors private to the owner of the ACP domain or potentially
through appropriate contractual agreements between the involved
parties. Public CA without such obligations and guarantees can not
be used.
A single owner can operate multiple independent ACP domains from the
same set of private trust anchors (CAs) when the ACP Registrars are
trusted not to permit certificates with incorrect ACP information
fields to be signed. Such as ACP information with a wrong acp-domain
field. In this case, CAs can be completely unaware of ACP specifics,
so that it should be possible to use any existing CA software. When
ACP Registrars are not to be trusted, the correctness of the ACP
domain information field for the candidate ACP node has to be
verified by the CA signing the ACP domain certificate.
6.1.4. Certificate and Trust Point Maintenance
ACP nodes MUST support renewal of their Certificate and Trust Points
(TP) via EST ("Enrollment over Secure Transport", see [RFC7030]) and
MAY support other mechanisms. An ACP network MUST have at least one
ACP node supporting EST server 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
ability for this remembered EST server to also be set by the ACP ability for this remembered EST server to also be set by the ACP
Registrar (see Section 6.10.7) that initially enrolled the ACP device Registrar (see Section 6.10.7) that initially enrolled the ACP device
with its ACP domain certificate. When BRSKI (see with its ACP domain certificate. When BRSKI (see
[I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of
the BRSKI registrar from the BRSKI TLS connection SHOULD be the BRSKI registrar from the BRSKI TLS connection SHOULD be
remembered and used for the next renewal via EST if that registrar remembered and used for the next renewal via EST if that registrar
also announces itself as an EST server via GRASP (see next section) also announces itself as an EST server via GRASP (see next section)
on its ACP address. on its ACP address.
6.1.3.1. GRASP objective for EST server 6.1.4.1. GRASP objective for EST server
ACP nodes that are EST servers MUST announce their service via GRASP ACP nodes that are EST servers MUST announce their service via GRASP
in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp], in the ACP through M_FLOOD messages. See [I-D.ietf-anima-grasp],
section 2.8.11 for the definition of this message type: section 2.8.11 for the definition of this message type:
Example: Example:
[M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000,
["SRV.est", 4, 255 ], ["SRV.est", 4, 255 ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
skipping to change at page 25, line 42 skipping to change at page 28, line 25
The formal definition of the objective in Concise data definition The formal definition of the objective in Concise data definition
language (CDDL) (see [I-D.ietf-cbor-cddl]) is as follows: language (CDDL) (see [I-D.ietf-cbor-cddl]) is as follows:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
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 = any ; 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 name "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]. Objective-value MUST be registered service name for [RFC7030]. Objective-value MUST be
ignored if present. Backward compatible extensions to [RFC7030] MAY ignored if present. Backward compatible extensions to [RFC7030] MAY
be indicated through objective-value. Non [RFC7030] compatible be indicated through objective-value. Non [RFC7030] compatible
certificate renewal 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
skipping to change at page 26, line 23 skipping to change at page 29, line 7
three 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.4.2. Renewal
When performing renewal, the node SHOULD attempt to connect to the When performing renewal, the node SHOULD attempt to connect to the
remembered EST server. If that fails, it SHOULD attempt to connect remembered EST server. If that fails, it SHOULD attempt to connect
to an EST server learned via GRASP. The server with which to an EST server learned via GRASP. The server with which
certificate renewal succeeds SHOULD be remembered for the next certificate renewal succeeds SHOULD be remembered for the next
renewal. renewal.
Remembering the last renewal server and preferring it provides Remembering the last renewal server and preferring it provides
stickiness which can help diagnostics. It also provides some stickiness which can help diagnostics. It also provides some
protection against off-path compromised ACP members announcing bogus protection against off-path compromised ACP members announcing bogus
information into GRASP. information into GRASP.
Renewal of certificates SHOULD start after less than 50% of the Renewal of certificates SHOULD start after less than 50% of the
domain certificate lifetime so that network operations has ample time domain certificate lifetime so that network operations has ample time
to investigate and resolve any problems that causes a node to not to investigate and resolve any problems that causes a node to not
renew its domain certificate in time - and to allow prolonged periods renew its domain certificate in time - and to allow prolonged periods
of running parts of a network disconnected from any CA. of running parts of a network disconnected from any CA.
6.1.3.3. Certificate Revocation Lists (CRLs) 6.1.4.3. Certificate Revocation Lists (CRLs)
The ACP node SHOULD support Certificate Revocation Lists (CRL) via The ACP node SHOULD support Certificate Revocation Lists (CRL) via
HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s) HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s)
MUST be indicated in the Domain Certificate when used. If the CDP MUST be indicated in the Domain Certificate when used. If the CDP
URL uses an IPv6 address (ULA address when using the addressing rules URL uses an IPv6 address (ULA address when using the addressing rules
specified in this document), the ACP node will connect to the CDP via specified in this document), the ACP node will connect to the CDP via
the ACP. If the CDP URL uses an IPv6 address (ULA address when using the ACP. If the CDP uses a domain name, the ACP node will connect to
the addressing rules specified in this document), the ACP node will the CDP via the Data-Plane.
connect to the CDP via the ACP. If the CDP uses a domain name, the
ACP node will connect to the CDP via the Data-Plane.
It is common to use domain names for CDP(s), but there is no It is common to use domain names for CDP(s), but there is no
requirement for the ACP to support DNS. Any DNS lookup in the Data- requirement for the ACP to support DNS. Any DNS lookup in the Data-
Plane is not only a possible security issue, but it would also not Plane is not only a possible security issue, but it would also not
indicate whether the resolved address is meant to be reachable across indicate whether the resolved address is meant to be reachable across
the ACP. Therefore, the use of an IPv6 address versus the use of a the ACP. Therefore, the use of an IPv6 address versus the use of a
DNS name doubles as an indicator whether or not to reach the CDP via DNS name doubles as an indicator whether or not to reach the CDP via
the ACP. the ACP.
A CDP can be reachable across the ACP either by running it on a node A CDP can be reachable across the ACP either by running it on a node
with ACP or by connecting its node via an ACP connect interface (see with ACP or by connecting its node via an ACP connect interface (see
Section 8.1). The CDP SHOULD use an ACP domain certificate for its Section 8.1). The CDP SHOULD use an ACP domain certificate for its
HTTPs connections. The connecting ACP node SHOULD verify that the HTTPs connections. The connecting ACP node SHOULD verify that the
CDP certificate used during the HTTPs connection has the same ACP CDP certificate used during the HTTPs connection has the same ACP
address as indicated in the CDP URL of the nodes ACP domain address as indicated in the CDP URL of the nodes ACP domain
certificate certificate if the CDP URL uses an IPv6 address.
6.1.3.4. Lifetimes 6.1.4.4. Lifetimes
Certificate lifetime may be set to shorter lifetimes than customary Certificate lifetime may be set to shorter lifetimes than customary
(1 year) because certificate renewal is fully automated via ACP and (1 year) because certificate renewal is fully automated via ACP and
EST. The primary limiting factor for shorter certificate lifetimes EST. The primary limiting factor for shorter certificate lifetimes
is load on the EST server(s) and CA. It is therefore recommended is load on the EST server(s) and CA. It is therefore recommended
that ACP domain certificates are managed via a CA chain where the that ACP domain certificates are managed via a CA chain where the
assigning CA has enough performance to manage short lived assigning CA has enough performance to manage short lived
certificates. See also Section 10.2.4 for discussion about an certificates. See also Section 10.2.4 for discussion about an
example setup achieving this. example setup achieving this. See also [I-D.ietf-acme-star].
When certificate lifetimes are sufficiently short, such as few hours, When certificate lifetimes are sufficiently short, such as few hours,
certificate revocation may not be necessary, allowing to simplify the certificate revocation may not be necessary, allowing to simplify the
overall certificate maintenance infrastructure. overall certificate maintenance infrastructure.
See Appendix A.2 for further optimizations of certificate maintenance See Appendix A.2 for further optimizations of certificate maintenance
when BRSKI can be used ("Bootstrapping Remote Secure Key when BRSKI can be used ("Bootstrapping Remote Secure Key
Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]). Infrastructures", see [I-D.ietf-anima-bootstrapping-keyinfra]).
6.1.3.5. Re-enrollment 6.1.4.5. Re-enrollment
An ACP node may determine that its ACP domain certificate has An ACP node may determine that its ACP domain certificate has
expired, for example because the ACP node was powered down or expired, for example because the ACP node was powered down or
disconnected longer than its certificate lifetime. In this case, the disconnected longer than its certificate lifetime. In this case, the
ACP node SHOULD convert to a role of a re-enrolling candidate ACP ACP node SHOULD convert to a role of a re-enrolling candidate ACP
node. node.
In this role, the node does maintain the trust anchor and certificate In this role, the node does maintain the trust anchor and certificate
chain associated with its ACP domain certificate exclusively for the chain associated with its ACP domain certificate exclusively for the
purpose of re-enrollment, and attempts (or waits) to get re-enrolled purpose of re-enrollment, and attempts (or waits) to get re-enrolled
with a new ACP certificate. The details depend on the mechanisms/ with a new ACP certificate. The details depend on the mechanisms/
protocols used by the ACP registrars. protocols used by the ACP registrars.
Please refer to Section 6.10.7 for explanations about ACP registrars Please refer to Section 6.10.7 and
and vouchers as used in the following text. [I-D.ietf-anima-bootstrapping-keyinfra] for explanations about ACP
registrars and vouchers as used in the following text. When ACP is
intended to be used without BRSKI, the details about BRSKI and
vouchers in the following text can be skipped.
When BRSKI is used (aka: on ACP nodes that are ANI nodes), the re- When BRSKI is used (i.e.: on ACP nodes that are ANI nodes), the re-
enrolling candidate ACP node would attempt to enroll like a candidate enrolling candidate ACP node would attempt to enroll like a candidate
ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID, ACP node (BRSKI pledge), but instead of using the ACP nodes IDevID,
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 node's 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.
skipping to change at page 29, line 8 skipping to change at page 31, line 41
therefore the injection of certificate failures could otherwise make therefore the injection of certificate failures could otherwise make
the ACP node easily attackable remotely. the ACP node easily attackable remotely.
When using BRSKI or other protocol/mechanisms supporting vouchers, When using BRSKI or other protocol/mechanisms supporting vouchers,
maintaining existing trust anchor information allows for re- maintaining existing trust anchor information allows for re-
enrollment of expired ACP certificates to be more lightweight, enrollment of expired ACP certificates to be more lightweight,
especially in environments where repeated acquisition of vouchers especially in environments where repeated acquisition of vouchers
during the lifetime of ACP nodes may be operationally expensive or during the lifetime of ACP nodes may be operationally expensive or
otherwise undesirable. otherwise undesirable.
6.1.3.6. Failing Certificates 6.1.4.6. Failing Certificates
An ACP domain certificate is called failing in this document, if/when An ACP domain certificate is called failing in this document, if/when
the ACP node can determine that it was revoked (or explicitly not the ACP node can determine that it was revoked (or explicitly not
renewed), or in the absence of such explicit local diagnostics, when renewed), or in the absence of such explicit local diagnostics, when
the ACP node fails to connect to other ACP nodes in the same ACP the ACP node fails to connect to other ACP nodes in the same ACP
domain using its ACP certificate. For connection failures to domain using its ACP certificate. For connection failures to
determine the ACP domain certificate as the culprit, the peer should determine the ACP domain certificate as the culprit, the peer should
pass the domain membership check (Section 6.1.2) and other reasons pass the domain membership check (Section 6.1.2) and other reasons
for the connection failure can be excluded because of the connection for the connection failure can be excluded because of the connection
error diagnostics. error diagnostics.
skipping to change at page 29, line 36 skipping to change at page 32, line 21
discover through connection failure are that the domain certificate discover through connection failure are that the domain certificate
or any of its signing certificates could have been revoked or may or any of its signing certificates could have been revoked or may
have expired, but the ACP node cannot self-diagnose this condition have expired, but the ACP node cannot self-diagnose this condition
directly. Revocation information or clock synchronization may only directly. Revocation information or clock synchronization may only
be available across the ACP, but the ACP node cannot build ACP secure be available across the ACP, but the ACP node cannot build ACP secure
channels because ACP peers reject the ACP node's domain certificate. channels because ACP peers reject the ACP node's domain certificate.
ACP nodes SHOULD support the option to determines whether its ACP ACP nodes SHOULD support the option to determines whether its ACP
certificate is failing, and when it does, put itself into the role of certificate is failing, and when it does, put itself into the role of
a re-enrolling candidate ACP node as explained above a re-enrolling candidate ACP node as explained above
(Section 6.1.3.5). (Section 6.1.4.5).
6.2. ACP Adjacency Table 6.2. ACP Adjacency Table
To know to which nodes to establish an ACP channel, every ACP node To know to which nodes to establish an ACP channel, every ACP node
maintains an adjacency table. The adjacency table contains maintains an adjacency table. The adjacency table contains
information about adjacent ACP nodes, at a minimum: Node-ID information about adjacent ACP nodes, at a minimum: Node-ID
(identifier of the node inside the ACP, see Section 6.10.3 and (identifier of the node inside the ACP, see Section 6.10.3 and
Section 6.10.5), interface on which neighbor was discovered (by GRASP Section 6.10.5), interface on which neighbor was discovered (by GRASP
as explained below), link-local IPv6 address of neighbor on that as explained below), link-local IPv6 address of neighbor on that
interface, certificate (including domain information field). An ACP interface, certificate (including domain information field). An ACP
node MUST maintain this adjacency table up to date. This table is node MUST maintain this adjacency table. This table is used to
used to determine to which neighbor an ACP connection is established. determine to which neighbor an ACP connection is established.
Where the next ACP node is not directly adjacent (i.e., not on a link Where the next ACP node is not directly adjacent (i.e., not on a link
connected to this node), the information in the adjacency table can connected to this node), the information in the adjacency table can
be supplemented by configuration. For example, the Node-ID and IP be supplemented by configuration. For example, the Node-ID and IP
address could be configured. address could be configured. See Section 8.2.
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 the ACP domain membership check against
the peer (see Section 6.1.2).
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.
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 Discovery Unsolicited Link-Local (DULL) GRASP is a limited subset of
insecure link-local scope. See section 2.5.2 of GRASP intended to operate across an insecure link-local scope. See
[I-D.ietf-anima-grasp] for its formal definition. The ACP uses one section 2.5.2 of [I-D.ietf-anima-grasp] for its formal definition.
instance of DULL GRASP for every L2 interface of the ACP node to The ACP uses one instance of DULL GRASP for every L2 interface of the
discover link level adjacent candidate ACP neighbors. Unless ACP node to discover link level adjacent candidate ACP neighbors.
modified by policy as noted earlier (Section 5 bullet point 2.), Unless modified by policy as noted earlier (Section 5 bullet point
native interfaces (e.g., physical interfaces on physical nodes) 2.), 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 StateLess 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).
skipping to change at page 32, line 44 skipping to change at page 35, line 21
ACP node on the sending interface. ACP node on the sending interface.
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". It is the main protocol used by the Internet IP security
the Internet IP security architecture (IPsec). We therefore use the architecture (IPsec). We therefore use the term "IKEv2" and not
term "IKEv2" and not "IPsec" in the GRASP definitions and example "IPsec" in the GRASP definitions and example above. "IKEv2" has a
above. "IKEv2" has a well-defined port number 500, but in the above well-defined port number 500, but in the above example, the candidate
example, the candidate ACP neighbor is offering ACP secure channel ACP neighbor is offering ACP secure channel negotiation via IKEv2 on
negotiation via IKEv2 on port 15000 (for the sake of creating a non- port 15000 (for the sake of creating a non-standard example).
standard example).
"DTLS" indicates datagram Transport Layer Security version 1.2. "DTLS" indicates datagram Transport Layer Security version 1.2.
There is no default UDP port, it must always be locally assigned by There is no default UDP port, it must always be locally assigned by
the node. See Section 6.7.2. 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
values of "IKEv2" and "DTLS". There is no distinction between IKEv2 objective-values of "IKEv2" and "DTLS". There is no distinction
native and GRE-IKEv2 because this is purely negotiated via IKEv2. between 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
needs to flood multiple versions of the "AN_ACP" objective so that needs to flood multiple versions of the "AN_ACP" objective so that
each method can be accompanied by its own locator-option. This can each method can be accompanied by its own locator-option. This can
use a single GRASP M_FLOOD message as shown in Figure 5. use a single GRASP M_FLOOD message as shown in Figure 5.
Note that a node serving both as an ACP node and BRSKI Join Proxy may Note that a node serving both as an ACP node and BRSKI Join Proxy may
choose to distribute the "AN_ACP" objective and the respective BRSKI choose to distribute the "AN_ACP" objective and the respective BRSKI
in the same M_FLOOD message, since GRASP allows multiple objectives in the same M_FLOOD message, since GRASP allows multiple objectives
in one message. This may be impractical though if ACP and BRSKI in one message. This may be impractical though if ACP and BRSKI
operations are implemented via separate software modules / ASAs. operations are implemented via separate software modules / ASAs.
The result of the discovery is the IPv6 link-local address of the The result of the discovery is the IPv6 link-local address of the
neighbor as well as its supported secure channel protocols (and non- neighbor as well as its supported secure channel protocols (and non-
standard port they are running on). It is stored in the ACP standard port they are running on). It is stored in the ACP
Adjacency Table, see Section 6.2 which then drives the further Adjacency Table (see Section 6.2), which then drives the further
building of the ACP to that neighbor. building of the ACP to that neighbor.
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 established exclusively between nodes in the same domain. The ACP is established exclusively between nodes in the same domain.
This includes all routing subdomains. Appendix A.7 explains how ACP This includes all routing subdomains. Appendix A.7 explains how ACP
skipping to change at page 34, line 26 skipping to change at page 36, line 47
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 because that code exists already on devices may only support DTLS because that code exists already on
them for end-to-end security, but low-end in-ceiling L2 switches may them for end-to-end security, but low-end in-ceiling L2 switches may
only want to support Media Access Control Security (MacSec, see only want to support Media Access Control Security (MacSec, see
802.1AE ([MACSEC]) because that is also supported in their chips. 802.1AE ([MACSEC]) because that is also supported in their chips.
Only a flexible gateway device may need to support both of these Only a flexible gateway device may need to support both of these
mechanisms and potentially more. mechanisms and potentially more. Note that MacSec is not required by
any profiles of the ACP in this specification but just mentioned as a
likely next interesting secure channel protocol.
To support extensible secure channel protocol selection without a To support extensible secure channel protocol selection without a
single common MTI protocol, ACP nodes must try all the ACP secure single common 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
rules apply: rules apply:
o An ACP node may choose to attempt initiate the different feasible o An ACP node may choose to attempt to initiate the different
ACP secure channel protocols it supports according to its local feasible ACP secure channel protocols it supports according to its
policies sequentially or in parallel, but it MUST support acting local policies sequentially or in parallel, but it MUST support
as a responder to all of them in parallel. acting as a responder to all of them in parallel.
o Once the first secure channel protocol succeeds, the two peers o Once the first secure channel protocol succeeds, the two peers
know each other's certificates because they must be used by all know each other's certificates because they must be used by all
secure channel protocols for mutual authentication. The node with secure channel protocols for mutual authentication. The node with
the lower Node-ID in the ACP address becomes Bob, the one with the the lower Node-ID in the ACP address becomes Bob, the one with the
higher Node-ID in the certificate Alice. higher Node-ID in the certificate Alice.
o Bob becomes passive, he does not attempt to further initiate ACP o Bob becomes passive, he does not attempt to further initiate ACP
secure channel protocols with Alice and does not consider it to be secure channel protocols with Alice and does not consider it to be
an error when Alice closes secure channels. Alice becomes the an error when Alice closes secure channels. Alice becomes the
active party, continues to attempt setting up secure channel active party, continues to attempt setting up secure channel
protocols with Bob until she arrives at the best one from her view protocols with Bob until she arrives at the best one from her view
that also works with Bob. that also works with Bob.
For example, originally Bob could have been the initiator of one ACP For example, originally Bob could have been the initiator of one ACP
secure channel protocol that Bob prefers and the security association secure channel protocol that Bob prefers and the security association
succeeded. The roles of Bob and Alice are then assigned. At this succeeded. The roles of Bob and Alice are then assigned and the
stage, the protocol may not even have completed negotiating a common connection setup is completed. The protocol could for example be
security profile. The protocol could for example be IPsec via IKEv2 IPsec via IKEv2 ("IP security", see [RFC4301] and "Internet Key
("IP security", see [RFC4301] and "Internet Key Exchange protocol Exchange protocol version 2", see [RFC7296]. It is now up to Alice
version 2", see [RFC7296]. It is now up to Alice to decide how to to decide how to proceed. Even if the IPsec connection from Bob
proceed. Even if the IPsec connection from Bob succeeded, Alice succeeded, Alice might prefer another secure protocol over IPsec
might prefer another secure protocol over IPsec (e.g., FOOBAR), and (e.g., FOOBAR), and try to set that up with Bob. If that preference
try to set that up with Bob. If that preference of Alice succeeds, of Alice succeeds, she would close the IPsec connection. If no
she would close the IPsec connection. If no better protocol attempt better protocol attempt succeeds, she would keep the IPsec
succeeds, she would keep the IPsec connection. connection.
The following sequence of steps show this example in more detail:
[1] Node 1 sends GRASP AN_ACP message to announce itself
[2] Node 2 sends GRASP AN_ACP message to announce itself
[3] Node 2 receives [1] from Node 1
[4:C1] Because of [3], Node 2 starts as initiator on its
preferred secure channel protocol towards Node 1.
Connection C1.
[5] Node 1 receives [2] from Node 2
[6:C2] Because of [5], Node 1 starts as initiator on its
preferred secure channel protocol towards Node 2.
Connection C2.
[7:C1] Node1 and Node2 have authenticated each others
certificate on connection C1 as valid ACP peers.
[8:C1] Node 1 certificate has lower ACP Node-ID than Node2,
therefore Node 1 considers itself Bob and Node 2 Alice
on connection C1. Connection setup C1 is completed.
[9] Node 1 (Bob)) refrains from attempting any further secure
channel connections to Node 2 (Alice) as learned from [2]
because it knows from [8:C1] that it is Bob relative
to Node 1.
[10:C2] Node1 and Node2 have authenticated each others
certificate on connection C2 (like [7:C1]).
[11:C2] Node 2 certificate has lower ACP Node-ID than Node2,
therefore Node 1 considers itself Bob and Node 2 Alice
on connection C1, but they also identify that C2 is to the
same mutual peer as their C1, so this has no further impact.
[12:C2] Node 1 (Alice) closes C1. Because of [8:C1], Node 2 (Bob)
expected this.
[13] Node 1 (Alice) and Node 2 (Bob) start data transfer across
C2, which makes it become a secure channel for the ACP.
Figure 7: Secure Channel sequence of steps
All this negotiation is in the context of an "L2 interface". Alice All this negotiation is in the context of an "L2 interface". Alice
and Bob will build ACP connections to each other on every "L2 and Bob will build ACP connections to each other on every "L2
interface" that they both connect to. An autonomic node must not interface" that they both connect to. An autonomic node must not
assume that neighbors with the same L2 or link-local IPv6 addresses assume that neighbors with the same L2 or link-local IPv6 addresses
on different L2 interfaces are the same node. This can only be on different L2 interfaces are the same node. This can only be
determined after examining the certificate after a successful determined after examining the certificate after a successful
security association attempt. security association attempt.
6.6. Candidate ACP Neighbor verification 6.6. Candidate ACP Neighbor verification
Independent of the security association protocol chosen, candidate Independent of the security association protocol chosen, candidate
ACP neighbors need to be authenticated based on their domain ACP neighbors need to be authenticated based on their domain
certificate. This implies that any secure channel protocol MUST certificate. This implies that any secure channel protocol MUST
support certificate based authentication that can support the ACP support certificate based authentication that can support the ACP
domain membership check as defined in Section 6.1.2. If it fails, domain membership check as defined in Section 6.1.2. If it fails,
the connection attempt is aborted and an error logged. Attempts to the connection attempt is aborted and an error logged. Attempts to
reconnect MUST be throttled. The RECOMMENDED default is exponential reconnect MUST be throttled. The RECOMMENDED default is exponential
backoff with a minimum delay of 10 seconds and a maximum delay of 640 base 2 backoff with a minimum delay of 10 seconds and a maximum delay
seconds. of 640 seconds.
6.7. Security Association protocols 6.7. Security Association protocols
The following sections define the security association protocols that The following sections define the security association protocols that
we consider to be important and feasible to specify in this document: we consider to be important and feasible to specify in this document:
6.7.1. ACP via IKEv2 6.7.1. ACP via IKEv2
An ACP node announces its ability to support IKEv2 as the ACP secure An ACP node announces its ability to support IKEv2 as the ACP secure
channel protocol in GRASP as "IKEv2". channel protocol in GRASP as "IKEv2".
6.7.1.1. Native IPsec 6.7.1.1. Native IPsec
To run ACP via IPsec natively, no further IANA assignments/ To run ACP via IPsec natively, no further IANA assignments/
definitions are required. An ACP node that is supporting native definitions are required. An ACP node that is supporting native
IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and
peer link-local IPv6 addresses used for encapsulation. It MUST then peer link-local IPv6 addresses used for encapsulation. It MUST then
support ESP with AES256 for encryption and SHA256 hash and MUST NOT support ESP with AES-256-GCM ([RFC4106]) for encryption and SHA256
permit weaker crypto options. hash and MUST NOT permit weaker crypto options. Key establishment
MUST support ECDHE with P-256.
In terms of IKEv2, this means the initiator will offer to support In terms of IKEv2, this means the initiator will offer to support
IPsec tunnel mode with next protocol equal 41 (IPv6). IPsec tunnel mode with next protocol equal to 41 (IPv6).
IPsec tunnel mode is required because the ACP will route/forward IPsec tunnel mode is required because the ACP will route/forward
packets received from any other ACP node across the ACP secure packets received from any other ACP node across the ACP secure
channels, and not only its own generated ACP packets. With IPsec channels, and not only its own generated ACP packets. With IPsec
transport mode, it would only be possible to send packets originated transport mode, it would only be possible to send packets originated
by the ACP node itself. by the ACP node itself.
ESP is used because ACP mandates the use of encryption for ACP secure ESP is used because ACP mandates the use of encryption for ACP secure
channels. channels.
skipping to change at page 37, line 8 skipping to change at page 40, line 38
ESP is used because ACP mandates the use of encryption for ACP secure ESP is used because ACP mandates the use of encryption for ACP secure
channels. channels.
In terms of IKEv2 negotiation, this means the initiator must offer to In terms of IKEv2 negotiation, this means the initiator must offer to
support IPsec transport mode with next protocol equal to GRE (47) support IPsec transport mode with next protocol equal to GRE (47)
followed by the offer for native IPsec as described above (because followed by the offer for native IPsec as described above (because
that option is mandatory to support). that option is mandatory to support).
If IKEv2 initiator and responder support GRE, it will be selected. If IKEv2 initiator and responder support GRE, it will be selected.
The version of GRE to be used must the according to [RFC7676]. The version of GRE to be used must be determined according to
[RFC7676].
6.7.2. ACP via DTLS 6.7.2. ACP via DTLS
We define the use of ACP via DTLS in the assumption that it is likely We define the use of ACP via DTLS in the assumption that it is likely
the first transport encryption code basis supported in some classes the first transport encryption code basis supported in some classes
of constrained devices. of constrained devices.
To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP To run ACP via UDP and DTLS v1.2 [RFC6347] a locally assigned UDP
port is used that is announced as a parameter in the GRASP AN_ACP port is used that is announced as a parameter in the GRASP AN_ACP
objective to candidate neighbors. All ACP nodes supporting DTLS as a objective to candidate neighbors.
secure channel protocol MUST support AES256 encryption and MUST NOT
permit weaker crypto options. All ACP nodes supporting DTLS as a secure channel protocol MUST
adhere to the DTLS implementation recommendations and security
considerations of [RFC7525] except with respect to the DTLS version.
ACP nodes supporting DTLS MUST implement only DTLS 1.2 or later. For
example, implementing DTLS-1.3 ([I-D.ietf-tls-dtls13]) is also an
option.
There is no additional session setup or other security association There is no additional session setup or other security association
besides this simple DTLS setup. As soon as the DTLS session is besides this simple DTLS setup. As soon as the DTLS session is
functional, the ACP peers will exchange ACP IPv6 packets as the functional, the ACP peers will exchange ACP IPv6 packets as the
payload of the DTLS transport connection. Any DTLS defined security payload of the DTLS transport connection. Any DTLS defined security
association mechanisms such as re-keying are used as they would be association mechanisms such as re-keying are used as they would be
for any transport application relying solely on DTLS. for any transport application relying solely on DTLS.
6.7.3. ACP Secure Channel Requirements 6.7.3. ACP Secure Channel Requirements
skipping to change at page 37, line 42 skipping to change at page 41, line 29
secure channel mechanism mandated for all ACP nodes. Instead, this secure channel mechanism mandated for all ACP nodes. Instead, this
section defines two ACP profiles (baseline and constrained) for ACP section defines two ACP profiles (baseline and constrained) for ACP
nodes that do introduce such requirements. nodes that do introduce such requirements.
A baseline ACP node MUST support IPsec natively and MAY support IPsec A baseline ACP node MUST support IPsec natively and MAY support IPsec
via GRE. A constrained ACP node that cannot support IPsec MUST via GRE. A constrained ACP node that cannot support IPsec MUST
support DTLS. An ACP node connecting an area of constrained ACP support DTLS. An ACP node connecting an area of constrained ACP
nodes with an area of baseline ACP nodes MUST therefore support IPsec nodes with an area of baseline ACP nodes MUST therefore support IPsec
and DTLS and supports therefore the baseline and constrained profile. and DTLS and supports therefore the baseline and constrained profile.
Explanation: Not all type of ACP nodes can or need to connect
directly to each other or are able to support or prefer all possible
secure channel mechanisms. For example, code space limited IoT
devices may only support DTLS because that code exists already on
them for end-to-end security, but high-end core routers may not want
to support DTLS because they can perform IPsec in accelerated
hardware but would need to support DTLS in an underpowered CPU
forwarding path shared with critical control plane operations. This
is not a deployment issue for a single ACP across these type of nodes
as long as there are also appropriate gateway ACP nodes that support
sufficiently many secure channel mechanisms to allow interconnecting
areas of ACP nodes with a more constrained set of secure channel
protocols. On the edge between IoT areas and high-end core networks,
general-purpose routers that act as those gateways and that can
support a variety of secure channel protocols is the norm already.
ACP nodes need to specify in documentation the set of secure ACP ACP nodes need to specify in documentation the set of secure ACP
mechanisms they support and should declare which profile they support mechanisms they support and should declare which profile they support
according to above requirements. according to above requirements.
An ACP secure channel MUST immediately be terminated when the An ACP secure channel MUST immediately be terminated when the
lifetime of any certificate in the chain used to authenticate the lifetime of any certificate in the chain used to authenticate the
neighbor expires or becomes revoked. Note that this is not standard neighbor expires or becomes revoked. Note that this is not standard
behavior in secure channel protocols such as IPsec because the behavior in secure channel protocols such as IPsec because the
certificate authentication only influences the setup of the secure certificate authentication only influences the setup of the secure
channel in these protocols. channel in these protocols.
skipping to change at page 39, line 36 skipping to change at page 44, line 36
............................................................... ...............................................................
. | | | ^^^ Users of ACP (GRASP/ASA) . . | | | ^^^ Users of ACP (GRASP/ASA) .
. | | | ACP interfaces/addressing . . | | | ACP interfaces/addressing .
. | | | . . | | | .
. | | | A . | | | A
. | ACP-Loopback Interf.| <- ACP Loopback interface C . | ACP-Loopback Interf.| <- ACP Loopback interface C
. | ACP-address | - address (global ULA) P . | ACP-address | - address (global ULA) P
. subnet1 | subnet2 <- ACP virtual interfaces . . subnet1 | subnet2 <- ACP virtual interfaces .
. link-local | link-local - link-local addresses . . link-local | link-local - link-local addresses .
............................................................... ...............................................................
. | | | ACP routing and forwarding . . | | | ACP VRF .
. | RPL-routing | . . | RPL-routing | virtual routing and forwarding .
. | /IP-Forwarding\ | A . | /IP-Forwarding\ | A
. | / \ | C . | / \ | C
. ACP IPv6 packets ACP IPv6 packets P . ACP IPv6 packets ACP IPv6 packets P
. |/ \| . . |/ \| .
. IPsec/DTLS IPsec/DTLS - ACP-cert auth . . IPsec/DTLS IPsec/DTLS - ACP-cert auth .
............................................................... ...............................................................
| | Data-Plane | | Data-Plane
| | | |
| | - ACP secure channel | | - ACP secure channel
link-local link-local - encapsulation addresses link-local link-local - encapsulation addresses
subnet1 subnet2 - Data-Plane interfaces subnet1 subnet2 - Data-Plane interfaces
| | | |
ACP-Nbr1 ACP-Nbr2 ACP-Nbr1 ACP-Nbr2
Figure 7: ACP as security and transport substrate for GRASP Figure 8: ACP as security and transport substrate for GRASP
GRASP unicast messages inside the ACP always use the ACP address. GRASP unicast messages inside the ACP always use the ACP address.
Link-local ACP addresses must not be used inside objectives. GRASP Link-local addresses from the ACP VRF must not be used inside
unicast messages inside the ACP are transported via TLS 1.2 objectives. GRASP unicast messages inside the ACP are transported
([RFC5246]) connections with AES256 encryption and SHA256. Mutual via TLS 1.2 ([RFC5246]) connections with AES256 encryption and
authentication uses the ACP domain membership check defined in SHA256. Mutual authentication uses the ACP domain membership check
(Section 6.1.2). defined in (Section 6.1.2).
GRASP link-local multicast messages are targeted for a specific ACP GRASP link-local multicast messages are targeted for a specific ACP
virtual interface (as defined Section 6.12.5) but are sent by the ACP virtual interface (as defined Section 6.12.5) but are sent by the ACP
into an ACP GRASP virtual interface that is constructed from the TCP into an ACP GRASP virtual interface that is constructed from the TCP
connection(s) to the IPv6 link-local neighbor address(es) on the connection(s) to the IPv6 link-local neighbor address(es) on the
underlying ACP virtual interface. If the ACP GRASP virtual interface underlying ACP virtual interface. If the ACP GRASP virtual interface
has two or more neighbors, the GRASP link-local multicast messages has two or more neighbors, the GRASP link-local multicast messages
are replicated to all neighbor TCP connections. are replicated to all neighbor TCP connections.
TLS and TLS connections for GRASP in the ACP use the IANA assigned TCP and TLS connections for GRASP in the ACP use the IANA assigned
TCP port for GRASP (7107). Effectively the transport stack is TCP port for GRASP (7107). Effectively the transport stack is
expected to be TLS for connections from/to the ACP address (e.g., expected to be TLS for connections from/to the ACP address (e.g.,
global scope address(es)) and TCP for connections from/to link-local global scope address(es)) and TCP for connections from/to link-local
addresses on the ACP virtual interfaces. The latter ones are only addresses on the ACP virtual interfaces. The latter ones are only
used for flooding of GRASP messages. used for flooding of GRASP messages.
6.8.2.1. Discussion 6.8.2.1. Discussion
TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local
messages is used because these messages are flooded across messages is used because these messages are flooded across
skipping to change at page 43, line 9 skipping to change at page 48, line 9
o No external connectivity: They do not provide access to the o No external connectivity: They do not provide access to the
Internet. If a node requires further reaching connectivity, it Internet. If a node requires further reaching connectivity, it
should use another, traditionally managed address scheme in should use another, traditionally managed address scheme in
parallel. parallel.
o Addresses in the ACP are permanent, and do not support temporary o Addresses in the ACP are permanent, and do not support temporary
addresses as defined in [RFC4941]. addresses as defined in [RFC4941].
o Addresses in the ACP are not considered sensitive on privacy o Addresses in the ACP are not considered sensitive on privacy
grounds because ACP nodes are not expected to be end-user devices. grounds because ACP nodes are not expected to be end-user host.
Therefore, ACP addresses do not need to be pseudo-random as All ACP nodes are in one (potentially federated) administrative
discussed in [RFC7721]. Because they are not propagated to domain. They are assumed to be to be candidate hosts of ACP
untrusted (non ACP) nodes and stay within a domain (of trust), we traffic amongst each other or transit thereof. There are no
also consider them not to be subject to scanning attacks. transit nodes less privileged to know about the identity of other
hosts in the ACP. Therefore, ACP addresses do not need to be
pseudo-random as discussed in [RFC7721]. Because they are not
propagated to untrusted (non ACP) nodes and stay within a domain
(of trust), we also consider them not to be subject to scanning
attacks.
The ACP is based exclusively on IPv6 addressing, for a variety of The ACP is based exclusively on IPv6 addressing, for a variety of
reasons: reasons:
o Simplicity, reliability and scale: If other network layer o Simplicity, reliability and scale: If other network layer
protocols were supported, each would have to have its own set of protocols were supported, each would have to have its own set of
security associations, routing table and process, etc. security associations, routing table and process, etc.
o Autonomic functions do not require IPv4: Autonomic functions and o Autonomic functions do not require IPv4: Autonomic functions and
autonomic service agents are new concepts. They can be autonomic service agents are new concepts. They can be
skipping to change at page 43, line 42 skipping to change at page 48, line 47
6.10.2. The ACP Addressing Base Scheme 6.10.2. The ACP Addressing Base Scheme
The Base ULA addressing scheme for ACP nodes has the following The Base ULA addressing scheme for ACP nodes has the following
format: format:
8 40 2 78 8 40 2 78
+--+-------------------------+------+------------------------------+ +--+-------------------------+------+------------------------------+
|fd| hash(routing-subdomain) | Type | (sub-scheme) | |fd| hash(routing-subdomain) | Type | (sub-scheme) |
+--+-------------------------+------+------------------------------+ +--+-------------------------+------+------------------------------+
Figure 8: ACP Addressing Base Scheme Figure 9: ACP Addressing Base Scheme
The first 48-bits follow the ULA scheme, as defined in [RFC4193], to The first 48-bits follow the ULA scheme, as defined in [RFC4193], to
which a type field is added: which a type field is added:
o "fd" identifies a locally defined ULA address. o "fd" identifies a locally defined ULA address.
o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP o The 40-bits ULA "global ID" (term from [RFC4193]) for ACP
addresses carried in the domain information field of domain addresses carried in the domain information field of domain
certificates are the first 40-bits of the SHA256 hash of the certificates are the first 40-bits of the SHA256 hash of the
routing subdomain from the same domain information field. In the routing subdomain from the same domain information field. In the
example of Section 6.1.1, the routing subdomain is example of Section 6.1.1, the routing subdomain is
"area51.research.acp.example.com" and the 40-bits ULA "global ID" "area51.research.acp.example.com" and the 40-bits ULA "global ID"
89b714f3db. 89b714f3db.
o When creating a new routing-subdomain for an existing autonomic
network, it MUST be ensured, that rsub is selected so the
resulting hash of the routing-subdomain does not collide with the
hash of any pre-existing routing-subdomains of the autonomic
network. This ensures that ACP addresses created by registrars
for different routing subdomains do not collide with each others.
o To allow for extensibility, the fact that the ULA "global ID" is a o To allow for extensibility, the fact that the ULA "global ID" is a
hash of the routing subdomain SHOULD NOT be assumed by any ACP hash of the routing subdomain SHOULD NOT be assumed by any ACP
node during normal operations. The hash function is only executed node during normal operations. The hash function is only executed
during the creation of the certificate. If BRSKI is used then the during the creation of the certificate. If BRSKI is used then the
BRSKI registrar will create the domain information field in BRSKI registrar will create the domain information field in
response to the EST Certificate Signing Request (CSR) Attribute response to the EST Certificate Signing Request (CSR) Attribute
Request message by the pledge. Request message by the pledge.
o Establishing connectivity between different ACP (different acp-
domain-name) is outside the scope of this specification. If it is
being done through future extensions, then the rsub of all
routing-subdomains across those autonomic networks need to be
selected so their hashes do not collide. For example a large
cooperation with its own private Trust Anchor may want to create
different autonomic networks that initially should not be able to
connect but where the option to do so should be kept open. When
taking this future possibility into account, it is easy to always
select rsub so that no collisions happen.
o Type: This field allows different address sub-schemes. This o Type: This field allows different address sub-schemes. This
addresses the "upgradability" requirement. Assignment of types addresses the "upgradability" requirement. Assignment of types
for this field will be maintained by IANA. for this field will be maintained by IANA.
The sub-scheme may imply a range or set of addresses assigned to the The sub-scheme may imply a range or set of addresses assigned to the
node, this is called the ACP address range/set and explained in each node, this is called the ACP address range/set and explained in each
sub-scheme. sub-scheme.
Please refer to Section 6.10.7 and Appendix A.1 for further Please refer to Section 6.10.7 and Appendix A.1 for further
explanations why the following Sub-Addressing schemes are used and explanations why the following Sub-Addressing schemes are used and
skipping to change at page 44, line 40 skipping to change at page 50, line 17
The sub-scheme defined here is defined by the Type value 00b (zero) The sub-scheme defined here is defined by the Type value 00b (zero)
in the base scheme and 0 in the Z bit. in the base scheme and 0 in the Z bit.
64 64 64 64
+-----------------+---+---------++-----------------------------+---+ +-----------------+---+---------++-----------------------------+---+
| (base scheme) | Z | Zone-ID || Node-ID | | (base scheme) | Z | Zone-ID || Node-ID |
| | | || Registrar-ID | Node-Number| V | | | | || Registrar-ID | Node-Number| V |
+-----------------+---+---------++--------------+--------------+---+ +-----------------+---+---------++--------------+--------------+---+
50 1 13 48 15 1 50 1 13 48 15 1
Figure 9: ACP Zone Addressing Sub-Scheme Figure 10: ACP Zone Addressing Sub-Scheme
The fields are defined as follows: The fields are defined as follows:
o Zone-ID: If set to all zero bits: The Node-ID bits are used as an o Zone-ID: If set to all zero bits: The Node-ID bits are used as an
identifier (as opposed to a locator). This results in a non- identifier (as opposed to a locator). This results in a non-
hierarchical, flat addressing scheme. Any other value indicates a hierarchical, flat addressing scheme. Any other value indicates a
zone. See Section 6.10.3.1 on how this field is used in detail. zone. See Section 6.10.3.1 on how this field is used in detail.
o Z: MUST be 0. o Z: MUST be 0.
skipping to change at page 46, line 30 skipping to change at page 51, line 50
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 (see Appendix A.10.1) that it is part of a zone, it If a node learns (see Appendix A.10.1) that it is part of a zone, it
MUST also respond to its ACP address with that Zone-ID. In this case MUST also respond to its ACP address with that Zone-ID. In this case
the ACP Loopback is configured with two ACP addresses: One for Zone- the ACP Loopback is configured with two ACP addresses: One for Zone-
ID = 0 and one for the assigned Zone-ID. This method allows for a ID = 0 and one for the assigned Zone-ID. This method allows for a
smooth transition between a flat addressing scheme and a hierarchical smooth transition between a flat addressing scheme and a 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 use that Zone-ID != 0 address in
address in GRASP locator fields. This eliminates the use of the GRASP locator fields. This eliminates the use of the identifier
identifier address (Zone-ID = 0) in forwarding and the need for address (Zone-ID = 0) in forwarding and the need for network wide
network wide reachability of those non-aggregable identifier reachability of those non-aggregable identifier addresses. Zone-ID
addresses. Zone-ID != 0 addresses are assumed to be aggregable in != 0 addresses are assumed to be aggregable in routing/forwarding
routing/forwarding based on how they are allocated in the ACP based on how they are allocated in the ACP topology.
topology.
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. 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
skipping to change at page 47, line 16 skipping to change at page 52, line 32
The sub-scheme defined here is defined by the Type value 00b (zero) The sub-scheme defined here is defined by the Type value 00b (zero)
in the base scheme and 1 in the Z bit. in the base scheme and 1 in the Z bit.
64 64 64 64
+---------------------+---+----------++-----------------------------+ +---------------------+---+----------++-----------------------------+
| (base scheme) | Z | Subnet-ID|| Interface Identifier | | (base scheme) | Z | Subnet-ID|| Interface Identifier |
+---------------------+---+----------++-----------------------------+ +---------------------+---+----------++-----------------------------+
50 1 13 50 1 13
Figure 10: ACP Manual Addressing Sub-Scheme Figure 11: ACP Manual Addressing Sub-Scheme
The fields are defined as follows: The fields are defined as follows:
o Subnet-ID: Configured subnet identifier. o Subnet-ID: Configured subnet identifier.
o Z: MUST be 1. o Z: MUST be 1.
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
skipping to change at page 48, line 23 skipping to change at page 53, line 41
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 |
+---------------------++--------------+--------------+----------+ +---------------------++--------------+--------------+----------+
50 46 24/16 8/16 50 46 24/16 8/16
Figure 11: ACP Vlong Addressing Sub-Scheme Figure 12: ACP Vlong Addressing Sub-Scheme
This addressing scheme foregoes the Zone-ID field to allow for This addressing scheme foregoes the Zone-ID field to allow for
larger, flatter routed networks (e.g., as in IoT) with 8421376 Node- larger, flatter routed networks (e.g., as in IoT) with 8421376 Node-
Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536) Numbers (2^23+2^15). It also allows for up to 2^16 (i.e. 65536)
different virtualized addresses within a node, which could be used to different virtualized addresses within a node, which could be used to
address individual software components in an ACP node. address individual software components in an ACP node.
The fields are the same as in the Zone-ID sub-scheme with the The fields are the same as in the Zone-ID sub-scheme with the
following refinements: following refinements:
o V: Virtualization bit: Values 0 and 1 are assigned in the same way o V: Virtualization field: 8 or 16 bit. Values 0 and 1 are assigned
as in the Zone-ID sub-scheme. in the same way as in the Zone-ID sub-scheme, the other values are
for further use by the node.
o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is
reduced to 46-bits. This still permits the use of the MAC address reduced to 46-bits. This still permits the use of the MAC address
of an ACP registrar by removing the V and U bits from the 48-bits of an ACP registrar by removing the V and U bits from the 48-bits
of a MAC address (those two bits are never unique, so they cannot of a MAC address (those two bits are never unique, so they cannot
be used to distinguish MAC addresses). be used to distinguish MAC addresses).
o If the first bit of the "Node-Number" is "1", then the Node-Number o If the first bit of the "Node-Number" is "1", then the Node-Number
is 16-bit long and the V field is 16-bit long. Otherwise the is 16-bit long and the V field is 16-bit long. Otherwise the
Node-Number is 24-bit long and the V field is 8-bit long. Node-Number is 24-bit long and the V field is 8-bit long.
skipping to change at page 49, line 34 skipping to change at page 55, line 7
uncoordinated allocation of node addresses by reserving bits for the uncoordinated allocation of node addresses by reserving bits for the
registrar-ID field in the address. registrar-ID field in the address.
IANA is asked need to assign a new "type" for each new addressing IANA is asked need to assign a new "type" for each new addressing
sub-scheme. With the current allocations, only 2 more schemes are sub-scheme. With the current allocations, only 2 more schemes are
possible, so the last addressing scheme MUST provide further possible, so the last addressing scheme MUST provide further
extensions (e.g., by reserving bits from it for further extensions). extensions (e.g., by reserving bits from it for further extensions).
6.10.7. ACP Registrars 6.10.7. ACP Registrars
The ACP address prefix is assigned to the ACP node during enrollment/ ACP registrars are responsible to enroll candidate ACP nodes with ACP
provisioning of the ACP domain certificate to the ACP node. It is domain certificates and associated trust point(s). They are also
intended to persist unchanged through the lifetime of the ACP node. responsible that an ACP domain information field is included in the
ACP domain certificate carrying the ACP domain name and the ACP nodes
ACP address prefix. This address prefix is intended to persist
unchanged through the lifetime of the ACP node.
Because of the ACP addressing sub-schemes explained above, ACP nodes Because of the ACP addressing sub-schemes, an ACP domain can have
for a single ACP domain can be enrolled by multiple distributed and multiple distributed ACP registrars that do not need to coordinate
uncoordinated entities called ACP registrars. These ACP registrars for address assignment. ACP registrars can also be sub-CAs, in which
are responsible to enroll ACP domain certificates and associated case they can also assign ACP domain certificates without
trust anchor(s) to candidate ACP nodes and are also responsible that dependencies against a (shared) root-CA (except during renewals of
an ACP domain information field is included in the ACP domain their own certificates).
certificate.
ACP registrars are PKI registration authorities (RA) enhanced with
the handling of the ACP domain certificate specific fields. They
request certificates for ACP nodes from a Certificate Authority
through any appropriate mechanism (out of scope in this document, but
required to be BRSKI for ANI registrars). Only nodes that are
trusted to be compliant with the requirements against registrar
described in this section must be given the necessary credentials to
perform this RA function, such as credentials for the BRSKI
connection to the CA for ANI registrars.
6.10.7.1. Use of BRSKI or other Mechanism/Protocols 6.10.7.1. Use of BRSKI or other Mechanism/Protocols
Any protocols or mechanisms may be used as ACP registrars, as long as Any protocols or mechanisms may be used as ACP registrars, as long as
the resulting ACP certificate and trust anchors allow to perform the the resulting ACP certificate and trust anchors allow to perform the
ACP domain membership described in Section 6.1.2 with other ACP ACP domain membership described in Section 6.1.2 with other ACP
domain members, and meet the ACP addressing requirements for its ACP domain members, and meet the ACP addressing requirements for its ACP
domain information field as described further below in this section. domain information field as described further below in this section.
An ACP registrar could be a person deciding whether to enroll a An ACP registrar could be a person deciding whether to enroll a
skipping to change at page 50, line 46 skipping to change at page 56, line 29
need to be globally unique but only unique across the set of ACP need to be globally unique but only unique across the set of ACP
registrars for an ACP domain, so other means to assign unique registrars for an ACP domain, so other means to assign unique
Registrar-IDs to ACP registrars can be used, such as configuration on Registrar-IDs to ACP registrars can be used, such as configuration on
the ACP registrars. the ACP registrars.
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 domain information field to
Pledge via the EST /csraddrs command (see the 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
skipping to change at page 51, line 48 skipping to change at page 57, line 28
routing to multiple zones, which is outside the scope of this routing to multiple zones, which is outside the scope of this
specification. specification.
ACP registrars that can use the IDevID of a candidate ACP device ACP registrars that can use the IDevID of a candidate ACP device
SHOULD be able to choose the zone vs. Vlong sub-address scheme for SHOULD be able to choose the zone vs. Vlong sub-address scheme for
ACP nodes based on the serialNumber of the IDevID, for example by the ACP nodes based on the serialNumber of the IDevID, for example by the
PID (Product Identifier) part which identifies the product type, or PID (Product Identifier) part which identifies the product type, or
the complete serialNumber. the complete serialNumber.
In a simple allocation scheme, an ACP registrar remembers In a simple allocation scheme, an ACP registrar remembers
persistently across reboots for its currently used Registrar-ID and persistently across reboots its currently used Registrar-ID and for
for each addressing scheme (zone with Subnet-ID 0, Vlong with /112, each addressing scheme (zone with Subnet-ID 0, Vlong with /112, Vlong
Vlong with /120), the next Node-Number available for allocation and with /120), the next Node-Number available for allocation and
increases it after successful enrollment to an ACP node. In this increases it during successful enrollment to an ACP node. In this
simple allocation scheme, the ACP registrar would not recycle ACP simple allocation scheme, the ACP registrar would not recycle ACP
address prefixes from no longer used ACP nodes. address prefixes from no longer used ACP nodes.
6.10.7.4. Address/Prefix Persistence 6.10.7.4. Address/Prefix Persistence
When an ACP domain certificate is renewed or rekeyed via EST or other When an ACP domain certificate is renewed or rekeyed via EST or other
mechanisms, the ACP address/prefix in the ACP domain information mechanisms, the ACP address/prefix in the ACP domain information
field MUST be maintained unless security issues or violations of the field MUST be maintained unless security issues or violations of the
unique address assignment requirements exist or are suspected by the unique address assignment requirements exist or are suspected by the
ACP registrar. Even when the renewing/rekeying ACP registrar is not ACP registrar.
the same as the one that enrolled the prior ACP certificate. See
Section 10.2.4 for an example. ACP address information SHOULD also ACP address information SHOULD be maintained even when the renewing/
be maintained even after an ACP certificate did expire or failed. rekeying ACP registrar is not the same as the one that enrolled the
See Section 6.1.3.5 and Section 6.1.3.6. prior ACP certificate. See Section 10.2.4 for an example.
ACP address information SHOULD also be maintained even after an ACP
certificate did expire or failed. See Section 6.1.4.5 and
Section 6.1.4.6.
6.10.7.5. Further Details 6.10.7.5. Further Details
Section 10.2 discusses further informative details of ACP registrars: Section 10.2 discusses further informative details of ACP registrars:
What interactions registrars need, what parameters they require, What interactions registrars need, what parameters they require,
certificate renewal and limitations, use of sub-CAs on registrars and certificate renewal and limitations, use of sub-CAs on registrars and
centralized policy control. centralized policy control.
6.11. Routing in the ACP 6.11. Routing in the ACP
skipping to change at page 52, line 41 skipping to change at page 58, line 27
for reachability. The use of the autonomic control plane specific for reachability. The use of the autonomic control plane specific
context eliminates the probable clash with Data-Plane routing tables context eliminates the probable clash with Data-Plane routing tables
and also secures the ACP from interference from the configuration and also secures the ACP from interference from the configuration
mismatch or incorrect routing updates. mismatch or incorrect routing updates.
The establishment of the routing plane and its parameters are The establishment of the routing plane and its parameters are
automatic and strictly within the confines of the autonomic control automatic and strictly within the confines of the autonomic control
plane. Therefore, no explicit configuration is required. plane. Therefore, no explicit configuration is required.
All routing updates are automatically secured in transit as the All routing updates are automatically secured in transit as the
channels of the autonomic control plane are by default secured, and channels of the ACP are encrypted, and this routing runs only inside
this routing runs only inside the ACP. the ACP.
The routing protocol inside the ACP is RPL ([RFC6550]). See The routing protocol inside the ACP is RPL ([RFC6550]). See
Appendix A.4 for more details on the choice of RPL. Appendix A.4 for more details on the choice of RPL.
RPL adjacencies are set up across all ACP channels in the same domain RPL adjacencies are set up across all ACP channels in the same domain
including all its routing subdomains. See Appendix A.7 for more including all its routing subdomains. See Appendix A.7 for more
details. details.
6.11.1. 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. Overview
In summary, the profile chosen for RPL is one that expects a fairly The choosen RPL profile is one that expects a fairly reliable network
reliable network with reasonably fast links so that RPL convergence with reasonably fast links so that RPL convergence will be triggered
will be triggered immediately upon recognition of link failure/ immediately upon recognition of link failure/recovery.
recovery.
The key limitation of the chosen profile is that it is designed to The profile is also designed to not require any RPL Data-Plane
not require any Data-Plane artifacts (such as [RFC6553]). While the artifacts (such as defined in [RFC6553]). This is largely driven by
senders/receivers of ACP packets can be legacy NOC devices connected the desire to avoid introducing the required Hop-by-Hop headers into
via ACP connect (see Section 8.1.1 to the ACP, their connectivity can the ACP forwarding plane, especially to support devices with silicon
be handled as non-RPL-aware leafs (or "Internet") according to the forwarding planes that cannot support insertion/removal of these
Data-Plane architecture explained in [I-D.ietf-roll-useofrplinfo]. headers in silicon or hop-by-hop forwarding based on them. Note:
This non-artifact profile is largely driven by the desire to avoid Insertion/removal of headers by a (potentially silicon based) ACP
introducing the required Hop-by-Hop headers into the ACP forwarding node would be be necessary when senders/receivers of ACP packets are
plane, especially to support devices with silicon forwarding planes legacy NOC devices connected via ACP connect (see Section 8.1.1 to
that cannot support insertion/removal of these headers in silicon. the ACP. Their connectivity can be handled in RPL as non-RPL-aware
leafs (or "Internet") according to the Data-Plane architecture
explained in [I-D.ietf-roll-useofrplinfo].
In this profile choice, RPL has no Data-Plane artifacts. A simple To avoid Data-Plane artefacts, the profile uses a simple destination
destination prefix based upon the routing table is used. A prefix based routing/forwarding table. To achieve this, the profiles
consequence of supporting only a single instanceID that is containing uses only one RPL instanceID. This single instanceID can contain
one Destination Oriented Directed Acyclic Graph (DODAG), the ACP will only one Destination Oriented Directed Acyclic Graph (DODAG), and the
only accommodate only a single class of routing table and cannot routing/forwarding table can therefore only calculate a single class
create optimized routing paths to accomplish latency or energy goals. of service ("best effort towards the primary NOC/root") and cannot
create optimized routing paths to accomplish latency or energy goals
between any two nodes.
Consider a network that has multiple NOCs in different locations. Consider a network that has multiple NOCs in different locations.
Only one NOC will become the DODAG root. Other NOCs will have to Only one NOC will become the DODAG root. Traffic to and from other
send traffic through the DODAG (tree) rooted in the primary NOC. NOCs has to be sent through the DODAG (shortest path tree) rooted in
Depending on topology, this can be an annoyance from a latency point the primary NOC. Depending on topology, this can be an annoyance
of view, but it does not represent a single point of failure, as the from a latency point of view or from minimizing network path
DODAG will reconfigure itself when it detects data plane forwarding resources, but this is deemed to be acceptable given how ACP traffic
failures. See Appendix A.10.4 for more details. is "only" network management/control traffic.
Using a single instanceID/DODAG does not introduce a single point of
failure, as the DODAG will reconfigure itself when it detects data-
plane forwarding failures including choosing a different root when
the primary one fails. See Appendix A.10.4 for more details.
The benefit of this profile, especially compared to other IGPs is
that it does not calculate routes for node reachable through the same
interface as the DODAG root. This RPL profile can therefore scale to
much larger number of ACP nodes in the same amount of compute and
memory than other routing protocols. Especially on nodes that are
leafs of the topology or those close to those leafs.
The lack of RPL Packet Information (RPI, the IPv6 header for RPL The lack of RPL Packet Information (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 time-to-live (TTL) of the packet reaches zero. This loop until the time-to-live (TTL) of the packet reaches zero. This
the same behavior as that of other IGPs that do not have the Data- is the same behavior as that of other IGPs that do not have the Data-
Plane options as RPL. Plane options of RPL.
Since links in the ACP are assumed to be mostly reliable (or have Since links in the ACP are assumed to be mostly reliable (or have
link layer protection against loss) and because there is no stretch link layer protection against loss) and because there is no stretch
according to Section 6.11.1.7, loops should be exceedingly rare according to Section 6.11.1.7, loops caused by RPL routing packet
though. loss should be exceedingly rare.
There are a variety of mechanisms possible in RPL to further avoid There are a variety of mechanisms possible in RPL to further avoid
temporary loops: DODAG Information Objects (DIOs) SHOULD be sent temporary loops: DODAG Information Objects (DIOs) SHOULD be sent
2...3 times to inform children when losing the last parent. The 2...3 times to inform children when losing the last parent. The
technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be technique in [RFC6550] section 8.2.2.6. (Detaching) SHOULD be
favored over that in section 8.2.2.5., (Poisoning) because it allows favored over that in section 8.2.2.5., (Poisoning) because it allows
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 them in parallel. (DAO)s to all of them in parallel.
Additionally, failed ACP tunnels will be detected by IKEv2 Dead Peer Additionally, failed ACP tunnels can be quickly discovered the secure
Detection (which can function as a replacement for a Low-power and channel protocol mechanisms such as IKEv2 Dead Peer Detection. This
Lossy Networks' (LLN's) Expected Transmission Count (ETX). A failure can function as a replacement for a Low-power and Lossy Networks'
of an ACP tunnel should signal the RPL control plane to pick a (LLN's) Expected Transmission Count (ETX) feature that is not used in
different parent. this profile. A failure of an ACP tunnel should imediately signal
the RPL control plane to pick a different parent.
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
skipping to change at page 55, line 15 skipping to change at page 61, line 20
rank_factor: Derived from link speed: <= 100Mbps: rank_factor: Derived from link speed: <= 100Mbps:
LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1) LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1)
6.11.1.7. DODAG Repair 6.11.1.7. DODAG Repair
Global Repair: we assume stable links and ranks (metrics), so no need Global Repair: we assume stable links and ranks (metrics), so no need
to periodically rebuild DODAG. DODAG version only incremented under to periodically rebuild DODAG. DODAG version only incremented under
catastrophic events (e.g., administrative action). catastrophic events (e.g., administrative action).
Local Repair: As soon as link breakage is detected, send No-Path DAO Local Repair: As soon as link breakage is detected, send No-Path DAO
for all the targets that where reachable only via this link. As soon for all the targets that were reachable only via this link. As soon
as link repair is detected, validate if this link provides you a as link repair is detected, validate if this link provides you a
better parent. If so, compute your new rank, and send new DIO that better parent. If so, compute your new rank, and send new DIO that
advertises your new rank. Then send a DAO with a new path sequence advertises your new rank. Then send a DAO with a new path sequence
about yourself. about yourself.
stretch_rank: none provided ("not stretched"). stretch_rank: none provided ("not stretched").
Data Path Validation: Not used. Data Path Validation: Not used.
Trickle: Not used. Trickle: Not used.
6.11.1.8. Multicast 6.11.1.8. Multicast
Not used yet but possible because of the selected mode of operations. Not used yet but possible because of the selected mode of operations.
6.11.1.9. Security 6.11.1.9. Security
[RFC6550] security not used, substituted by ACP security. [RFC6550] security not used, substituted by ACP security.
Because the ACP links already include provisions for confidentiality
and integrity protection, their usage at the RPL layer would be
redundant, and so RPL security is not used.
6.11.1.10. P2P communications 6.11.1.10. P2P communications
Not used. Not used.
6.11.1.11. IPv6 address configuration 6.11.1.11. IPv6 address configuration
Every ACP node (RPL node) announces an IPv6 prefix covering the Every ACP node (RPL node) announces an IPv6 prefix covering the
address(es) used in the ACP node. The prefix length depends on the address(es) used in the ACP node. The prefix length depends on the
chosen addressing sub-scheme of the ACP address provisioned into the chosen addressing sub-scheme of the ACP address provisioned into the
certificate of the ACP node, e.g., /127 for Zone Addressing Sub- certificate of the ACP node, e.g., /127 for Zone Addressing Sub-
skipping to change at page 60, line 39 skipping to change at page 66, line 48
ACP GRASP wants to send a link-local GRASP multicast message to Bob ACP GRASP wants to send a link-local GRASP multicast message to Bob
and Carol. If Alice's ACP emulates the LAN as one point-to-point and Carol. If Alice's ACP emulates the LAN as one point-to-point
virtual interface to Bob and one to Carol, The sending applications virtual interface to Bob and one to Carol, The sending applications
itself will send two copies, if Alice's ACP emulates a LAN, GRASP itself will send two copies, if Alice's ACP emulates a LAN, GRASP
will send one packet and the ACP will replicate it. The result is will send one packet and the ACP will replicate it. The result is
the same. The difference happens when Bob and Carol receive their the same. The difference happens when Bob and Carol receive their
packet. If they use ACP point-to-point virtual interfaces, their packet. If they use ACP point-to-point virtual interfaces, their
GRASP instance would forward the packet from Alice to each other as GRASP instance would forward the packet from Alice to each other as
part of the GRASP flooding procedure. These packets are unnecessary part of the GRASP flooding procedure. These packets are unnecessary
and would be discarded by GRASP on receipt as duplicates (by use of and would be discarded by GRASP on receipt as duplicates (by use of
the GRASP Session ID). If Bob and Charlie's ACP would emulate a the GRASP Session ID). If Bob and Carol's ACP would emulate a multi-
multi-access virtual interface, then this would not happen, because access virtual interface, then this would not happen, because GRASPs
GRASPs flooding procedure does not replicate back packets to the flooding procedure does not replicate back packets to the interface
interface that they were received from. that they were received from.
Note that link-local GRASP multicast messages are not sent directly Note that link-local GRASP multicast messages are not sent directly
as IPv6 link-local multicast UDP messages into ACP virtual as IPv6 link-local multicast UDP messages into ACP virtual
interfaces, but instead into ACP GRASP virtual interfaces, that are interfaces, but instead into ACP GRASP virtual interfaces, that are
layered on top of ACP virtual interfaces to add TCP reliability to layered on top of ACP virtual interfaces to add TCP reliability to
link-local multicast GRASP messages. Nevertheless, these ACP GRASP link-local multicast GRASP messages. Nevertheless, these ACP GRASP
virtual interfaces perform the same replication of message and, virtual interfaces perform the same replication of message and,
therefore, result in the same impact on flooding. See Section 6.8.2 therefore, result in the same impact on flooding. See Section 6.8.2
for more details. for more details.
skipping to change at page 61, line 24 skipping to change at page 67, line 33
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)
7.1. Why 7.1. Why (Benefits of ACP on L2 switches)
ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2
.../ \ \ ... .../ \ \ ...
ANrtrM ------ \ ------- ANrtrN ANrtrM ------ \ ------- ANrtrN
ANswitchM ... ANswitchM ...
Figure 12: Topology with L2 ACP switches Figure 13: Topology with L2 ACP switches
Consider a large L2 LAN with ANrtr1...ANrtrN connected via some Consider a large L2 LAN with ANrtr1...ANrtrN connected via some
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
skipping to change at page 63, line 51 skipping to change at page 70, line 10
In devices without such a mix of L2 port/interfaces and L3 interfaces In devices without such a mix of L2 port/interfaces and L3 interfaces
(to terminate any transport layer connections), implementation (to terminate any transport layer connections), implementation
details will differ. Logically most simply every L2 port is details will differ. Logically most simply every L2 port is
considered and used as a separate L3 subnet for all ACP operations. considered and used as a separate L3 subnet for all ACP operations.
The fact that the ACP only requires IPv6 link-local unicast and The fact that the ACP only requires IPv6 link-local unicast and
multicast should make support for it on any type of L2 devices as multicast should make support for it on any type of L2 devices as
simple as possible. simple as possible.
A generic issue with ACP in L2 switched networks is the interaction A generic issue with ACP in L2 switched networks is the interaction
with the Spanning Tree Protocol. Ideally, the ACP should be built with the Spanning Tree Protocol. Without further L2 enhancements,
also across ports that are blocked in STP so that the ACP does not the ACP would run only across the active STP topology and the ACP
depend on STP and can continue to run unaffected across STP topology would be interrupted and re-converge with STP changes. Ideally, ACP
changes (where re-convergence can be quite slow). The above peering should be built also across ports that are blocked in STP so
described simple implementation options are not sufficient for this. that the ACP does not depend on STP and can continue to run
Instead they would simply have the ACP run across the active STP unaffected across STP topology changes, where re-convergence can be
topology and the ACP would equally be interrupted and re-converge quite slow. The above described simple implementation options are
with STP changes. not sufficient to achieve this.
8. Support for Non-ACP Components (Normative) 8. Support for Non-ACP Components (Normative)
8.1. ACP Connect 8.1. ACP Connect
8.1.1. Non-ACP Controller / NMS system 8.1.1. Non-ACP Controller / NMS system
The Autonomic Control Plane can be used by management systems, such The Autonomic Control Plane can be used by management systems, such
as controllers or network management system (NMS) hosts (henceforth as controllers or network management system (NMS) hosts (henceforth
called simply "NMS hosts"), to connect to devices (or other type of called simply "NMS hosts"), to connect to devices (or other type of
skipping to change at page 64, line 33 skipping to change at page 70, line 40
default access only to trusted, autonomic systems. Therefore, a default access only to trusted, autonomic systems. Therefore, a
traditional, non-ACP NMS system does not have access to the ACP by traditional, non-ACP NMS system does not have access to the ACP by
default, such as any other external node. default, such as any other external node.
If the NMS host is not autonomic, i.e., it does not support autonomic If the NMS host is not autonomic, i.e., it does not support autonomic
negotiation of the ACP, then it can be brought into the ACP by negotiation of the ACP, then it can be brought into the ACP by
explicit configuration. To support connections to adjacent non-ACP explicit configuration. To support connections to adjacent non-ACP
nodes, an ACP node must support "ACP connect" (sometimes also called nodes, an ACP node 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 an interface level configured workaround for
"ACP edge node". With "ACP connect", interfaces on the node can be connection of trusted non-ACP nodes to the ACP. The ACP node on
configured to be put into the ACP VRF. The ACP is then accessible to which ACP connect is configured is called an "ACP edge node". With
other (NOC) systems on such an interface without those systems having ACP connect, the ACP is accessible from those non-ACP nodes (such as
NOC systems) on such an interface without those non-ACP nodes having
to support any ACP discovery or ACP channel setup. This is also to support any ACP discovery or ACP channel setup. This is also
called "native" access to the ACP because to those (NOC) systems the called "native" access to the ACP because to those (NOC) systems the
interface looks like a normal network interface (without any interface looks like a normal network interface (without any
encryption/novel-signaling). encryption/novel-signaling).
Data-Plane "native" (no ACP) Data-Plane "native" (no ACP)
. .
+--------+ +----------------+ . +-------------+ +--------+ +----------------+ . +-------------+
| ACP | |ACP Edge Node | . | | | ACP | |ACP Edge Node | . | |
| Node | | | v | | | Node | | | v | |
skipping to change at page 65, line 23 skipping to change at page 71, line 23
| | . | [ ] | . ^ | || | | . | [ ] | . ^ | ||
+--------+ . +----------------+ . . +-------------+| +--------+ . +----------------+ . . +-------------+|
. . . +-------------+ . . . +-------------+
. . . . . .
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 14: 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
routed inside the ACP. routed inside the ACP.
An ACP connect interface provides exclusively access to only the ACP. An ACP connect interface provides exclusively access to only the ACP.
This is likely insufficient for many NMS hosts. Instead, they would This is likely insufficient for many NMS hosts. Instead, they would
require a second "Data-Plane" interface outside the ACP for require a second "Data-Plane" interface outside the ACP for
connections between the NMS host and administrators, or Internet connections between the NMS host and administrators, or Internet
based services, or for direct access to the Data-Plane. The document based services, or for direct access to the Data-Plane. The document
"Using Autonomic Control Plane for Stable Connectivity of Network "Using Autonomic Control Plane for Stable Connectivity of Network
OAM" [RFC8368] explains in more detail how the ACP can be integrated OAM" [RFC8368] explains in more detail how the ACP can be integrated
in a mixed NOC environment. in a mixed NOC environment.
The ACP connect interface must be (auto-)configured with an IPv6 An ACP connect interface SHOULD use an IPv6 address/prefix from the
address prefix. Is prefix SHOULD be covered by one of the (ULA) ACP Manual Addressing Sub-Scheme (Section 6.10.4), letting the
prefix(es) used in the ACP. If using non-autonomic configuration, it operator configure for example only the Subnet-ID and having the node
SHOULD use the ACP Manual Addressing Sub-Scheme (Section 6.10.4). It automatically assign the remaining part of the prefix/address. It
SHOULD NOT use a prefix that is also routed outside the ACP so that SHOULD NOT use a prefix that is also routed outside the ACP so that
the addresses clearly indicate whether it is used inside the ACP or the addresses clearly indicate whether it is used inside the ACP or
not. not.
The prefix of ACP connect subnets MUST be distributed by the ACP edge The prefix of ACP connect subnets MUST be distributed by the ACP edge
node into the ACP routing protocol (RPL). The NMS hosts MUST connect node into the ACP routing protocol (RPL). The NMS hosts MUST connect
to prefixes in the ACP routing table via its ACP connect interface. to prefixes in the ACP routing table via its ACP connect interface.
In the simple case where the ACP uses only one ULA prefix and all ACP In the simple case where the ACP uses only one ULA prefix and all ACP
connect subnets have prefixes covered by that ULA prefix, NMS hosts connect subnets have prefixes covered by that ULA prefix, NMS hosts
can rely on [RFC6724] - The NMS host will select the ACP connect can rely on [RFC6724] to determine longest match prefix routes
interface because any ACP destination address is best matched by the towards its different interfaces, ACP and data-plane. With RFC6724,
address on the ACP connect interface. If the NMS hosts ACP connect The NMS host will select the ACP connect interface for all addresses
interface uses another prefix or if the ACP uses multiple ULA in the ACP because any ACP destination address is longest matched by
the address on the ACP connect interface. If the NMS hosts ACP
connect interface uses another prefix or if the ACP uses multiple ULA
prefixes, then the NMS hosts require (static) routes towards the ACP prefixes, then the NMS hosts require (static) routes towards the ACP
interface. interface for these prefixes.
ACP Edge Nodes MUST only forward IPv6 packets received from an ACP When an ACP Edge node receives a packet from an ACP connect
connect interface into the ACP that has an IPv6 address from the ACP interface, it MUST only forward it intot he ACP if it has an IPv6
prefix assigned to this interface (sometimes called "RPF filtering"). source address from that interface. This is sometimes called "RPF
This MAY be changed through administrative measures. filtering". 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 (those in physically secure locations such as a deployed with it (those in physically secure locations such as a
NOC). For example, the registrar could disable the ability to enable NOC). For example, the registrar could disable the ability to enable
ACP connect on devices during enrollment and that property could only ACP connect on devices during enrollment and that property could only
be changed through re-enrollment. See also Appendix A.10.5. be changed through re-enrollment. See also Appendix A.10.5.
8.1.2. Software Components 8.1.2. Software Components
skipping to change at page 68, line 22 skipping to change at page 74, line 27
| | | [ACP ]. | . | |+ | | | [ACP ]. | . | |+
| | | .[VRF ] .[VRF ] | v | "ACP address"|| | | | .[VRF ] .[VRF ] | v | "ACP address"||
| +-------+. .[Select].+--------+ "Date Plane || | +-------+. .[Select].+--------+ "Date Plane ||
| | ^ | .[Data ]. | | Address(es)"|| | | ^ | .[Data ]. | | Address(es)"||
| | . | [Plane] | | || | | . | [Plane] | | ||
| | . | [ ] | +--------------+| | | . | [ ] | +--------------+|
+--------+ . +--------------------+ +--------------+ +--------+ . +--------------------+ +--------------+
. .
Data-Plane "native" and + ACP auto-negotiated/encrypted Data-Plane "native" and + ACP auto-negotiated/encrypted
Figure 14: VRF select Figure 15: VRF select
Using two physical and/or virtual subnets (and therefore interfaces) Using two physical and/or virtual subnets (and therefore interfaces)
into NMS Hosts (as per Section 8.1.1) or Software (as per into NMS Hosts (as per Section 8.1.1) or Software (as per
Section 8.1.2) may be seen as additional complexity, for example with Section 8.1.2) may be seen as additional complexity, for example with
legacy NMS Hosts that support only one IP interface. legacy NMS Hosts that support only one IP interface.
To provide a single subnet into both ACP and Data-Plane, the ACP Edge To provide a single subnet into both ACP and Data-Plane, the ACP Edge
node needs to de-multiplex packets from NMS hosts into ACP VRF and node needs to de-multiplex packets from NMS hosts into ACP VRF and
Data-Plane. This is sometimes called "VRF select". If the ACP VRF Data-Plane. This is sometimes called "VRF select". If the ACP VRF
has no overlapping IPv6 addresses with the Data-Plane (as it should), has no overlapping IPv6 addresses with the Data-Plane (it should have
then this function can use the IPv6 Destination address. The problem no overlapping addresses), then this function can use the IPv6
is Source Address Selection on the NMS Host(s) according to RFC6724. Destination address. The problem is Source Address Selection on the
NMS Host(s) according to RFC6724.
Consider the simple case: The ACP uses only one ULA prefix, the ACP Consider the simple case: The ACP uses only one ULA prefix, the ACP
IPv6 prefix for the Combined ACP and Data-Plane interface is covered IPv6 prefix for the Combined ACP and Data-Plane interface is covered
by that ULA prefix. The ACP edge node announces both the ACP IPv6 by that ULA prefix. The ACP edge node announces both the ACP IPv6
prefix and one (or more) prefixes for the Data-Plane. Without prefix and one (or more) prefixes for the Data-Plane. Without
further policy configurations on the NMS Host(s), it may select its further policy configurations on the NMS Host(s), it may select its
ACP address as a source address for Data-Plane ULA destinations ACP address as a source address for Data-Plane ULA destinations
because of Rule 8 of RFC6724. The ACP edge node can pass on the because of Rule 8 of RFC6724. The ACP edge node can pass on the
packet to the Data-Plane, but the ACP source address should not be packet to the Data-Plane, but the ACP source address should not be
used for Data-Plane traffic, and return traffic may fail. used for Data-Plane traffic, and return traffic may fail.
skipping to change at page 70, line 45 skipping to change at page 76, line 51
ABNF. ABNF.
connection = [ method , local-addr, remote-addr, ?pmtu ] connection = [ method , local-addr, remote-addr, ?pmtu ]
method = [ "IKEv2" , ?port ] method = [ "IKEv2" , ?port ]
method //= [ "DTLS", port ] method //= [ "DTLS", port ]
local-addr = [ address , ?vrf ] local-addr = [ address , ?vrf ]
remote-addr = [ address ] remote-addr = [ address ]
address = ("any" | ipv4-address | ipv6-address ) address = ("any" | ipv4-address | ipv6-address )
vrf = tstr ; Name of a VRF on this node with local-address vrf = tstr ; Name of a VRF on this node with local-address
Figure 15: Parameters for remote ACP neighbors Figure 16: 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:
skipping to change at page 72, line 36 skipping to change at page 78, line 42
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.
o When any changes happen in the topology, the routing protocol used o When any changes happen in the topology, the routing protocol used
in the ACP will automatically adapt to the changes and will in the ACP will automatically adapt to the changes and will
continue to provide reachability to all nodes. continue to provide reachability to all nodes.
o If the domain certificate of an existing ACP node gets revoked, it o The ACP tracks the validity of peer certificates and tears down
will automatically be denied access to the ACP as its domain ACP secure channels when a peer certificate has expired. When
certificate will be validated against a Certificate Revocation short-lived certificates with lifetimes in the order of OCSP/CRL
List during authentication. Since the revocation check is only refresh times are used, then this allows for removal of invalid
done at the establishment of a new security association, existing peers (whose certificate was not renewed) at similar speeds as
ones are not automatically torn down. If an immediate disconnect when using OCSP/CRL. The same benefit can be achieved when using
is required, existing sessions to a freshly revoked node can be CRL/OCSP, periodically refreshing the revocation information and
re-set. also tearing down ACP secure channels when the peers (long-lived)
certificate is revoked. There is no requirement against ACP
implementations to require this enhancement though to keep the
mandatory implementations simpler.
The ACP can also sustain network partitions and mergers. Practically The ACP can also sustain network partitions and mergers. Practically
all ACP operations are link local, where a network partition has no all ACP operations are link local, where a network partition has no
impact. Nodes authenticate each other using the domain certificates impact. Nodes authenticate each other using the domain certificates
to establish the ACP locally. Addressing inside the ACP remains to establish the ACP locally. Addressing inside the ACP remains
unchanged, and the routing protocol inside both parts of the ACP will unchanged, and the routing protocol inside both parts of the ACP will
lead to two working (although partitioned) ACPs. lead to two working (although partitioned) ACPs.
There are few central dependencies: A certificate revocation list There are few central dependencies: A certificate revocation list
(CRL) may not be available during a network partition; a suitable (CRL) may not be available during a network partition; a suitable
skipping to change at page 73, line 26 skipping to change at page 79, line 33
partition is left with one or more of such ACP registrars, it can partition is left with one or more of such ACP registrars, it can
continue to enroll new candidate ACP nodes as long as the ACP continue to enroll new candidate ACP nodes as long as the ACP
registrars sub-CA certificate does not expire. Because the ACP registrars sub-CA certificate does not expire. Because the ACP
addressing relies on unique Registrar-IDs, a later re-merge of addressing relies on unique Registrar-IDs, a later re-merge of
partitions will also not cause problems with ACP addresses assigned partitions will also not cause problems with ACP addresses assigned
during partitioning. during partitioning.
After a network partition, a re-merge will just establish the After a network partition, a re-merge will just establish the
previous status, certificates can be renewed, the CRL is available, previous status, certificates can be renewed, the CRL is available,
and new nodes can be enrolled everywhere. Since all nodes use the and new nodes can be enrolled everywhere. Since all nodes use the
same trust anchor, a re-merge will be smooth. same trust anchor(s), a re-merge will be smooth.
Merging two networks with different trust anchors requires the trust Merging two networks with different trust anchors requires the ACP
anchors to mutually trust each other (for example, by cross-signing). nodes to trust the union of Trust Anchors. As long as the routing-
As long as the domain names are different, the addressing will not subdomain hashes are different, the addressing will not overlap,
overlap (see Section 6.10). except for the low probability of a 40-bit hash collision in SHA256
(see Section 6.10). Note that the complete mechanisms to merge
networks is out of scope of this specification.
It is also highly desirable for implementation of the ACP to be able It is also highly desirable for implementation of the ACP to be able
to run it over interfaces that are administratively down. If this is to run it over interfaces that are administratively down. If this is
not feasible, then it might instead be possible to request explicit not feasible, then it might instead be possible to request explicit
operator override upon administrative actions that would operator override upon administrative actions that would
administratively bring down an interface across which the ACP is administratively bring down an interface across which the ACP is
running. Especially if bringing down the ACP is known to disconnect running. Especially if bringing down the ACP is known to disconnect
the operator from the node. For example any such down administrative the operator from the node. For example any such down administrative
action could perform a dependency check to see if the transport action could perform a dependency check to see if the transport
connection across which this action is performed is affected by the connection across which this action is performed is affected by the
skipping to change at page 74, line 17 skipping to change at page 80, line 26
An attacker will not be able to join the ACP unless having a valid An attacker will not be able to join the ACP unless having a valid
domain certificate, also packet injection and sniffing traffic will domain certificate, also packet injection and sniffing traffic will
not be possible due to the security provided by the encryption not be possible due to the security provided by the encryption
protocol. protocol.
The ACP also serves as protection (through authentication and The ACP also serves as protection (through authentication and
encryption) for protocols relevant to OAM that may not have secured encryption) for protocols relevant to OAM that may not have secured
protocol stack options or where implementation or deployment of those protocol stack options or where implementation or deployment of those
options fail on some vendor/product/customer limitations. This options fail on some vendor/product/customer limitations. This
includes protocols such as SNMP, NTP/PTP, DNS, DHCP, syslog, includes protocols such as SNMP ([RFC3411]), NTP ([RFC5905]), PTP
Radius/Diameter/TACACS, IPFIX/Netflow - just to name a few. ([IEEE-1588-2008]), DNS ([RFC1886]), DHCPv6 ([RFC3315]), syslog
Protection via the ACP secure hop-by-hop channels for these protocols ([RFC3164]), Radius ([RFC2865]), Diameter ([RFC6733]), TACACS
is meant to be only a stopgap though: The ultimate goal is for these ([RFC1492]), IPFIX ([RFC7011]), Netflow ([RFC3954]) - just to name a
and other protocols to use end-to-end encryption utilizing the domain few. Protection via the ACP secure hop-by-hop channels for these
certificate and rely on the ACP secure channels primarily for zero- protocols is meant to be only a stopgap though: The ultimate goal is
touch reliable connectivity, but not primarily for security. for these and other protocols to use end-to-end encryption utilizing
the domain certificate and rely on the ACP secure channels primarily
for zero-touch reliable connectivity, but not primarily for security.
The remaining attack vector would be to attack the underlying ACP The remaining attack vector would be to attack the underlying ACP
protocols themselves, either via directed attacks or by denial-of- protocols themselves, either via directed attacks or by denial-of-
service attacks. However, as the ACP is built using link-local IPv6 service attacks. However, as the ACP is built using link-local IPv6
address, remote attacks are impossible. The ULA addresses are only addresses, remote attacks from the data-plane are impossible as long
as the data-plane has no facilities to remotely sent IPv6 link-local
packets. The only exception are ACP connected interfaces which
require higher physical protection. The ULA addresses are only
reachable inside the ACP context, therefore, unreachable from the reachable inside the ACP context, therefore, unreachable from the
Data-Plane. Also, the ACP protocols should be implemented to be Data-Plane. Also, the ACP protocols should be implemented to be
attack resistant and not consume unnecessary resources even while attack resistant and not consume unnecessary resources even while
under attack. under attack.
9.2.2. From the inside 9.2.2. From the inside
The security model of the ACP is based on trusting all members of the The security model of the ACP is based on trusting all members of the
group of nodes that do receive an ACP domain certificate for the same group of nodes that receive an ACP domain certificate for the same
domain. Attacks from the inside by a compromised group member are domain. Attacks from the inside by a compromised group member are
therefore the biggest challenge. therefore the biggest challenge.
Group members must be protected against attackers so that there is no Group members must be protected against attackers so that there is no
easy way to compromise them, or use them as a proxy for attacking easy way to compromise them, or use them as a proxy for attacking
other devices across the ACP. For example, management plane other devices across the ACP. For example, management plane
functions (transport ports) should only be reachable from the ACP but functions (transport ports) should only be reachable from the ACP but
not the Data-Plane. Especially for those management plane functions not the Data-Plane. Especially for those management plane functions
that have no good protection by themselves because they do not have that have no good protection by themselves because they do not have
secure end-to-end transport and to whom ACP does not only provides secure end-to-end transport and to whom ACP does not only provides
skipping to change at page 75, line 14 skipping to change at page 81, line 27
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).
See Appendix A.10.8 for further considerations how to avoid and deal
with compromised nodes.
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 (intended to be) independent of
scope for configuration errors on the ACP itself. The administrator configuration, there is no scope for configuration errors on the ACP
may have the option to enable or disable the entire approach, but itself. The administrator may have the option to enable or disable
detailed configuration is not possible. This means that the ACP must the entire approach, but detailed configuration is not possible.
not be reflected in the running configuration of nodes, except a This means that the ACP must not be reflected in the running
possible on/off switch. configuration of nodes, except a possible on/off switch (and even
that is undesirable).
While configuration is not possible, an administrator must have full While configuration is not possible, an administrator must have full
visibility of the ACP and all its parameters, to be able to do visibility of the ACP and all its parameters, to be able to do
trouble-shooting. Therefore, an ACP must support all show and debug trouble-shooting. Therefore, an ACP must support all show and debug
options, as for any other network function. Specifically, a network options, as for any other network function. Specifically, a network
management system or controller must be able to discover the ACP, and management system or controller must be able to discover the ACP, and
monitor its health. This visibility of ACP operations must clearly monitor its health. This visibility of ACP operations must clearly
be separated from visibility of Data-Plane so automated systems will be separated from visibility of Data-Plane so automated systems will
never have to deal with ACP aspect unless they explicitly desire to never have to deal with ACP aspect unless they explicitly desire to
do so. do so.
skipping to change at page 78, line 4 skipping to change at page 84, line 20
anchors. anchors.
o If no keying material and ANI is supported/enabled, check the o If no keying material and ANI is supported/enabled, check the
state of BRSKI (not detailed in this example). state of BRSKI (not detailed in this example).
o Check the validity of the domain certificate: o Check the validity of the domain certificate:
* Does the certificate authenticate against the trust anchor? * Does the certificate authenticate against the trust anchor?
* Has it been revoked? * Has it been revoked?
* Was the last scheduled attempt to retrieve a CRL successful * Was the last scheduled attempt to retrieve a CRL successful
(e.g., do we know that our CRL information is up to date). (e.g., do we know that our CRL information is up to date).
* Is the certificate valid: validity start time in the past, * Is the certificate valid: validity start time in the past,
expiration time in the future? expiration time in the future?
* Does the certificate have a correctly formatted ACP information * Does the certificate have a correctly formatted ACP domain
field? information field?
o Was the ACP VRF successfully created? o Was the ACP VRF successfully created?
o Is ACP enabled on one or more interfaces that are up and running? o Is ACP enabled on one or more interfaces that are up and running?
If all this looks good, the ACP should be running locally "fine" - If all this looks good, the ACP should be running locally "fine" -
but we did not check any ACP neighbor relationships. but we did not check any ACP neighbor relationships.
Question: why does the node not create a working ACP connection to a Question: why does the node not create a working ACP connection to a
neighbor on an interface? neighbor on an interface?
skipping to change at page 82, line 47 skipping to change at page 89, line 16
certificate or not, for example based on the devices LDevID as in certificate or not, for example based on the devices LDevID as in
BRSKI. The ACP registrar may have a whitelist or blacklist of BRSKI. The ACP registrar may have a whitelist or blacklist of
devices serialNumbers from their LDevID. devices serialNumbers from their LDevID.
Policies what type of address prefix to assign to a candidate ACP Policies what type of address prefix to assign to a candidate ACP
devices, based on likely the same information. devices, based on likely the same information.
For BRSKI or other mechanisms using vouchers: Parameters to For BRSKI or other mechanisms using vouchers: Parameters to
determine how to retrieve vouchers for specific type of secure determine how to retrieve vouchers for specific type of secure
bootstrap candidate ACP nodes (such as MASA URLs), unless this bootstrap candidate ACP nodes (such as MASA URLs), unless this
information is automatically learned such as from the LDevID of information is automatically learned such as from the IDevID of
candidate ACP nodes (as defined in BRSKI). candidate ACP nodes (as defined in BRSKI).
10.2.3. Certificate renewal and limitations 10.2.3. Certificate renewal and limitations
When an ACP node renews/rekeys its certificate, it may end up doing When an ACP node renews/rekeys its certificate, it may end up doing
so via a different registrar (e.g., EST server) than the one it so via a different registrar (e.g., EST server) than the one it
originally received its ACP domain certificate from, for example originally received its ACP domain certificate from, for example
because that original ACP registrar is gone. The ACP registrar because that original ACP registrar is gone. The ACP registrar
through which the renewal/rekeying is performed would by default through which the renewal/rekeying is performed would by default
trust the ACP domain information from the ACP nodes current ACP trust the ACP domain information from the ACP nodes current ACP
skipping to change at page 83, line 45 skipping to change at page 90, line 15
10.2.4. ACP Registrars with sub-CA 10.2.4. ACP Registrars with sub-CA
In situations, where either of the above two limitations are an In situations, where either of the above two limitations are an
issue, ACP registrars could also be sub-CAs. This removes the need issue, ACP registrars could also be sub-CAs. This removes the need
for connectivity to a root-CA whenever an ACP node is enrolled, and for connectivity to a root-CA whenever an ACP node is enrolled, and
reduces the need for connectivity of such an ACP registrar to a root- reduces the need for connectivity of such an ACP registrar to a root-
CA to only those times when it needs to renew its own certificate. CA to only those times when it needs to renew its own certificate.
The ACP registrar would also now use its own (sub-CA) certificate to The ACP registrar would also now use its own (sub-CA) certificate to
enroll and sign the ACP nodes certificates, and therefore it is only enroll and sign the ACP nodes certificates, and therefore it is only
necessary to revoke a compromised ACP registrars sub-CA certificate. necessary to revoke a compromised ACP registrars sub-CA certificate.
Or let it expire and not renew it, when the certificate of the sub-CA Alternatively one can let it expire and not renew it, when the
is appropriately short-lived. certificate of the sub-CA is appropriately short-lived.
As the ACP domain membership check verifies a peer ACP node's ACP As the ACP domain membership check verifies a peer ACP node's ACP
domain certificate trust chain, it will also verify the signing domain certificate trust chain, it will also verify the signing
certificate which is the compromised/revoked sub-CA certificate. certificate which is the compromised/revoked sub-CA certificate.
Therefore ACP domain membership for an ACP node enrolled from a Therefore ACP domain membership for an ACP node enrolled from a
compromised ACP registrar will fail. compromised and discovered ACP registrar will fail.
ACP nodes enrolled by a compromised ACP registrar would automatically ACP nodes enrolled by a compromised ACP registrar would automatically
fail to establish ACP channels and ACP domain certificate renewal via fail to establish ACP channels and ACP domain certificate renewal via
EST and therefore revert to their role as a candidate ACP members and EST and therefore revert to their role as a candidate ACP members and
attempt to get a new ACP domain certificate from an ACP registrar - attempt to get a new ACP domain certificate from an ACP registrar -
for example, via BRSKI. In result, ACP registrars that have an for example, via BRSKI. In result, ACP registrars that have an
associated sub-CA makes isolating and resolving issues with associated sub-CA makes isolating and resolving issues with
compromised registrars easier. compromised registrars easier.
Note that ACP registrars with sub-CA functionality also can control Note that ACP registrars with sub-CA functionality also can control
skipping to change at page 86, line 40 skipping to change at page 93, line 14
10.3.2.1. Security 10.3.2.1. Security
Interfaces are physically brought down (or left in default down Interfaces are physically brought down (or left in default down
state) as a form of security. "Admin down" state as described above state) as a form of security. "Admin down" state as described above
provides also a high level of security because it only permits ACP/ provides also a high level of security because it only permits ACP/
ANI operations which are both well secured. Ultimately, it is ANI operations which are both well secured. Ultimately, it is
subject to security review for the deployment whether "admin down" is subject to security review for the deployment whether "admin down" is
a feasible replacement for "physical down". a feasible replacement for "physical down".
The need to trust into the security of ACP/ANI operations need to be The need to trust the security of ACP/ANI operations needs to be
weighed against the operational benefits of permitting this: Consider weighed against the operational benefits of permitting this: Consider
the typical example of a CPE (customer premises equipment) with no the typical example of a CPE (customer premises equipment) with no
on-site network expert. User ports are in physical down state unless on-site network expert. User ports are in physical down state unless
explicitly configured not to be. In a misconfiguration situation, explicitly configured not to be. In a misconfiguration situation,
the uplink connection is incorrectly plugged into such a user port. the uplink connection is incorrectly plugged into such as user port.
The device is disconnected from the network and therefore no The device is disconnected from the network and therefore no
diagnostics from the network side is possible anymore. diagnostics from the network side is possible anymore.
Alternatively, all ports default to "admin down". The ACP (but not Alternatively, all ports default to "admin down". The ACP (but not
the Data-Plane) would still automatically form. Diagnostics from the the Data-Plane) would still automatically form. Diagnostics from the
network side is possible and operator reaction could include to network side is possible and operator reaction could include to
either make this port the operational uplink port or to instruct re- either make this port the operational uplink port or to instruct re-
cabling. Security wise, only ACP/ANI could be attacked, all other cabling. Security wise, only ACP/ANI could be attacked, all other
functions are filtered on interfaces in "admin down" state. functions are filtered on interfaces in "admin down" state.
10.3.2.2. Fast state propagation and Diagnostics 10.3.2.2. Fast state propagation and Diagnostics
skipping to change at page 90, line 41 skipping to change at page 97, line 20
only command necessary to create an ACP across a network of only command necessary to create an ACP across a network of
brownfield nodes once all the nodes have a domain certificate. When brownfield nodes once all the nodes have a domain certificate. When
BRSKI is used ("ANI enable"), provisioning of the certificates only BRSKI is used ("ANI enable"), provisioning of the certificates only
requires set-up of a single BRSKI registrar node which could also requires set-up of a single BRSKI registrar node which could also
implement a CA for the network. This is the most simple way to implement a CA for the network. This is the most simple way to
introduce ACP/ANI into existing (== brownfield) networks. introduce ACP/ANI into existing (== brownfield) networks.
The need to explicitly enable ACP/ANI is especially important in The need to explicitly enable ACP/ANI is especially important in
brownfield nodes because otherwise software updates may introduce brownfield nodes because otherwise software updates may introduce
support for ACP/ANI: Automatic enablement of ACP/ANI in networks support for ACP/ANI: Automatic enablement of ACP/ANI in networks
where the operator does not only not want ACP/ANI but where he likely where the operator does not only not want ACP/ANI but where the
never even heard of it could be quite irritating to him. Especially operator likely never even heard of it could be quite irritating to
when "down" behavior is changed to "admin down". the operator. Especially when "down" behavior is changed to "admin
down".
Automatically setting "ANI enable" on brownfield nodes where the Automatically setting "ANI enable" on brownfield nodes where the
operator is unaware of it could also be a critical security issue operator is unaware of it could also be a critical security issue
depending on the vouchers used by BRKSI on these nodes. An attacker depending on the vouchers used by BRKSI on these nodes. An attacker
could claim to be the owner of these devices and create an ACP that could claim to be the owner of these devices and create an ACP that
the attacker has access/control over. In network where the operator the attacker has access/control over. In networks where the operator
explicitly wants to enable the ANI this could not happen, because he explicitly wants to enable the ANI this could not happen, because he
would create a BRSKI registrar that would discover attack attempts. would create a BRSKI registrar that would discover attack attempts.
Nodes requiring "ownership vouchers" would not be subject to that Nodes requiring "ownership vouchers" would not be subject to that
attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more
details. Note that a global "ACP enable" alone is not subject to details. Note that a global "ACP enable" alone is not subject to
these type of attacks, because it always depends on some other these type of attacks, because it always depends on some other
mechanism first to provision domain certificates into the device. mechanism first to provision domain certificates into the device.
10.3.5.2. Greenfield nodes 10.3.5.2. Greenfield nodes
A "greenfield" node is one that did not have any prior configuration. A "greenfield" node is one that did not have any prior configuration.
skipping to change at page 92, line 31 skipping to change at page 99, line 10
Interface level "ACP/ANI enable" control per-interface operations. Interface level "ACP/ANI enable" control per-interface operations.
It is enabled by default on native interfaces and has to be It is enabled by default on native interfaces and has to be
configured explicitly on other interfaces. configured explicitly on other interfaces.
Disabling "ACP/ANI enable" global and per-interface should have Disabling "ACP/ANI enable" global and per-interface should have
additional checks to minimize undesired breakage of ACP. The degree additional checks to minimize undesired breakage of ACP. The degree
of control could be a domain wide parameter in the domain of control could be a domain wide parameter in the domain
certificates. certificates.
10.4. Configuration and the ACP (summary)
There is no desirable configuration for the ACP. Instead, all
parameters that need to be configured in support of the ACP are
limitations of the solution, but they are only needed in cases where
not all components are made autonomic. Whereever this is necessary,
it will rely on pre-existing mechanisms for configuration such as CLI
or YANG ([RFC7950]) data models.
The most important examples of such configuration include:
o When ACP nodes do not support an autonomic way to receive an ACP
domain certificate, for example BRSKI, then such certificate needs
to be configured via some pre-existing mechanisms outside the
scope of this specification. Today, router have typically a
variety of mechanisms to do this.
o Certificate maintenance requires PKI functions. Discovery of
these functions across the ACP is automated (see Section 6.1.4),
but their configuration is is not.
o When non-ACP capable nodes need to be connected to the ACP, the
connecting ACP node needs to be configuration to support this
according to Section 8.1.
o When devices are not autonomically bootstrapped, explicit
configuration to enable the ACP needs to be applied. See
Section 10.3.
o When the ACP needs to be extended across interfacess other than
L2, the ACP as defined in this document can not autodiscover
candidate neighbors automatically. Remove neighbors need to be
configured, see Section 8.2.
Once the ACP is operating, any further configuration for the data-
lane can be configured more reliably across the ACP itself because
the ACP provides addressing and connectivity (routing) independent of
the data-plane itself. For this, the configuration methods simply
need to also allow to operate across the ACP VRF - netconf, ssh or
any other method.
The ACP also provides additional security through its hop-by-hop
encryption for any such configuration operations: Some legacy
configuration methods (SNMP, TFTP, HTTP) may not use end-to-end
encryption, and most of the end-to-end secured configuration methods
still allow for easy passive observation along the path about
configuration taking place (transport flows, port numbers, IP
addresses).
The ACP can and should equally be used as the transport to configure
any of the aforemention non-automic components of the ACP, but in
that case, the same caution needs to be exercised as with data-plane
configuration without ACP: Misconfiguration may cause the configuring
entity to be disconnected from the node it configures - for example
when incorrectly unconfiguring a remote ACP neighbor through which
the configured ACP node is reached.
11. Security Considerations 11. Security Considerations
An ACP is self-protecting and there is no need to apply configuration After seeding an ACP by configuring at least one ACP registrar with
to make it secure. Its security therefore does not depend on routing-subdomain and a CA, an ACP is self-protecting and there is no
configuration. See Section 9.2 for details of how the ACP protects need to apply configuration to make it secure (typically the ACP
Registrar doubles as EST server for certificate renewal). Its
security therefore does not depend on configuration. This does not
include workarounds for non-autonomic components as explained in
Section 8. See Section 9.2 for details of how the ACP protects
itself against attacks from the outside and to a more limited degree itself against attacks from the outside and to a more limited degree
from the inside as well. from the inside as well.
However, the security of the ACP depends on a number of other However, the security of the ACP depends on a number of other
factors: factors:
o The usage of domain certificates depends on a valid supporting PKI o The usage of domain certificates depends on a valid supporting PKI
infrastructure. If the chain of trust of this PKI infrastructure infrastructure. If the chain of trust of this PKI infrastructure
is compromised, the security of the ACP is also compromised. This is compromised, the security of the ACP is also compromised. This
is typically under the control of the network administrator. is typically under the control of the network administrator.
o Every ACP registrar is criticial infrastructure that needs to be
hardened against attacks similar to a CA. A malicious registrar
can enroll enemy plegdes to an ACP network or break ACP routing by
duplicate ACP address assignment to pledges via their ACP domain
certificates.
o Security can be compromised by implementation errors (bugs), as in o Security can be compromised by implementation errors (bugs), as in
all products. all products.
There is no prevention of source-address spoofing inside the ACP. There is no prevention of source-address spoofing inside the ACP.
This implies that if an attacker gains access to the ACP, it can This implies that if an attacker gains access to the ACP, it can
spoof all addresses inside the ACP and fake messages from any other spoof all addresses inside the ACP and fake messages from any other
node. node.
Fundamentally, security depends on correct operation, implementation The ACP It is designed to enable automation of current network
and architecture. Autonomic approaches such as the ACP largely management and future autonomic peer-to-peer/distributed network
eliminate the dependency on correct operation; implementation and automation. Any ACP member can send ACP IPv6 packet to other ACP
architectural mistakes are still possible, as in all networking members and announce via ACP GRASP services to all ACP members
technologies. without depenency against centralized components.
The ACP relies on peer-to-peer authentication and authorization using
ACP certificates. This security model is necessary to enable the
autonomic ad-hoc any-to-any connectivity between ACP nodes. It
provides infrastructure protection through hop by hop authentication
and encryption - without relying on third parties. For any services
where this complete autonomic peer-to-peer group security model is
appropriate, the ACP domain certificate can also be used unchanged.
For example for any type of data-plane routing protocol security.
This ACP security model is designed primarily to protect against
attack from the outside, but not against attacks from the inside. To
protect against spoofing attacks from compromised on-path ACP nodes,
end-to-end encryption inside the ACP is used by new ACP signaling:
GRASP across the ACP using TLS. The same is expected from any non-
legacy services/protocols using the ACP. Because no group-keys are
used, there is no risk for impacted nodes to access end-to-end
encrypted traffic from other ACP nodes.
Attacks from impacted ACP nodes against the ACP are more difficult
than against the data-plane because of the autoconfiguration of the
ACP and the absence of configuration options that could be abused
that allow to change/break ACP behavior. This is excluding
configuration for workaround in support of non-autonomic components.
Mitigation against compromised ACP members is possible through
standard automated certificate management mechanisms including
revocation and non-renewal of short-lived cdrtificates. In this
version of the specification, there are no further optimization of
these mechanisms defined for the ACP (but see Appendix A.10.8).
Higher layer service built using ACP domain certificates should not
solely rely on undifferentiated group security when another model is
more appropriate/more secure. For example central network
configuration relies on a security model where only few especially
trusted nodes are allowed to configure the data-plane of network
nodes (CLIL, Netconf). This can be done through ACP domain
certificates by differentiating them and introduce roles. See
Appendix A.10.5.
Fundamentally, security depends on avoiding operator and network
operations automation mistakes, implementation and architecture.
Autonomic approaches such as the ACP largely eliminate operator
mistakes and make it easier to recover from network operations
mistakes. Implementation and architectural mistakes are still
possible, as in all networking 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
node's 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.4.
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 (Data-Plane) minimizing its dependency against any non-ACP (Data-Plane)
operations/configuration on a node. See also Section 6.12.2. operations/configuration on a node. See also Section 6.12.2.
In combination with BRSKI, ACP enables a resilient, fully zero-touch In combination with BRSKI, ACP enables a resilient, fully zero-touch
network solution for short-lived certificates that can be renewed or network solution for short-lived certificates that can be renewed or
re-enrolled even after unintentional expiry (e.g., because of re-enrolled even after unintentional expiry (e.g., because of
interrupted connectivity). See Appendix A.2. interrupted connectivity). See Appendix A.2.
Because ACP secure channels can be long lived, but certificates used
may be short lived, secure channels, for example built via IPsec need
to be terminated when peer certificates expire. See Section 6.7.3.
The ACP is designed to minimize attacks from the outside by
minimizing its dependency against any non-ACP (Data-Plane)
operations/configuration on a node. See also Section 6.12.2.
12. IANA Considerations 12. IANA Considerations
This document defines the "Autonomic Control Plane". This document defines the "Autonomic Control Plane".
The IANA is requested to register the value "AN_ACP" (without quotes) The IANA is requested to register the value "AN_ACP" (without quotes)
to the GRASP Objectives Names Table in the GRASP Parameter Registry. to the GRASP Objectives Names Table in the GRASP Parameter Registry.
The specification for this value is this document, Section 6.3. The specification for this value is this document, Section 6.3.
The IANA is requested to register the value "SRV.est" (without The IANA is requested to register the value "SRV.est" (without
quotes) to the GRASP Objectives Names Table in the GRASP Parameter quotes) to the GRASP Objectives Names Table in the GRASP Parameter
Registry. The specification for this value is this document, Registry. The specification for this value is this document,
Section 6.1.3. Section 6.1.4.
Note that the objective format "SRV.<service-name>" is intended to be Explanation: This document chooses the initially strange looking
used for any <service-name> that is an [RFC6335] registered service format "SRV.<service-name>" because these objective names would be in
name. This is a proposed update to the GRASP registry subject to line with potential future simplification of the GRASP objective
future work and only mentioned here for informational purposed to registry. Today, every name in the GRASP objective registry needs to
explain the unique format of the objective name. be explicitly allocated with IANA. In the future, this type of
objective names could considered to be automatically registered in
that registry for the same service for which <service-name> is
registered according to [RFC6335]. This explanation is solely
informational and has no impact on the requested registration.
The IANA is requested to create an ACP Parameter Registry with The IANA is requested to create an ACP Parameter Registry with
currently one registry table - the "ACP Address Type" table. currently one registry table - the "ACP Address Type" table.
"ACP Address Type" Table. The value in this table are numeric values "ACP Address Type" Table. The value in this table are numeric values
0...3 paired with a name (string). Future values MUST be assigned 0...3 paired with a name (string). Future values MUST be assigned
using the Standards Action policy defined by [RFC8126]. The using the Standards Action policy defined by [RFC8126]. The
following initial values are assigned by this document: following initial values are assigned by this document:
0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 9) / ACP Manual 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 10) / ACP Manual
Addressing Sub-Scheme (ACP RFC Section 6.10.4) Addressing Sub-Scheme (ACP RFC Section 6.10.4)
1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5)
13. Acknowledgements 13. Acknowledgements
This work originated from an Autonomic Networking project at Cisco This work originated from an Autonomic Networking project at Cisco
Systems, which started in early 2010. Many people contributed to Systems, which started in early 2010. Many people contributed to
this project and the idea of the Autonomic Control Plane, amongst this project and the idea of the Autonomic Control Plane, amongst
which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji
BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Michael
skipping to change at page 99, line 14 skipping to change at page 108, line 22
o Moved ACP channel negotiation from normative section to appendix o Moved ACP channel negotiation from normative section to appendix
because it can in the timeline of this document not be fully because it can in the timeline of this document not be fully
specified to be implementable. Aka: work for future document. specified to be implementable. Aka: work for future document.
That work would also need to include analysing IKEv2 and describin That work would also need to include analysing IKEv2 and describin
the difference of a proposed GRASP/TLS solution to it. the difference of a proposed GRASP/TLS solution to it.
o Removed IANA request to allocate registry for GRASP/TLS. This o Removed IANA request to allocate registry for GRASP/TLS. This
would come with future draft (see above). would come with future draft (see above).
o Gave the name "ACP information field" to the field in the o Gave the name "ACP domain information field" to the field in the
certificate carrying the ACP address and domain name. certificate carrying the ACP address and domain name.
o Changed the rules for mutual authentication of certificates to o Changed the rules for mutual authentication of certificates to
rely on the domain in the ACP information field of the certificate rely on the domain in the ACP information field of the certificate
instead of the OU in the certificate. Also renewed the text instead of the OU in the certificate. Also renewed the text
pointing out that the ACP information field in the certificate is pointing out that the ACP information field in the certificate is
meant to be in a form that it does not disturb other uses of the meant to be in a form that it does not disturb other uses of the
certificate. As long as the ACP expected to rely on a common OU certificate. As long as the ACP expected to rely on a common OU
across all certificates in a domain, this was not really true: across all certificates in a domain, this was not really true:
Other uses of the certificates might require different OUs for Other uses of the certificates might require different OUs for
skipping to change at page 116, line 29 skipping to change at page 125, line 40
Overlooked early SecDir review from frank.xialiang@huawei.com: Overlooked early SecDir review from frank.xialiang@huawei.com:
most issues fixed through other review in -16. Added reference to most issues fixed through other review in -16. Added reference to
self-protection section 9.2 into security considerations section. self-protection section 9.2 into security considerations section.
14.24. draft-ietf-anima-autonomic-control-plane-18 14.24. draft-ietf-anima-autonomic-control-plane-18
Too many word/grammar mistakes in -17. Too many word/grammar mistakes in -17.
14.25. draft-ietf-anima-autonomic-control-plane-19
Review Eric Rescola:
6.1.2 - clarified that we do certificate path validation against
potentially multiple trust anchors.
6.1.3 - Added more comprehensive explanation of Trust Points via new
section 6.1.3.
6.5 - added figure with sequential steps of ACP channel establishment
and Alice and Bob finding their role in the setup.
6.7.x - detailled crypto profiles: AES-256-GCM, ECDHE.
6.7.2 - Referring to RFC7525 as the required crypto profile for DTLS
(taking text from RFC8310 as previously discussed with Eric).
6.7.3 - Added explanation that ACP needs no single MTI secure channel
protocol with example.
6.10.2 - Added requirement that rsub must be choosen so that they
don't create SHA256 collisions. Added explanation how the same could
be done for different ACP networks with same trust anchors but that
this outside the scope of this specification.
6.7.10 - Explains security expectations against ACP registrars: Must
be trusted and then given credentials to act as PKI RA to help
pledges to enroll with an ACP certificate.
9.1 - Added explanations about merging ACP domains requiring both
domains to trust union of Trust Anchors and need to avod ULA hash
collisions.
11 - Added that ACP registrars are critical infrastructure requiring
hardening like CA, mentioning attack impact examples.
11 - Mentioning that ACP requires initial setup of CA and registrar.
11 - long rewrite/extension of group security model and its
implication shared with review from Ben (below).
Many nits fixed.
Review Benjamin Kaduk:
Fixed various nits.
Changed style of MUST/SHOULD in Requirements section to all lower
case to avoid any RFC2119 confusion.
1. clarified support for constrained devices/DTLS: Opportunistic.
1. Clarified ACPs use of two variants of GRASP DULL for neighbor
discovery and ACP grasp for service discovery/clients.
3.2 - amended text explaining what additional security ACP provides
for bootstrap protocols.
6.1.1 - Added note about ASN.1 encoding in the justification for use
of rfc822address.
6.1.2 - Added details how to handle ACP connection when node via
which OCSP/CRL-server is reached fails certificate verification.
12. Rewrote explanation why objective names requested for ACP use
SRV.name.
10.4 - added summary section about ACP and configuration.
Review Eric Rescorla:
6.1.2 - changed peer certificate verification to be certificate path
verification, added lowercase normalizaion comparison to domain name
check.
6.1.2 - explained how domain membership check is authentication and
authorization.
6.1.4.1 - Fixed "objective value" to "objective name".
6.1.4.3 - check IPv6 address of CDP against CDP ACP certificate IPv6
address only if URL uses IPv6 address.
6.10.1 - added more justification why there is no need for privacy
protection of ACP addresses.
6.11.1.1 - thorough fixup of sentences/structure of this RPL overview
section to make it more logical and easier to digest. Also added a
paragraph about the second key benefit of this profile (scalability).
6.11.1.9 - Added explanation about not using RPL security from
Benjamin.
8.1.1 - Fixed up text for address assignment of ACP connect
interfaces. Only recommending manual addressing scheme.
9.1 - changed self-healing benefit text to describe immediate channel
reset for short-lived certificates and describing how the same with
CRL/OCSP is optional.
11. - added note about immediate termination of secure channels after
certificate expiry as this is uncommon today.
11. - rewrote section of security model, attacks and mitigation of
compromised ACP members.
A.24 - clarified the process in which expired certificates are used
for certificate renewal to avvoid higher overhead of -re-enrolment.
A.4 - removed mentioning of RPL trickle because not used by ACP RPL
profile.
A.10.8 - added section discussing how to minimize risk of compromised
nodes, recovering them or kicking them out.
14.26. Open Issues in -19
Need to find good reference for TLS profile for ACP GRASP TLS
connections.
TBD: Add DTLS choice to GRASP secure channel.
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
express CBOR data structures", draft-ietf-cbor-cddl-03 express CBOR and JSON data structures", draft-ietf-cbor-
(work in progress), July 2018. cddl-07 (work in progress), February 2019.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005,
<https://www.rfc-editor.org/info/rfc4106>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
skipping to change at page 118, line 37 skipping to change at page 130, line 33
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676, for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015, DOI 10.17487/RFC7676, October 2015,
<https://www.rfc-editor.org/info/rfc7676>. <https://www.rfc-editor.org/info/rfc7676>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
15.2. Informative References 15.2. Informative References
[AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and [AR8021] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[I-D.eckert-anima-noc-autoconfig]
Eckert, T., "Autoconfiguration of NOC services in ACP
networks via GRASP", draft-eckert-anima-noc-autoconfig-00
(work in progress), July 2018.
[I-D.ietf-acme-star]
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-05 (work in
progress), March 2019.
[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-16 (work in progress), June 2018. keyinfra-18 (work in progress), January 2019.
[I-D.ietf-anima-prefix-management] [I-D.ietf-anima-prefix-management]
Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic
IPv6 Edge Prefix Management in Large-scale Networks", IPv6 Edge Prefix Management in Large-scale Networks",
draft-ietf-anima-prefix-management-07 (work in progress), draft-ietf-anima-prefix-management-07 (work in progress),
December 2017. December 2017.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
and J. Nobre, "A Reference Model for Autonomic and J. Nobre, "A Reference Model for Autonomic
Networking", draft-ietf-anima-reference-model-06 (work in Networking", draft-ietf-anima-reference-model-10 (work in
progress), February 2018. progress), November 2018.
[I-D.ietf-netconf-zerotouch] [I-D.ietf-netconf-zerotouch]
Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero
Provisioning for Networking Devices", draft-ietf-netconf- Touch Provisioning (SZTP)", draft-ietf-netconf-
zerotouch-22 (work in progress), June 2018. zerotouch-29 (work in progress), January 2019.
[I-D.ietf-roll-applicability-template] [I-D.ietf-roll-applicability-template]
Richardson, M., "ROLL Applicability Statement Template", Richardson, M., "ROLL Applicability Statement Template",
draft-ietf-roll-applicability-template-09 (work in draft-ietf-roll-applicability-template-09 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "Using RPL
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- Option Type, Routing Header for Source Routes and IPv6-in-
useofrplinfo-23 (work in progress), May 2018. IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-24 (work in progress), January 2019.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-30 (work in progress),
November 2018.
[IEEE-1588-2008]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
December 2008, <http://standards.ieee.org/findstds/
standard/1588-2008.html>.
[IEEE-802.1X] [IEEE-802.1X]
IEEE SA-Standards Board, "IEEE Standard for Local and Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
Metropolitan Area Networks: Port-Based Network Access Metropolitan Area Networks: Port-Based Network Access
Control", February 2010, Control", February 2010,
<http://standards.ieee.org/findstds/ <http://standards.ieee.org/findstds/
standard/802.1X-2010.html>. standard/802.1X-2010.html>.
[LLDP] IEEE SA-Standards Board, "IEEE Standard for Local and [LLDP] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
Metropolitan Area Networks: Station and Media Access Metropolitan Area Networks: Station and Media Access
Control Connectivity Discovery", June 2016, Control Connectivity Discovery", June 2016,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/802.1AB-2016.html>. standard/802.1AB-2016.html>.
[MACSEC] IEEE SA-Standards Board, "IEEE Standard for Local and [MACSEC] Group, W. -. H. L. L. P. W., "IEEE Standard for Local and
Metropolitan Area Networks: Media Access Control (MAC) Metropolitan Area Networks: Media Access Control (MAC)
Security", June 2006, Security", June 2006,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/802.1AE-2006.html>. standard/802.1AE-2006.html>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989, RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>. <https://www.rfc-editor.org/info/rfc1112>.
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC 1492, DOI 10.17487/RFC1492, July 1993,
<https://www.rfc-editor.org/info/rfc1492>.
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, DOI 10.17487/RFC1886, December 1995,
<https://www.rfc-editor.org/info/rfc1886>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<https://www.rfc-editor.org/info/rfc2315>. <https://www.rfc-editor.org/info/rfc2315>.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, DOI 10.17487/RFC2821, April 2001, RFC 2821, DOI 10.17487/RFC2821, April 2001,
<https://www.rfc-editor.org/info/rfc2821>. <https://www.rfc-editor.org/info/rfc2821>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
DOI 10.17487/RFC3164, August 2001,
<https://www.rfc-editor.org/info/rfc3164>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002,
<https://www.rfc-editor.org/info/rfc3411>.
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export
Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,
<https://www.rfc-editor.org/info/rfc3954>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005, DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>. <https://www.rfc-editor.org/info/rfc4007>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<https://www.rfc-editor.org/info/rfc4210>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>. <https://www.rfc-editor.org/info/rfc4429>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
skipping to change at page 121, line 33 skipping to change at page 135, line 5
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
DOI 10.17487/RFC5790, February 2010, DOI 10.17487/RFC5790, February 2010,
<https://www.rfc-editor.org/info/rfc5790>. <https://www.rfc-editor.org/info/rfc5790>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404, Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014, DOI 10.17487/RFC7404, November 2014,
<https://www.rfc-editor.org/info/rfc7404>. <https://www.rfc-editor.org/info/rfc7404>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
skipping to change at page 125, line 14 skipping to change at page 139, line 5
The use of BRSKI in conjunction with the ACP can also help to further The use of BRSKI in conjunction with the ACP can also help to further
simplify maintenance and renewal of domain certificates. Instead of simplify maintenance and renewal of domain certificates. Instead of
relying on CRL, the lifetime of certificates can be made extremely relying on CRL, the lifetime of certificates can be made extremely
small, for example in the order of hours. When a node fails to small, for example in the order of hours. When a node fails to
connect to the ACP within its certificate lifetime, it cannot connect connect to the ACP within its certificate lifetime, it cannot connect
to the ACP to renew its certificate across it (using just EST), but to the ACP to renew its certificate across it (using just EST), but
it can still renew its certificate as an "enrolled/expired pledge" it can still renew its certificate as an "enrolled/expired pledge"
via the BRSKI bootstrap proxy. This requires only that the BRSKI via the BRSKI bootstrap proxy. This requires only that the BRSKI
registrar honors expired domain certificates and that the pledge registrar honors expired domain certificates and that the pledge
first attempts to perform TLS authentication for BRSKI bootstrap with attempts to perform TLS authentication for BRSKI bootstrap using its
its expired domain certificate - and only reverts to its IDevID when expired domain certificate before falling back to attempting to use
this fails. This mechanism could also render CRLs unnecessary its IDevID for BRSKI. This mechanism could also render CRLs
because the BRSKI registrar in conjunction with the CA would not unnecessary because the BRSKI registrar in conjunction with the CA
renew revoked certificates - only a "Do-not-renew" list would be would not renew revoked certificates - only a "Do-not-renew" list
necessary on BRSKI registrars/CA. would be necessary on BRSKI registrars/CA.
In the absence of BRSKI or less secure variants thereof, provisioning In the absence of BRSKI or less secure variants thereof, provisioning
of certificates may involve one or more touches or non-standardized of certificates may involve one or more touches or non-standardized
automation. Node vendors usually support provisioning of automation. Node vendors usually support provisioning of
certificates into nodes via PKCS#7 (see [RFC2315]) and may support certificates into nodes via PKCS#7 (see [RFC2315]) and may support
this provisioning through vendor specific models via Netconf this provisioning through vendor specific models via Netconf
([RFC6241]). If such nodes also support Netconf Zero-Touch ([RFC6241]). If such nodes also support Netconf Zero-Touch
([I-D.ietf-netconf-zerotouch]) then this can be combined to zero- ([I-D.ietf-netconf-zerotouch]) then this can be combined to zero-
touch provisioning of domain certificates into nodes. Unless there touch provisioning of domain certificates into nodes. Unless there
are equivalent integration of Netconf connections across the ACP as are equivalent integration of Netconf connections across the ACP as
skipping to change at page 127, line 12 skipping to change at page 140, line 51
completely automatically. RPL is a simple, self-managing completely automatically. RPL is a simple, self-managing
protocol, which does not require zones or areas; it is also self- protocol, which does not require zones or areas; it is also self-
configuring, since configuration is carried as part of the configuring, since configuration is carried as part of the
protocol (see Section 6.7.6 of [RFC6550]). protocol (see Section 6.7.6 of [RFC6550]).
o Scale: The ACP builds over an entire domain, which could be a o Scale: The ACP builds over an entire domain, which could be a
large enterprise or service provider network. The routing large enterprise or service provider network. The routing
protocol must therefore support domains of 100,000 nodes or more, protocol must therefore support domains of 100,000 nodes or more,
ideally without the need for zoning or separation into areas. RPL ideally without the need for zoning or separation into areas. RPL
has this scale property. This is based on extensive use of has this scale property. This is based on extensive use of
default routing. RPL also has other scalability improvements, default routing.
such as selecting only a subset of peers instead of all possible
ones, and trickle support for information synchronization.
o Low resource consumption: The ACP supports traditional network o Low resource consumption: The ACP supports traditional network
infrastructure, thus runs in addition to traditional protocols. infrastructure, thus runs in addition to traditional protocols.
The ACP, and specifically the routing protocol must have low The ACP, and specifically the routing protocol must have low
resource consumption both in terms of memory and CPU requirements. resource consumption both in terms of memory and CPU requirements.
Specifically, at edge nodes, where memory and CPU are scarce, Specifically, at edge nodes, where memory and CPU are scarce,
consumption should be minimal. RPL builds a destination-oriented consumption should be minimal. RPL builds a destination-oriented
directed acyclic graph (DODAG), where the main resource directed acyclic graph (DODAG), where the main resource
consumption is at the root of the DODAG. The closer to the edge consumption is at the root of the DODAG. The closer to the edge
of the network, the less state needs to be maintained. This of the network, the less state needs to be maintained. This
skipping to change at page 132, line 25 skipping to change at page 146, line 14
be policies flooded across ACP GRASP and interpreted on every ACP be policies flooded across ACP GRASP and interpreted on every ACP
node. node.
One concern for future definitions of Intent solutions is the problem One concern for future definitions of Intent solutions is the problem
of circular dependencies when expressing Intent policies about the of circular dependencies when expressing Intent policies about the
ACP itself. ACP itself.
For example, Intent could indicate the desire to build an ACP across For example, Intent could indicate the desire to build an ACP across
all domains that have a common parent domain (without relying on the all domains that have a common parent domain (without relying on the
rsub/routing-subdomain solution defined in this document). For rsub/routing-subdomain solution defined in this document). For
example ACP nodes with domain "example.com", nodes of "example.com", example ACP nodes with domain "example.com", "access.example.com",
"access.example.com", "core.example.com" and "city.core.example.com" "core.example.com" and "city.core.example.com" should all establish
should all establish one single ACP. one single ACP.
If each domain has its own source of Intent, then the Intent would If each domain has its own source of Intent, then the Intent would
simply have to allow adding the peer domains trust anchors (CA) and simply have to allow adding the peer domains trust anchors (CA) and
domain names to the ACP domain membership check (Section 6.1.2) so domain names to the ACP domain membership check (Section 6.1.2) so
that nodes from those other domains are accepted as ACP peers. that nodes from those other domains are accepted as ACP peers.
If this Intent was to be originated only from one domain, it could If this Intent was to be originated only from one domain, it could
likely not be made to work because the other domains will not build likely not be made to work because the other domains will not build
any ACP connection amongst each other, whether they use the same or any ACP connection amongst each other, whether they use the same or
different CA due to the ACP domain membership check. different CA due to the ACP domain membership check.
skipping to change at page 134, line 9 skipping to change at page 147, line 47
Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes Data-Plane, but the ACP is the Data-Plane. Add BRSKI, and it becomes
a fully autonomic network - except that it does not support automatic a fully autonomic network - except that it does not support automatic
addressing for user equipment. This gap can then be closed for addressing for user equipment. This gap can then be closed for
example by adding a solution derived from example by adding a solution derived from
[I-D.ietf-anima-prefix-management]. [I-D.ietf-anima-prefix-management].
TCP/TLS as the protocols to provide reliability and security to GRASP TCP/TLS as the protocols to provide reliability and security to GRASP
in the ACP may not be the preferred choice in constrained networks. in the ACP may not be the preferred choice in constrained networks.
For example, CoAP/DTLS (Constrained Application Protocol) may be For example, CoAP/DTLS (Constrained Application Protocol) may be
preferred where they are already used, allowing to reduce the preferred where they are already used, allowing to reduce the
additional code space footprint for the ACP on those devices. additional code space footprint for the ACP on those devices. Hop-
Because the transport for GRASP is not only hop-by-hop, but end-to- by-hop reliability for ACP GRASP messages could be made to support
end across the ACP, this would require the definition of an protocols like DTLS by adding the same type of negotiation as defined
incompatible variant of the ACP. Non-constrained devices could in this document for ACP secure channel protocol negotiation. End-
support both variants (the ACP as defined here, and one using CoAP/ to-end GRASP connections can be made to select their transport
DTLS for GRASP), and the variant used in a deployment could be chosen protocol in future extensions of the ACP meant to better support
for example through a parameter of the domain certificate. constrained devices by indicating the supported transport protocols
(e.g.: TLS/DTLS) via GRASP parameters of the GRASP objective through
which the transport endpoint is discovered.
The routing protocol chosen by the ACP design (RPL) does explicitly The routing protocol chosen by the ACP design (RPL) does explicitly
not optimize for shortest paths and fastest convergence. Variations not optimize for shortest paths and fastest convergence. Variations
of the ACP may want to use a different routing protocol or introduce of the ACP may want to use a different routing protocol or introduce
more advanced RPL profiles. more advanced RPL profiles.
Variations such as what routing protocol to use, or whether to Variations such as what routing protocol to use, or whether to
instantiate an ACP in a VRF or (as suggested above) as the actual instantiate an ACP in a VRF or (as suggested above) as the actual
Data-Plane, can be automatically chosen in implementations built to Data-Plane, can be automatically chosen in implementations built to
support multiple options by deriving them from future parameters in support multiple options by deriving them from future parameters in
skipping to change at page 135, line 16 skipping to change at page 149, line 9
be achieved for example by configuring zone-boundaries, announcing be achieved for example by configuring zone-boundaries, announcing
via GRASP into the zones the zone parameters (zone-ID and /48 ULA via GRASP into the zones the zone parameters (zone-ID and /48 ULA
prefix) and auto-aggegating routes on the zone-boundaries. Nodes prefix) and auto-aggegating routes on the zone-boundaries. Nodes
would assign their Zone-ID and potentially even /48 prefix based on would assign their Zone-ID and potentially even /48 prefix based on
the GRASP announcements. the GRASP announcements.
A.10.2. More options for avoiding IPv6 Data-Plane dependency 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 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 establish IPv6 link-local addressing on interfaces. Using a separate
MAC address for the ACP allows to fully isolate the ACP from the data MAC address for the ACP allows to fully isolate the ACP from the
plane in a way that is compatible with this specification. It is data-plane in a way that is compatible with this specification. It
also an ideal option when using Single-root input/output is also an ideal option when using Single-root input/output
virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single- virtualization (SR-IOV - see https://en.wikipedia.org/wiki/Single-
root_input/output_virtualization [2]) in an implementation to isolate root_input/output_virtualization [2]) in an implementation to isolate
the ACP because different SR-IOV interfaces use different MAC the ACP because different SR-IOV interfaces use different MAC
addresses. addresses.
When additional MAC address(es) are not available, separation of the When additional MAC address(es) are not available, separation of the
ACP could be done at different demux points. The same subnet ACP could be done at different demux points. The same subnet
interface could have a separate IPv6 interface for the ACP and Data- interface could have a separate IPv6 interface for the ACP and Data-
Plane and therefore separate link-local addresses for both, where the Plane and therefore separate link-local addresses for both, where the
ACP interface is non-configurable on the Data-Plane. This too would ACP interface is non-configurable on the Data-Plane. This too would
skipping to change at page 136, line 22 skipping to change at page 150, line 19
ACP1 --------------------------- ACP2 . ACP1 --------------------------- ACP2 .
| | . WAN | | . WAN
| metric 10 metric 20 | . Core | metric 10 metric 20 | . Core
| | . | | .
ACP3 --------------------------- ACP4 . ACP3 --------------------------- ACP4 .
| metric 100 | | metric 100 |
| | . | | .
| | . Sites | | . Sites
ACP10 ACP11 . ACP10 ACP11 .
Figure 16: Dual NOC Figure 17: Dual NOC
The profile for RPL specified in this document builds only one The profile for RPL specified in this document builds only one
spanning-tree path set to a root (NOC). In the presence of multiple spanning-tree path set to a root (NOC). In the presence of multiple
NOCs, routing toward the non-root NOCs may be suboptimal. Figure 16 NOCs, routing toward the non-root NOCs may be suboptimal. Figure 17
shows an extreme example. Assuming that node ACP1 becomes the RPL shows an extreme example. Assuming that node ACP1 becomes the RPL
root, traffic between ACP11 and NOC2 will pass through root, traffic between ACP11 and NOC2 will pass through
ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated
DODAG/routes are shortest paths towards the RPL root. DODAG/routes are shortest paths towards the RPL root.
To overcome these limitations, extensions/modifications to the RPL To overcome these limitations, extensions/modifications to the RPL
profile can provide optimality for multiple NOCs. This requires profile can provide optimality for multiple NOCs. This requires
utilizing Data-Plane artifact including IPinIP encap/decap on ACP utilizing Data-Plane artifact including IPinIP encap/decap on ACP
routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst)
routing table entries could be used. routing table entries could be used.
skipping to change at page 138, line 5 skipping to change at page 151, line 47
2. In alternative to LLDP, A DULL GRASP diagnostics objective could 2. In alternative to LLDP, A DULL GRASP diagnostics objective could
be defined to carry these information elements. be defined to carry these information elements.
3. The IDevID of BRSKI pledges should be included in the selected 3. The IDevID of BRSKI pledges should be included in the selected
insecure diagnostics option. insecure diagnostics option.
4. A richer set of diagnostics information should be made available 4. A richer set of diagnostics information should be made available
via the secured ACP channels, using either single-hop GRASP or via the secured ACP channels, using either single-hop GRASP or
network wide "topology discovery" mechanisms. network wide "topology discovery" mechanisms.
A.10.8. Avoiding and dealing with compromised ACP nodes
Compromised ACP nodes pose the biggest risk to the operations of the
network. The most common type of compromise is leakage of
credentials to manage/configure the device and the application of
malicious configuration including the change of access credentials,
but not the change of software. Most of todays networking equipment
should have secure boot/software infrastructure anyhow, so attacks
that introduce malicious software should be a lot harder.
The most important aspect of security design against these type of
attacks is to eliminate password based configuration access methods
and instead rely on certificate based credentials handed out only to
nodes where it is clear that the private keys can not leak. This
limits unexpected propagation of credentials.
If password based credentials to configure devices still need to be
supported, they must not be locally configurable, but only be
remotely provisioned or verified (through protocols like Radius or
Diameter), and there must be no local configuration permitting to
change these authentication mechanisms, but ideally they should be
autoconfiguring across the ACP. See
[I-D.eckert-anima-noc-autoconfig].
Without physcial access to the compromised device, attackers with
access to configuration should not be able to break the ACP
connectivity, even when they can break or otherwise manipulate
(spoof) the data-plane connectivity through configuration. To
achieve this, it is necessary to avoid providing configuration
options for the ACP, such as enabling/disabling it on interfaces.
For example there could be an ACP configuration that locks down the
current ACP config unless factory reseet is done.
With such means, the valid administration has the best chances to
maintain access to ACP nodes, discover malicious configuration though
ongoing configuration tracking from central locations for example,
and to react accordingly.
The primary reaction is withdrawal/change of credentials, terminate
malicious existing management sessions and fixing the configuration.
Ensuring that manaement sessions using invalidated credentials are
terminated automatically without recourse will likely require new
work.
Only when these steps are not feasible would it be necessary to
revoke or expire the ACP domain certificate credentials and consider
the node kicked off the network - until the situation can be further
rectified, likely requiring direct physical access to the node.
Without extensions, compromised ACP nodes can only be removed from
the ACP at the speed of CRL/OCSP information refresh or expiry (and
non-removal) of short lived certificates. Future extensions to the
ACP could for example use GRASP flooding distribution of triggered
updates of CRL/OCSP or explicit removal indication of the compromised
nodes domain certificate.
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. 167 change blocks. 
526 lines changed or deleted 1172 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/