draft-ietf-anima-autonomic-control-plane-15.txt   draft-ietf-anima-autonomic-control-plane-16.txt 
ANIMA WG T. Eckert, Ed. ANIMA WG T. Eckert, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track M. Behringer, Ed. Intended status: Standards Track M. Behringer, Ed.
Expires: December 8, 2018 Expires: December 10, 2018
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
June 6, 2018 June 8, 2018
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-15 draft-ietf-anima-autonomic-control-plane-16
Abstract Abstract
Autonomic functions need a control plane to communicate, which Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Management depends on some addressing and routing. This Autonomic Management
and Control Plane should ideally be self-managing, and as independent and Control Plane should ideally be self-managing, and as independent
as possible of configuration. This document defines such a plane and as possible of configuration. This document defines such a plane and
calls it the "Autonomic Control Plane", with the primary use as a calls it the "Autonomic Control Plane", with the primary use as a
control plane for autonomic functions. It also serves as a "virtual control plane for autonomic functions. It also serves as a "virtual
out-of-band channel" for Operations Administration and Management out-of-band channel" for Operations Administration and Management
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 8, 2018. This Internet-Draft will expire on December 10, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 7 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 7
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 9 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 9
3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 14 3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 14
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 14 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 14
3.2. Secure Bootstrap over a not configured Network . . . . . 14 3.2. Secure Bootstrap over a not configured Network . . . . . 14
3.3. Data-Plane Independent Permanent Reachability . . . . . . 15 3.3. Data-Plane Independent Permanent Reachability . . . . . . 15
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 18 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 18
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 18 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 19
6.1.1. Certificate Domain Information Field . . . . . . . . 19 6.1.1. Certificate Domain Information Field . . . . . . . . 20
6.1.2. ACP domain membership check . . . . . . . . . . . . . 22 6.1.2. ACP domain membership check . . . . . . . . . . . . . 22
6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 23 6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 23
6.1.3.1. GRASP objective for EST server . . . . . . . . . 23 6.1.3.1. GRASP objective for EST server . . . . . . . . . 23
6.1.3.2. Renewal . . . . . . . . . . . . . . . . . . . . . 24 6.1.3.2. Renewal . . . . . . . . . . . . . . . . . . . . . 25
6.1.3.3. Certificate Revocation Lists (CRLs) . . . . . . . 25 6.1.3.3. Certificate Revocation Lists (CRLs) . . . . . . . 25
6.1.3.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 25 6.1.3.4. Lifetimes . . . . . . . . . . . . . . . . . . . . 26
6.1.3.5. Re-enrollment . . . . . . . . . . . . . . . . . . 26 6.1.3.5. Re-enrollment . . . . . . . . . . . . . . . . . . 26
6.1.3.6. Failing Certificates . . . . . . . . . . . . . . 27 6.1.3.6. Failing Certificates . . . . . . . . . . . . . . 27
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 28 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 28
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 28 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 29
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 31 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 32
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 32 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 32
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 34 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 34
6.7. Security Association protocols . . . . . . . . . . . . . 34 6.7. Security Association protocols . . . . . . . . . . . . . 34
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 34 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 34
6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 34 6.7.1.1. Native IPsec . . . . . . . . . . . . . . . . . . 34
6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 35 6.7.1.2. IPsec with GRE encapsulation . . . . . . . . . . 35
6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 35 6.7.2. ACP via DTLS . . . . . . . . . . . . . . . . . . . . 36
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 36 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 36
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 36 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 36
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 36 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 37
6.8.2. ACP as the Security and Transport substrate for GRASP 37 6.8.2. ACP as the Security and Transport substrate for GRASP 37
6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 39 6.8.2.1. Discussion . . . . . . . . . . . . . . . . . . . 39
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 40 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 40
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 40 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 41
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 41 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 41
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 42 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 42
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 43 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 43
6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 44 6.10.3.1. Usage of the Zone-ID Field . . . . . . . . . . . 45
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 45 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 46
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 47 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 47
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 48 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 48
6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 48 6.10.7. ACP Registrars . . . . . . . . . . . . . . . . . . . 48
6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 48 6.10.7.1. Use of BRSKI or other Mechanism/Protocols . . . 48
6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 49 6.10.7.2. Unique Address/Prefix allocation . . . . . . . . 49
6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 50 6.10.7.3. Addressing Sub-Scheme Policies . . . . . . . . . 50
6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 51 6.10.7.4. Address/Prefix Persistence . . . . . . . . . . . 51
6.10.7.5. Further Details . . . . . . . . . . . . . . . . 51 6.10.7.5. Further Details . . . . . . . . . . . . . . . . 51
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 51 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 51
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 52 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 52
skipping to change at page 4, line 25 skipping to change at page 4, line 25
10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82 10.2.2. Registrar Parameter . . . . . . . . . . . . . . . . 82
10.2.3. Certificate renewal and limitations . . . . . . . . 82 10.2.3. Certificate renewal and limitations . . . . . . . . 82
10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83 10.2.4. ACP Registrars with sub-CA . . . . . . . . . . . . . 83
10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84 10.2.5. Centralized Policy Control . . . . . . . . . . . . . 84
10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 84 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 84
10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 85
10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 85
10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86 10.3.2.1. Security . . . . . . . . . . . . . . . . . . . . 86
10.3.2.2. Fast state propagation and Diagnostics . . . . . 86 10.3.2.2. Fast state propagation and Diagnostics . . . . . 86
10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87 10.3.2.3. Low Level Link Diagnostics . . . . . . . . . . . 87
10.3.2.4. Power Consumption . . . . . . . . . . . . . . . 88 10.3.2.4. Power Consumption Issues . . . . . . . . . . . . 88
10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 88
10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88 10.3.4. Which interfaces to auto-enable? . . . . . . . . . . 88
10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 90
10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90 10.3.5.1. Brownfield nodes . . . . . . . . . . . . . . . . 90
10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91 10.3.5.2. Greenfield nodes . . . . . . . . . . . . . . . . 91
10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 91
10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 92
11. Background and Futures (Informative) . . . . . . . . . . . . 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 92
11.1. ACP Address Space Schemes . . . . . . . . . . . . . . . 92 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93
11.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . 93 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94
11.3. ACP Neighbor discovery protocol selection . . . . . . . 94 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 94
11.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 94 14.1. Initial version . . . . . . . . . . . . . . . . . . . . 94
11.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . 95 14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 95
11.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 95 14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 95
11.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 95 14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 95
11.5. ACP Information Distribution and multicast . . . . . . . 97 14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 95
11.6. Extending ACP channel negotiation (via GRASP) . . . . . 98 14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 96
11.7. CAs, domains and routing subdomains . . . . . . . . . . 100 14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 96
11.8. Adopting ACP concepts for other environments . . . . . . 101 14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 96
12. Security Considerations . . . . . . . . . . . . . . . . . . . 103 14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 97
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104 14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 97
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105 14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 97
15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 105 14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 98
15.1. Initial version . . . . . . . . . . . . . . . . . . . . 105 14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 98
15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 105 14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 100
15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 106 14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 102
15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 106 14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 104
15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 106 14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 105
15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 106 14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 106
15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 107 14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 107
15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 107 14.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 109
15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 108 14.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 113
15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 108 14.22. draft-ietf-anima-autonomic-control-plane-16 . . . . . . 113
15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 108 14.23. wish-list . . . . . . . . . . . . . . . . . . . . . . . 114
15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 109 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 109 15.1. Normative References . . . . . . . . . . . . . . . . . . 115
15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 111 15.2. Informative References . . . . . . . . . . . . . . . . . 117
15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 113 Appendix A. Background and Futures (Informative) . . . . . . . . 121
15.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 115 A.1. ACP Address Space Schemes . . . . . . . . . . . . . . . . 122
15.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 116 A.2. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . . 122
15.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 117 A.3. ACP Neighbor discovery protocol selection . . . . . . . . 123
15.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 118 A.3.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 124
15.20. draft-ietf-anima-autonomic-control-plane-14 . . . . . . 120 A.3.2. mDNS and L2 support . . . . . . . . . . . . . . . . . 124
15.21. draft-ietf-anima-autonomic-control-plane-15 . . . . . . 124 A.3.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 124
15.22. wish-list . . . . . . . . . . . . . . . . . . . . . . . 124 A.4. Choice of routing protocol (RPL) . . . . . . . . . . . . 125
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 125 A.5. ACP Information Distribution and multicast . . . . . . . 126
16.1. Normative References . . . . . . . . . . . . . . . . . . 125 A.6. Extending ACP channel negotiation (via GRASP) . . . . . . 127
16.2. Informative References . . . . . . . . . . . . . . . . . 127 A.7. CAs, domains and routing subdomains . . . . . . . . . . . 129
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 131 A.8. Adopting ACP concepts for other environments . . . . . . 130
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 132
1. Introduction 1. Introduction
Autonomic Networking is a concept of self-management: Autonomic Autonomic Networking is a concept of self-management: Autonomic
functions self-configure, and negotiate parameters and settings functions self-configure, and negotiate parameters and settings
across the network. [RFC7575] defines the fundamental ideas and across the network. [RFC7575] defines the fundamental ideas and
design goals of Autonomic Networking. A gap analysis of Autonomic design goals of Autonomic Networking. A gap analysis of Autonomic
Networking is given in [RFC7576]. The reference architecture for Networking is given in [RFC7576]. The reference architecture for
Autonomic Networking in the IETF is specified in the document Autonomic Networking in the IETF is specified in the document
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Autonomic functions need an autonomically built communications Autonomic functions need an autonomically built communications
infrastructure. This infrastructure needs to be secure, resilient infrastructure. This infrastructure needs to be secure, resilient
and re-usable by all autonomic functions. Section 5 of [RFC7575] and re-usable by all autonomic functions. Section 5 of [RFC7575]
introduces that infrastructure and calls it the Autonomic Control introduces that infrastructure and calls it the Autonomic Control
Plane (ACP). More descriptively it would be the "Autonomic Plane (ACP). More descriptively it would be the "Autonomic
communications infrastructure for Management and Control". For communications infrastructure for Management and Control". For
naming consistency with that prior document, this document continues naming consistency with that prior document, this document continues
to use the name ACP though. to use the name ACP though.
Today, the management and control plane of networks typically uses Today, the management and control plane of networks typically uses a
the global routing table, which is dependent on correct configuration routing and forwarding table which is dependent on correct
and routing. Misconfigurations or routing problems can therefore configuration and routing. Misconfigurations or routing problems can
disrupt management and control channels. Traditionally, an out-of- therefore disrupt management and control channels. Traditionally, an
band network has been used to avoid or allow recovery from such out-of-band network has been used to avoid or allow recovery from
problems, or personnel are sent on site to access devices through such problems, or personnel are sent on site to access devices
console ports (craft ports). However, both options are expensive. through out-of-band management ports (also called craft ports, serial
console, management ethernet port). However, both options are
expensive.
In increasingly automated networks either centralized management In increasingly automated networks either centralized management
systems or distributed autonomic service agents in the network systems or distributed autonomic service agents in the network
require a control plane which is independent of the configuration of require a control plane which is independent of the configuration of
the network they manage, to avoid impacting their own operations the network they manage, to avoid impacting their own operations
through the configuration actions they take. through the configuration actions they take.
This document describes a modular design for a self-forming, self- This document describes a modular design for a self-forming, self-
managing and self-protecting Autonomic Control Plane (ACP), which is managing and self-protecting Autonomic Control Plane (ACP), which is
a virtual in-band network designed to be as independent as possible a virtual in-band network designed to be as independent as possible
skipping to change at page 7, line 9 skipping to change at page 7, line 11
This document describes these purposes as use cases for the ACP in This document describes these purposes as use cases for the ACP in
Section 3, it defines the requirements in Section 4. Section 5 gives Section 3, it defines the requirements in Section 4. Section 5 gives
an overview how the ACP is constructed, and in Section 6 the process an overview how the ACP is constructed, and in Section 6 the process
is defined in detail. Section 7 defines how to support ACP on L2 is defined in detail. Section 7 defines how to support ACP on L2
switches. Section 8 explains how non-ACP nodes and networks can be switches. Section 8 explains how non-ACP nodes and networks can be
integrated. integrated.
The following sections are non-normative: Section 9 reviews benefits The following sections are non-normative: Section 9 reviews benefits
of the ACP (after all the details have been defined), Section 10 of the ACP (after all the details have been defined), Section 10
provides operational recommendations, Section 11 provides additional provides operational recommendations, Appendix A provides additional
explanations and describes additional details or future work explanations and describes additional details or future work
possibilities that where considered not to be appropriate for possibilities that where considered not to be appropriate for
standardization in this document but were considered important to standardization in this document but were considered important to
document. document.
The ACP provides secure IPv6 connectivity, therefore it can not only The ACP provides secure IPv6 connectivity, therefore it can not only
be used as the secure connectivity for self-management as required be used as the secure connectivity for self-management as required
for the ACP in [RFC7575], but it can also be used as the secure for the ACP in [RFC7575], but it can also be used as the secure
connectivity for traditional (centralized) management. The ACP can connectivity for traditional (centralized) management. The ACP can
be implemented and operated without any other components of autonomic be implemented and operated without any other components of autonomic
skipping to change at page 9, line 6 skipping to change at page 9, line 10
GRASP is the only completely novel protocol used in the ACP, and this GRASP is the only completely novel protocol used in the ACP, and this
choice was necessary because there is no existing suitable protocol choice was necessary because there is no existing suitable protocol
to provide the necessary functions to the ACP, so GRASP was developed to provide the necessary functions to the ACP, so GRASP was developed
to fill that gap. to fill that gap.
The ACP design can be applicable to (cpu, memory) constrained devices The ACP design can be applicable to (cpu, memory) constrained devices
and (bitrate, reliability) constrained networks, but this document and (bitrate, reliability) constrained networks, but this document
does not attempt to define the most constrained type of devices or does not attempt to define the most constrained type of devices or
networks to which the ACP is applicable. RPL and DTLS are two networks to which the ACP is applicable. RPL and DTLS are two
protocol choices already making ACP more applicable to constrained protocol choices already making ACP more applicable to constrained
environments. See Section 11.8 for discussions about how variations environments. See Appendix A.8 for discussions about how variations
of the ACP could be defined in the future to better meet different of the ACP could be defined in the future to better meet different
expectations from those on which the current design is based. expectations from those on which the current design is based.
2. Acronyms and Terminology 2. Acronyms and Terminology
In the rest of the document we will refer to systems using the ACP as In the rest of the document we will refer to systems using the ACP as
"nodes". Typically such a node is a physical (network equipment) "nodes". Typically such a node is a physical (network equipment)
device, but it can equally be some virtualized system. Therefore, we device, but it can equally be some virtualized system. Therefore, we
do not refer to them as devices unless the context specifically calls do not refer to them as devices unless the context specifically calls
for a physical system. for a physical system.
skipping to change at page 12, line 50 skipping to change at page 13, line 9
Can be virtual or physical. Physical nodes are called devices. Can be virtual or physical. Physical nodes are called devices.
Node-ID: The identifier of an ACP node inside that ACP. It is the Node-ID: The identifier of an ACP node inside that ACP. It is the
last 64 (see Section 6.10.3) or 78 bit (see xref target="Vlong"/>) last 64 (see Section 6.10.3) or 78 bit (see xref target="Vlong"/>)
of the ACP address. of the ACP address.
(virtual) out-of-band network: An out-of-band network is a secondary (virtual) out-of-band network: An out-of-band network is a secondary
network used to manage a primary network. The equipment of the network used to manage a primary network. The equipment of the
primary network is connected to the out-of-band network via primary network is connected to the out-of-band network via
dedicated management ports on the primary network equipment. dedicated management ports on the primary network equipment.
Serial (console) management ports are most common, higher end Serial (console) management ports where historically most common,
network equipment also has ethernet ports dedicated only for higher end network equipment now also has ethernet ports dedicated
management. An out-of-band network provides management access to only for management. An out-of-band network provides management
the primary network independent of the configuration state of the access to the primary network independent of the configuration
primary network. One of the goals of the ACP is to provide this state of the primary network. One of the goals of the ACP is to
benefit of out-of-band networks virtually on the primary network provide this benefit of out-of-band networks virtually on the
equipment. The ACP VRF acts as a virtual out of band network primary network equipment. The ACP VRF acts as a virtual out of
device providing configuration independent management access. The band network device providing configuration independent management
ACP secure channels are the virtual links of the ACP virtual out- access. The ACP secure channels are the virtual links of the ACP
of-band network, meant to be operating independent of the virtual out-of-band network, meant to be operating independent of
configuration of the primary network. See also ->"in-band the configuration of the primary network. See also ->"in-band
(management)" (). (management)" ().
RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The RPL: "IPv6 Routing Protocol for Low-Power and Lossy Networks". The
routing protocol used in the ACP. See [RFC6550]. routing protocol used in the ACP. See [RFC6550].
MASA (service): "Manufacturer Authorized Signing Authority". A MASA (service): "Manufacturer Authorized Signing Authority". A
vendor/manufacturer or delegated cloud service on the Internet vendor/manufacturer or delegated cloud service on the Internet
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
skipping to change at page 14, line 4 skipping to change at page 14, line 11
ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6 ULA: (Global ID prefix) A "Unique Local Address" (ULA) is an IPv6
address in the block fc00::/7, defined in [RFC4193]. It is the address in the block fc00::/7, defined in [RFC4193]. It is the
approximate IPv6 counterpart of the IPv4 private address approximate IPv6 counterpart of the IPv4 private address
([RFC1918]). The ULA Global ID prefix are the first 48 bit of a ([RFC1918]). The ULA Global ID prefix are the first 48 bit of a
ULA address. In this document it is abbreviated as "ULA prefix". ULA address. In this document it is abbreviated as "ULA prefix".
(ACP) VRF: The ACP is modeled in this document as a "Virtual Routing (ACP) VRF: The ACP is modeled in this document as a "Virtual Routing
and Forwarding" instance (VRF). This means that it is based on a and Forwarding" instance (VRF). This means that it is based on a
"virtual router" consisting of a separate IPv6 forwarding table to "virtual router" consisting of a separate IPv6 forwarding table to
which the ACP virtual interfaces are attached and an associated which the ACP virtual interfaces are attached and an associated
separate IPv6 routing table. Unlike the VRFs on MPLS/VPN-PE IPv6 routing table separate from the Data-Plane. Unlike the VRFs
([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF does not have any on MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF
special "core facing" functionality or routing/mapping protocols does not have any special "core facing" functionality or routing/
shared across multiple VRFs. In vendor products a VRF such as the mapping protocols shared across multiple VRFs. In vendor products
ACP-VRF may also be referred to as a so called VRF-lite. a VRF such as the ACP-VRF may also be referred to as a so called
VRF-lite.
(ACP) Zone: An ACP zone is a connected region of the ACP where nodes (ACP) Zone: An ACP zone is a connected region of the ACP where nodes
derive from their non-aggregatable ACP address (identifier derive from their non-aggregatable ACP address (identifier
address) an aggregatable ACP zone address (locator address). See address) an aggregatable ACP zone address (locator address). See
the definition of the ACP Zone Addressing Sub-Scheme the definition of the ACP Zone Addressing Sub-Scheme
(Section 6.10.3). The complete definition of zones is subject to (Section 6.10.3). The complete definition of zones is subject to
future work because this document does not describe the routing future work because this document does not describe the routing
protocols details for aggregation of ACP zone addresses, but only protocols details for aggregation of ACP zone addresses, but only
their addressing scheme. their addressing scheme.
skipping to change at page 14, line 50 skipping to change at page 15, line 10
a controlling node such as an SDN controller ("Software Defined a controlling node such as an SDN controller ("Software Defined
Networking", see [RFC7426]) and the new node to be completely and Networking", see [RFC7426]) and the new node to be completely and
correctly addressed, configured and secured. Bootstrapping and correctly addressed, configured and secured. Bootstrapping and
configuration of a network happens in rings around the controller - configuration of a network happens in rings around the controller -
configuring each ring of devices before the next one can be configuring each ring of devices before the next one can be
bootstrapped. Without console access (for example through an out-of- bootstrapped. Without console access (for example through an out-of-
band network) it is not possible today to make devices securely band network) it is not possible today to make devices securely
reachable before having configured the entire network leading up to reachable before having configured the entire network leading up to
them. them.
With the ACP, secure bootstrap of new devices can happen without With the ACP, secure bootstrap of new devices and whole new networks
requiring any configuration such as the transit connectivity to can happen without requiring any configuration of unconfigured
bootstrap further devices. A new device can automatically be devices along the path: As long as all devices along the path support
bootstrapped in a secure fashion and be deployed with a domain ACP and a zero-touch bootstrap mechanism like BRSKI, the ACP across a
certificate. This does not require any configuration on intermediate whole network of unconfigured devices can be brought up without
nodes, because they can communicate zero-touch and securely through operator/provisioning intervention. The ACP also provides additional
the ACP. security for any bootstrap mechanism, because it encrypts the traffic
along the path hop-by-hop.
3.3. Data-Plane Independent Permanent Reachability 3.3. Data-Plane Independent Permanent Reachability
Today, most critical control plane protocols and network management Today, most critical control plane protocols and network management
protocols are using the Data-Plane (global routing table) of the protocols are using the Data-Plane of the network. This leads to
network. This leads to undesirable dependencies between control and often undesirable dependencies between control and management plane
management plane on one side and the Data-Plane on the other: Only if on one side and the Data-Plane on the other: Only if the forwarding
the Data-Plane is operational, will the other planes work as and control plane of the Data-Plane are configured correctly, will
expected. the Data-Plane and the managment plane work as expected.
Data-Plane connectivity can be affected by errors and faults, for Data-Plane connectivity can be affected by errors and faults, for
example misconfigurations that make AAA (Authentication, example misconfigurations that make AAA (Authentication,
Authorization and Accounting) servers unreachable or can lock an Authorization and Accounting) servers unreachable or can lock an
administrator out of a device; routing or addressing issues can make administrator out of a device; routing or addressing issues can make
a device unreachable; shutting down interfaces over which a current a device unreachable; shutting down interfaces over which a current
management session is running can lock an admin irreversibly out of management session is running can lock an admin irreversibly out of
the device. Traditionally only console access can help recover from the device. Traditionally only out-of-band access can help recover
such issues. from such issues (such as serial console or ethernet management
port).
Data-Plane dependencies also affect applications in a Network Data-Plane dependencies also affect applications in a Network
Operations Center (NOC) such as SDN controller applications: Certain Operations Center (NOC) such as SDN controller applications: Certain
network changes are today hard to operate, because the change itself network changes are today hard to implement, because the change
may affect reachability of the devices. Examples are address or mask itself may affect reachability of the devices. Examples are address
changes, routing changes, or security policies. Today such changes or mask changes, routing changes, or security policies. Today such
require precise hop-by-hop planning. changes require precise hop-by-hop planning.
Note that specific control plane functions for the Data-Plane often
want to depend on forwarding of their packets via the Data-Plane:
Aliveness and routing protocol signaling packets across the Data-
Plane to verify reachability across the Data-Plane, using IPv4
signaling packets for IPv4 routing vs. IPv6 signaling packets for
IPv6 routing.
The ACP provides reachability that is independent of the Data-Plane The ACP provides reachability that is independent of the Data-Plane
(except for the dependency discussed in Section 6.12.2 which can be (except for the dependency discussed in Section 6.12.2 which can be
removed through future work), which allows the control plane and removed through future work), which allows the control plane and
management plane to operate more robustly: management plane to operate more robustly:
o For management plane protocols, the ACP provides the functionality o For management plane protocols, the ACP provides the functionality
of a Virtual out of Band (VooB) channel, by providing connectivity of a Virtual out of Band (VooB) channel, by providing connectivity
to all nodes regardless of their configuration or global routing to all nodes regardless of their Data-Plane configuration, routing
table. and forwarding tables.
o For control plane protocols, the ACP allows their operation even o For control plane protocols, the ACP allows their operation even
when the Data-Plane is temporarily faulty, or during transitional when the Data-Plane is temporarily faulty, or during transitional
events, such as routing changes, which may affect the control events, such as routing changes, which may affect the control
plane at least temporarily. This is specifically important for plane at least temporarily. This is specifically important for
autonomic service agents, which could affect Data-Plane autonomic service agents, which could affect Data-Plane
connectivity. connectivity.
The document "Using Autonomic Control Plane for Stable Connectivity The document "Using Autonomic Control Plane for Stable Connectivity
of Network OAM" [RFC8368] explains this use case for the ACP in of Network OAM" [RFC8368] explains this use case for the ACP in
skipping to change at page 19, line 12 skipping to change at page 19, line 26
members, the TA is used to authenticate the ACP domain membership of members, the TA is used to authenticate the ACP domain membership of
other nodes (see Section 6.1.2). other nodes (see Section 6.1.2).
The LDevID is called the ACP domain certificate, the TA is the The LDevID is called the ACP domain certificate, the TA is the
Certificate Authority (CA) of the ACP domain. Certificate Authority (CA) of the ACP domain.
The ACP does not mandate specific mechanisms by which this keying The ACP does not mandate specific mechanisms by which this keying
material is provisioned into the ACP node, it only requires the material is provisioned into the ACP node, it only requires the
Domain information field as specified in Section 6.1.1 in its domain Domain information field as specified in Section 6.1.1 in its domain
certificate as well as those of candidate ACP peers. See certificate as well as those of candidate ACP peers. See
Section 11.2 for more information about enrollment or provisioning Appendix A.2 for more information about enrollment or provisioning
options. options.
This document uses the term ACP in many places where the Autonomic This document uses the term ACP in many places where the Autonomic
Networking reference documents [RFC7575] and Networking reference documents [RFC7575] and
[I-D.ietf-anima-reference-model] use the word autonomic. This is [I-D.ietf-anima-reference-model] use the word autonomic. This is
done because those reference documents consider (only) fully done because those reference documents consider (only) fully
autonomic networks and nodes, but support of ACP does not require autonomic networks and nodes, but support of ACP does not require
support for other components of autonomic networks. Therefore the support for other components of autonomic networks. Therefore the
word autonomic might be misleading to operators interested in only word autonomic might be misleading to operators interested in only
the ACP: the ACP:
skipping to change at page 20, line 9 skipping to change at page 20, line 21
6.1.1. Certificate Domain Information Field 6.1.1. Certificate Domain Information Field
Information about the domain MUST be encoded in the domain Information about the domain MUST be encoded in the domain
certificate in a subjectAltName / rfc822Name field according to the certificate in a subjectAltName / rfc822Name field according to the
following ABNF definition ([RFC5234]): following ABNF definition ([RFC5234]):
[RFC Editor: Please substitute SELF in all occurences of rfcSELF in [RFC Editor: Please substitute SELF in all occurences of rfcSELF in
this document with the RFC number assigned to this document and this document with the RFC number assigned to this document and
remove this comment line] remove this comment line]
domain-information = local-part "@" domain domain-information = local-part "@" acp-domain-name
local-part = key [ "." local-info ] local-part = key [ "." local-info ]
key = "rfcSELF" key = "rfcSELF"
local-info = [ acp-address ] [ "+" rsub extensions ] local-info = [ acp-address ] [ "+" rsub extensions ]
acp-address = 32hex-dig acp-address = 32hex-dig
hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
rsub = [ domain-name ] ; empty if not used rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5
domain = domain-name routing-subdomain = [ rsub " ." ] acp-domain-name
routing-subdomain = [ rsub " ." ] domain acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5
domain-name = ; <domain> ; as of RFC 1034, section 3.5
extensions = *( "+" extension ) extensions = *( "+" extension )
extension = ; future definition. extension = ; future 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
routing-subdomain = area51.research.acp.example.com acp-domain-name = acp.example.com
routing-subdomain = area51.research.acp.example.com
Figure 2: ACP Domain Information Field ABNF Figure 2: ACP Domain Information Field ABNF
"acp-address" MUST be the ACP address of the node. It is optional to "acp-address" MUST be the ACP address of the node. It is optional to
support variations of the ACP mechanisms, for example other means for support variations of the ACP mechanisms, for example other means for
nodes to assign ACP addresses to themselves. Such methods are nodes to assign ACP addresses to themselves. Such methods are
subject to future work though. subject to future work though.
Note: "acp-address" cannot use standard IPv6 address formats because Note: "acp-address" cannot use standard IPv6 address formats because
it must match the simple dot-atom format of [RFC5322]. ":" are not it must match the simple dot-atom format of [RFC5322]. ":" are not
allowed in that format. allowed in that format.
"domain" is used to indicate the ACP Domain across which all ACP "acp-domain-name" is used to indicate the ACP Domain across which all
nodes trust each other and are willing to build ACP channel to each ACP nodes trust each other and are willing to build ACP channel to
other. See Section 6.1.2. Domain SHOULD be the FQDN of a domain each other. See Section 6.1.2. Acp-domain-name SHOULD be the FQDN
owned by the operator assigning the certificate. This is a simple of a DNS domain owned by the operator assigning the certificate.
method to ensure that the domain is globally unique and collision of This is a simple method to ensure that the domain is globally unique
ACP addresses would therefore only happen due to ULA hash collisions. and collision of ACP addresses would therefore only happen due to ULA
If the operator does not own any FQDN, it should choose a string in hash collisions. If the operator does not own any FQDN, it should
FQDN format that intends to be equally unique. choose a string (in FQDN format) that intends to be equally unique.
"routing-subdomain" is the autonomic subdomain that is used to "routing-subdomain" is the autonomic subdomain that is used to
calculate the hash for the ULA Global ID of the ACP address of the calculate the hash for the ULA Global ID of the ACP address of the
node. "rsub" is optional; its syntax is defined in this document, node. "rsub" is optional; its syntax is defined in this document,
but its semantics are for further study. Understanding the benefits but its semantics are for further study. Understanding the benefits
of using rsub may depend on the results of future work on enhancing of using rsub may depend on the results of future work on enhancing
routing for the ACP. When "rsub" is not used, "routing-subdomain" is routing for the ACP. When "rsub" is not used, "routing-subdomain" is
the same as "domain". "rsub" needs to be in the "local-part"; it the same as "acp-domain-name". "rsub" needs to be in the "local-
could not syntactically be separated from "domain-name" if "domain" part": If the format just had routing-subdomain as the domain part of
is just a domain name. It also makes it easier for domain name to be the domain-information, rsub and acp-domain-name could not be
a valid e-mail target. separated from each other. It also makes acp-domain-name a valid
e-mail target across all routing-subdomains.
The optional "extensions" field is used for future extensions to this The optional "extensions" field is used for future extensions to this
specification. It MUST be ignored if present and not understood. specification. It MUST be ignored if present and not understood.
In this specification, the "acp-address" field is REQUIRED, but In this specification, the "acp-address" field is REQUIRED, but
future variations (see Section 11.8) may use local information to future variations (see Appendix A.8) may use local information to
derive the ACP address. In this case, "acp-address" could be empty. derive the ACP address. In this case, "acp-address" could be empty.
Such a variation would be indicated by an appropriate "extension". Such a variation would be indicated by an appropriate "extension".
If "acp-address" is empty, and "rsub" is empty too, the "local-part" If "acp-address" is empty, and "rsub" is empty too, the "local-part"
will have the format "rfcSELF + + extension(s)". The two plus will have the format "rfcSELF + + extension(s)". The two plus
characters are necessary so the node can unambiguously parse that characters are necessary so the node can unambiguously parse that
both "acp-address" and "rsub" are empty. both "acp-address" and "rsub" are empty.
Note that the maximum size of "domain-information" is 254 characters Note that the maximum size of "domain-information" is 254 characters
and the maximum size of node-info is 64 characters according to and the maximum size of node-info is 64 characters according to
[RFC5280] that is referring to [RFC2821] (superseded by [RFC5321]). [RFC5280] that is referring to [RFC2821] (superseded by [RFC5321]).
skipping to change at page 22, line 33 skipping to change at page 22, line 49
o In result, if any unexpected use of the ACP addressing information o In result, if any unexpected use of the ACP addressing information
in a certificate happens, it is benign and detectable: it would be in a certificate happens, it is benign and detectable: it would be
mail to that mailbox. mail to that mailbox.
See section 4.2.1.6 of [RFC5280] for details on the subjectAltName See section 4.2.1.6 of [RFC5280] for details on the subjectAltName
field. field.
6.1.2. ACP domain membership check 6.1.2. ACP domain membership check
The following points constitute the ACP domain membership check: The following points constitute the ACP domain membership check of a
possible peer certificate, independent of the protocol used:
o The peer certificate is valid as proven by the security o The peer certificate is valid (lifetime).
associations protocol exchange.
o The peer has proved ownership of the private key associated with
the certifictes public key.
o The peer's certificate is signed by one of the trust anchors o The peer's certificate is signed by one of the trust anchors
associated with the ACP domain certificate. associated with the ACP domain certificate.
o If the node certificates indicates a Certificate Revocation List o If the node certificates indicates a Certificate Revocation List
(CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or
Online Certificate Status Protocol (OCSP) responder ([RFC5280], Online Certificate Status Protocol (OCSP) responder ([RFC5280],
section 4.2.2.1), then the peer's certificate must be valid section 4.2.2.1), then the peer's certificate must be valid
according to those criteria: An OCSP check for the peers according to those criteria: An OCSP check for the peers
certificate across the ACP must succeed or the peer certificate certificate across the ACP must succeed or the peer certificate
must not be listed in the CRL retrieved from the CDP. must not be listed in the CRL retrieved from the CDP.
o The peers certificate has a syntactically valid domain information o The peers certificate has a syntactically valid domain information
field (subjectAltName / rfc822Name) and the domain name in that field (subjectAltName / rfc822Name) and the acp-domain-name in
peers domain information field is the same as in this ACP node that peers domain information field is the same as in this ACP
certificate. Note that future Intent rules may modify this. See node certificate. Note that future Intent rules may modify this.
Section 11.7. See Appendix A.7.
6.1.3. Certificate Maintenance 6.1.3. Certificate Maintenance
ACP nodes MUST support certificate renewal via EST ("Enrollment over ACP nodes MUST support certificate renewal via EST ("Enrollment over
Secure Transport", see [RFC7030]) and MAY support other mechanisms. Secure Transport", see [RFC7030]) and MAY support other mechanisms.
An ACP network MUST have at least one ACP node supporting EST server An ACP network MUST have at least one ACP node supporting EST server
functionality across the ACP so that EST renewal is useable. functionality across the ACP so that EST renewal is useable.
ACP nodes SHOULD be able to remember the EST server from which they ACP nodes SHOULD be able to remember the EST server from which they
last renewed their ACP domain certificate and SHOULD provide the last renewed their ACP domain certificate and SHOULD provide the
skipping to change at page 24, line 26 skipping to change at page 24, line 39
Figure 4: GRASP SRV.est definition Figure 4: GRASP SRV.est definition
The objective value "SRV.est" indicates that the objective is an The objective value "SRV.est" indicates that the objective is an
[RFC7030] compliant EST server because "est" is an [RFC6335] [RFC7030] compliant EST server because "est" is an [RFC6335]
registered service name for [RFC7030]. Future backward compatible registered service name for [RFC7030]. Future backward compatible
extensions/alternatives to [RFC7030] may be indicated through extensions/alternatives to [RFC7030] may be indicated through
objective-value. Future non-backward compatible certificate renewal objective-value. Future non-backward compatible certificate renewal
options must use a different objective-name. 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. The frequency 60 seconds, the value SHOULD be operator configurable but SHOULD be
of sending MUST be such that the aggregate amount of periodic not smaller than 60 seconds. The frequency of sending MUST be such
M_FLOODs from all flooding sources causes only negligible traffic that the aggregate amount of periodic M_FLOODs from all flooding
across the ACP. The ttl parameter SHOULD be 3.5 times the period so sources causes only negligible traffic across the ACP. The ttl
that up to three consecutive messages can be dropped before parameter SHOULD be 3.5 times the period so that up to three
considering an announcement expired. In the example above, the ttl consecutive messages can be dropped before considering an
is 210000 msec, 3.5 times 60 seconds. When a service announcer using announcement expired. In the example above, the ttl is 210000 msec,
these parameters unexpectedly dies immediately after sending the 3.5 times 60 seconds. When a service announcer using these
M_FLOOD, receivers would consider it expired 210 seconds later. When parameters unexpectedly dies immediately after sending the M_FLOOD,
a receiver tries to connect to this dead service before this timeout, receivers would consider it expired 210 seconds later. When a
receiver tries to connect to this dead service before this timeout,
it will experience a failing connection and use that as an indication it will experience a failing connection and use that as an indication
that the service is dead and select another instance of the same that the service is dead and select another instance of the same
service instead. service instead.
6.1.3.2. Renewal 6.1.3.2. Renewal
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
skipping to change at page 26, line 5 skipping to change at page 26, line 22
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.
When certificate lifetimes are sufficiently short, such as few hours, When certificate lifetimes are sufficiently short, such as few hours,
certificate revocation may not be necessary, allowing to simplify the certificate revocation may not be necessary, allowing to simplify the
overall certificate maintenance infrastructure. overall certificate maintenance infrastructure.
See Section 11.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.3.5. Re-enrollment
An ACP node may determine that its ACP domain certificate has An ACP node may determine that its ACP domain certificate has
expired, for example because the ACP node was powered down or expired, for example because the ACP node was powered down or
disconnected longer than its certificate lifetime. In this case, the disconnected longer than its certificate lifetime. In this case, the
ACP node SHOULD convert to a role of a re-enrolling candidate ACP ACP node SHOULD convert to a role of a re-enrolling candidate ACP
node. node.
skipping to change at page 28, line 51 skipping to change at page 29, line 22
this document) will be updated in case any last-minute changes in this document) will be updated in case any last-minute changes in
GRASP would make those section references change. GRASP would make those section references change.
DULL GRASP is a limited subset of GRASP intended to operate across an DULL GRASP is a limited subset of GRASP intended to operate across an
insecure link-local scope. See section 2.5.2 of insecure link-local scope. See section 2.5.2 of
[I-D.ietf-anima-grasp] for its formal definition. The ACP uses one [I-D.ietf-anima-grasp] for its formal definition. The ACP uses one
instance of DULL GRASP for every L2 interface of the ACP node to instance of DULL GRASP for every L2 interface of the ACP node to
discover link level adjacent candidate ACP neighbors. Unless discover link level adjacent candidate ACP neighbors. Unless
modified by policy as noted earlier (Section 5 bullet point 2.), modified by policy as noted earlier (Section 5 bullet point 2.),
native interfaces (e.g., physical interfaces on physical nodes) native interfaces (e.g., physical interfaces on physical nodes)
SHOULD be initialized automatically enough, so that ACP discovery can SHOULD be initialized automatically to a state in which ACP discovery
be performed and any native interfaces with ACP neighbors can then be can be performed and any native interfaces with ACP neighbors can
brought into the ACP even if the interface is otherwise not then be brought into the ACP even if the interface is otherwise not
configured. Reception of packets on such otherwise not configured configured. Reception of packets on such otherwise not configured
interfaces MUST be limited so that at first only IPv6 State Less interfaces MUST be limited so that at first only IPv6 State Less
Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work Address Auto Configuration (SLAAC - [RFC4862]) and DULL GRASP work
and then only the following ACP secure channel setup packets - but and then only the following ACP secure channel setup packets - but
not any other unnecessary traffic (e.g., no other link-local IPv6 not any other unnecessary traffic (e.g., no other link-local IPv6
transport stack responders for example). transport stack responders for example).
Note that the use of the IPv6 link-local multicast address Note that the use of the IPv6 link-local multicast address
(ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener (ALL_GRASP_NEIGHBORS) implies the need to use Multicast Listener
Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to Discovery Version 2 (MLDv2, see [RFC3810]) to announce the desire to
skipping to change at page 29, line 30 skipping to change at page 29, line 50
ACP discovery SHOULD NOT be enabled by default on non-native ACP discovery SHOULD NOT be enabled by default on non-native
interfaces. In particular, ACP discovery MUST NOT run inside the ACP interfaces. In particular, ACP discovery MUST NOT run inside the ACP
across ACP virtual interfaces. See Section 10.3 for further, non- across ACP virtual interfaces. See Section 10.3 for further, non-
normative suggestions on how to enable/disable ACP at node and normative suggestions on how to enable/disable ACP at node and
interface level. See Section 8.2.2 for more details about tunnels interface level. See Section 8.2.2 for more details about tunnels
(typical non-native interfaces). See Section 7 for how ACP should be (typical non-native interfaces). See Section 7 for how ACP should be
extended on devices operating (also) as L2 bridges. extended on devices operating (also) as L2 bridges.
Note: If an ACP node also implements BRSKI to enroll its ACP domain Note: If an ACP node also implements BRSKI to enroll its ACP domain
certificate (see Section 11.2 for a summary), then the above certificate (see Appendix A.2 for a summary), then the above
considerations also apply to GRASP discovery for BRSKI. Each DULL considerations also apply to GRASP discovery for BRSKI. Each DULL
instance of GRASP set up for ACP is then also used for the discovery instance of GRASP set up for ACP is then also used for the discovery
of a bootstrap proxy via BRSKI when the node does not have a domain of a bootstrap proxy via BRSKI when the node does not have a domain
certificate. Discovery of ACP neighbors happens only when the node certificate. Discovery of ACP neighbors happens only when the node
does have the certificate. The node therefore never needs to does have the certificate. The node therefore never needs to
discover both a bootstrap proxy and ACP neighbor at the same time. discover both a bootstrap proxy and ACP neighbor at the same time.
An ACP node announces itself to potential ACP peers by use of the An ACP node announces itself to potential ACP peers by use of the
"AN_ACP" objective. This is a synchronization objective intended to "AN_ACP" objective. This is a synchronization objective intended to
be flooded on a single link using the GRASP Flood Synchronization be flooded on a single link using the GRASP Flood Synchronization
(M_FLOOD) message. In accordance with the design of the Flood (M_FLOOD) message. In accordance with the design of the Flood
message, a locator consisting of a specific link-local IP address, IP message, a locator consisting of a specific link-local IP address, IP
protocol number and port number will be distributed with the flooded protocol number and port number will be distributed with the flooded
objective. An example of the message is informally: objective. An example of the message is informally:
Example:
[M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 210000, [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 210000,
["AN_ACP", 4, 1, "IKEv2" ], ["AN_ACP", 4, 1, "IKEv2" ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80000000000000c0011001FEEF0000, UDP, 15000] h'fe80000000000000c0011001FEEF0000, UDP, 15000]
["AN_ACP", 4, 1, "DTLS" ], ["AN_ACP", 4, 1, "DTLS" ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80000000000000c0011001FEEF0000, UDP, 17000] h'fe80000000000000c0011001FEEF0000, UDP, 17000]
] ]
Figure 5: GRASP AN_ACP example Figure 5: GRASP AN_ACP example
skipping to change at page 31, line 50 skipping to change at page 32, line 15
Adjacency Table, see Section 6.2 which then drives the further Adjacency Table, see Section 6.2 which then drives the further
building of the ACP to that neighbor. building of the ACP to that neighbor.
6.4. Candidate ACP Neighbor Selection 6.4. Candidate ACP Neighbor Selection
An ACP node must determine to which other ACP nodes in the adjacency An ACP node must determine to which other ACP nodes in the adjacency
table it should build an ACP connection. This is based on the table it should build an ACP connection. This is based on the
information in the ACP Adjacency table. information in the ACP Adjacency table.
The ACP is by default established exclusively between nodes in the The ACP is by default established exclusively between nodes in the
same domain. This includes all routing subdomains. Section 11.7 same domain. This includes all routing subdomains. Appendix A.7
explains how ACP connections across multiple routing subdomains are explains how ACP connections across multiple routing subdomains are
special. special.
Future extensions to this document including Intent can change this Future extensions to this document including Intent can change this
default behavior. Examples include: default behavior. Examples include:
o Build the ACP across all domains that have a common parent domain. o Build the ACP across all domains that have a common parent domain.
For example ACP nodes with domain "example.com", nodes of For example ACP nodes with domain "example.com", nodes of
"example.com", "access.example.com", "core.example.com" and "example.com", "access.example.com", "core.example.com" and
"city.core.example.com" could all establish one single ACP. "city.core.example.com" could all establish one single ACP.
o ACP connections across domains with different Certificate o ACP connections across domains with different Certificate
Authorities (CA) could establish a common ACP by installing the Authorities (CA) could establish a common ACP by installing the
alternate domains' CA into the trusted anchor store. This is an alternate domains' CA into the trusted anchor store. This is an
executive management action that could easily be accomplished executive management action that could easily be accomplished
through the control channel created by the ACP. through the control channel created by the ACP.
Since Intent is transported over the ACP, the first ACP connection a Since Intent is transported over the ACP, the first ACP connection a
node establishes is always following the default behavior. See node establishes is always following the default behavior. See
Section 11.7 for more details. Appendix A.7 for more details.
The result of the candidate ACP neighbor selection process is a list The result of the candidate ACP neighbor selection process is a list
of adjacent or configured autonomic neighbors to which an ACP channel of adjacent or configured autonomic neighbors to which an ACP channel
should be established. The next step begins that channel should be established. The next step begins that channel
establishment. establishment.
6.5. Channel Selection 6.5. Channel Selection
To avoid attacks, initial discovery of candidate ACP peers cannot To avoid attacks, initial discovery of candidate ACP peers cannot
include any non-protected negotiation. To avoid re-inventing and include any non-protected negotiation. To avoid re-inventing and
skipping to change at page 36, line 9 skipping to change at page 36, line 26
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
As explained in the beginning of Section 6.5, there is no single
secure channel mechanism mandated for all ACP nodes. Instead, this
section defines two ACP profiles (baseline and constrained) for ACP
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 can not support IPsec MUST via GRE. A constrained ACP node that can not support IPsec MUST
support DTLS. ACP nodes connecting constrained areas with baseline support DTLS. An ACP node connecting an area of constrained ACP
areas MUST therefore support IPsec and DTLS. nodes with an area of baseline ACP nodes MUST therefore support IPsec
and DTLS and supports threefore the baseline and constrained profile.
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. mechanisms they support and should declare which profile they support
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.
6.8. GRASP in the ACP 6.8. GRASP in the ACP
6.8.1. GRASP as a core service of the ACP 6.8.1. GRASP as a core service of the ACP
The ACP MUST run an instance of GRASP inside of it. It is a key part The ACP MUST run an instance of GRASP inside of it. It is a key part
of the ACP services. The function in GRASP that makes it fundamental of the ACP services. The function in GRASP that makes it fundamental
as a service of the ACP is the ability to provide ACP wide service as a service of the ACP is the ability to provide ACP wide service
discovery (using objectives in GRASP). discovery (using objectives in GRASP).
ACP provides IP unicast routing via the RPL routing protocol (see ACP provides IP unicast routing via the RPL routing protocol (see
Section 6.11). Section 6.11).
skipping to change at page 36, line 45 skipping to change at page 37, line 23
The ACP does not use IP multicast routing nor does it provide generic The ACP does not use IP multicast routing nor does it provide generic
IP multicast services (the handling of GRASP link-local multicast IP multicast services (the handling of GRASP link-local multicast
messages is explained in Section 6.8.2). Instead, the ACP provides messages is explained in Section 6.8.2). Instead, the ACP provides
service discovery via the objective discovery/announcement and service discovery via the objective discovery/announcement and
negotiation mechanisms of the ACP GRASP instance (services are a form negotiation mechanisms of the ACP GRASP instance (services are a form
of objectives). These mechanisms use hop-by-hop reliable flooding of of objectives). These mechanisms use hop-by-hop reliable flooding of
GRASP messages for both service discovery (GRASP M_DISCOVERY GRASP messages for both service discovery (GRASP M_DISCOVERY
messages) and service announcement (GRASP M_FLOOD messages). messages) and service announcement (GRASP M_FLOOD messages).
See Section 11.5 for more discussion about this design choice of the See Appendix A.5 for more discussion about this design choice of the
ACP and considerations for possible future variations. ACP and considerations for possible future variations.
6.8.2. ACP as the Security and Transport substrate for GRASP 6.8.2. ACP as the Security and Transport substrate for GRASP
In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the
security and transport substrate for the GRASP instance run inside security and transport substrate for the GRASP instance run inside
the ACP ("ACP GRASP"). the ACP ("ACP GRASP").
This means that the ACP is responsible for ensuring that this This means that the ACP is responsible for ensuring that this
instance of GRASP is only sending messages across the ACP GRASP instance of GRASP is only sending messages across the ACP GRASP
skipping to change at page 37, line 30 skipping to change at page 38, line 5
In this case ASAs using GRASP running on the same node would still In this case ASAs using GRASP running on the same node would still
need to be able to discover each other's objectives. When the ACP need to be able to discover each other's objectives. When the ACP
does not exist, ASAs leveraging the ACP instance of GRASP via APIs does not exist, ASAs leveraging the ACP instance of GRASP via APIs
MUST still be able to operate, and MUST be able to understand that MUST still be able to operate, and MUST be able to understand that
there is no ACP and that therefore the ACP instance of GRASP can not there is no ACP and that therefore the ACP instance of GRASP can not
operate. operate.
The way ACP acts as the security and transport substrate for GRASP is The way ACP acts as the security and transport substrate for GRASP is
visualized in the following picture: visualized in the following picture:
[RFC Editor: please try to put the following picture on a single page ..............................ACP..............................
and remove this note. We cannot figure out how to do this with XML.
The picture does fit on a single page.]
ACP:
...............................................................
. . . .
. /-GRASP-flooding-\ ACP GRASP instance . . /-GRASP-flooding-\ ACP GRASP instance .
. / \ . . / \ A
. GRASP GRASP GRASP . . GRASP GRASP GRASP C
. link-local unicast link-local . . link-local unicast link-local P
. multicast messages multicast . . multicast messages multicast .
. messages | messages . . messages | messages .
. | | | . . | | | .
............................................................... ...............................................................
. v v v ACP security and transport . . v v v ACP security and transport .
. | | | substrate for GRASP . . | | | substrate for GRASP .
. | | | . . | | | .
. | ACP GRASP | - ACP GRASP . . | ACP GRASP | - ACP GRASP A
. | Loopback | Loopback interface . . | Loopback | Loopback interface C
. | interface | - ACP-cert auth . . | interface | - ACP-cert auth P
. | TLS | . . | TLS | .
. ACP GRASP | ACP GRASP - ACP GRASP virtual . . ACP GRASP | ACP GRASP - ACP GRASP virtual .
. subnet1 | subnet2 virtual interfaces . . subnet1 | subnet2 virtual interfaces .
. TCP | TCP . . TCP | TCP .
. | | | . . | | | .
............................................................... ...............................................................
. | | | ^^^ Users of ACP (GRASP/ASA) . . | | | ^^^ Users of ACP (GRASP/ASA) .
. | | | ACP interfaces/addressing . . | | | ACP interfaces/addressing .
. | | | . . | | | .
. | | | . . | | | A
. | ACP-Loopback Interf.| <- ACP Loopback interface . . | ACP-Loopback Interf.| <- ACP Loopback interface C
. | ACP-address | - address (global ULA) . . | 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 routing and forwarding .
. | RPL-routing | . . | RPL-routing | .
. | /IP-Forwarding\ | . . | /IP-Forwarding\ | A
. | / \ | . . | / \ | C
. ACP IPv6 packets ACP IPv6 packets . . 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
skipping to change at page 40, line 33 skipping to change at page 40, line 51
In classical network system, a dedicated so called Virtual routing In classical network system, a dedicated so called Virtual routing
and forwarding instance (VRF) is one logical implementation option and forwarding instance (VRF) is one logical implementation option
for the ACP. If possible by the systems software architecture, for the ACP. If possible by the systems software architecture,
separation options that minimize shared components are preferred, separation options that minimize shared components are preferred,
such as a logical container or virtual machine instance. The context such as a logical container or virtual machine instance. The context
for the ACP needs to be established automatically during bootstrap of for the ACP needs to be established automatically during bootstrap of
a node. As much as possible it should be protected from being a node. As much as possible it should be protected from being
modified unintentionally by ("Data-Plane") configuration. modified unintentionally by ("Data-Plane") configuration.
Context separation improves security, because the ACP is not Context separation improves security, because the ACP is not
reachable from the global routing table. Also, configuration errors reachable from the Data-Plane routing or forwarding table(s). Also,
from the Data-Plane setup do not affect the ACP. configuration errors from the Data-Plane setup do not affect the ACP.
6.10. Addressing inside the ACP 6.10. Addressing inside the ACP
The channels explained above typically only establish communication The channels explained above typically only establish communication
between two adjacent nodes. In order for communication to happen between two adjacent nodes. In order for communication to happen
across multiple hops, the autonomic control plane requires ACP across multiple hops, the autonomic control plane requires ACP
network wide valid addresses and routing. Each ACP node must create network wide valid addresses and routing. Each ACP node must create
a Loopback interface with an ACP network wide unique address inside a Loopback interface with an ACP network wide unique address inside
the ACP context (as explained in in Section 6.9). This address may the ACP context (as explained in in Section 6.9). This address may
be used also in other virtual contexts. be used also in other virtual contexts.
skipping to change at page 43, line 13 skipping to change at page 43, line 24
Request message by the pledge. Request message by the pledge.
o Type: This field allows different address sub-schemes. This o Type: This field allows different address sub-schemes. This
addresses the "upgradability" requirement. Assignment of types addresses the "upgradability" requirement. Assignment of types
for this field will be maintained by IANA. for this field will be maintained by IANA.
The sub-scheme may imply a range or set of addresses assigned to the The sub-scheme may imply a range or set of addresses assigned to the
node, this is called the ACP address range/set and explained in each node, this is called the ACP address range/set and explained in each
sub-scheme. sub-scheme.
Please refer to Section 6.10.7 and Section 11.1 for further Please refer to Section 6.10.7 and Appendix A.1 for further
explanations why the following Sub-Addressing schemes are used and explanations why the following Sub-Addressing schemes are used and
why multiple are necessary. why multiple are necessary.
6.10.3. ACP Zone Addressing Sub-Scheme 6.10.3. ACP Zone Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 00b (zero) The sub-scheme defined here is defined by the Type value 00b (zero)
in the base scheme and 0 in the Z bit. in the base scheme and 0 in the Z bit.
64 64 64 64
+-----------------+---+---------++-----------------------------+---+ +-----------------+---+---------++-----------------------------+---+
skipping to change at page 48, line 25 skipping to change at page 48, line 28
also lead to the fairly liberal use of address space: The Zone also lead to the fairly liberal use of address space: The Zone
Addressing Sub-Scheme is intended to enable optimized routing in Addressing Sub-Scheme is intended to enable optimized routing in
large networks by reserving bits for Zone-ID's. The Vlong addressing large networks by reserving bits for Zone-ID's. The Vlong addressing
sub-scheme enables the allocation of 8/16 bit of addresses inside sub-scheme enables the allocation of 8/16 bit of addresses inside
individual ACP nodes. Both address spaces allow distributed, individual ACP nodes. Both address spaces allow distributed,
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 should consider making possible, so the last addressing scheme MUST provide further
provisions provision for further extensions (e.g., by reserving bits extensions (e.g., by reserving bits from it for further extensions).
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/ The ACP address prefix is assigned to the ACP node during enrollment/
provisioning of the ACP domain certificate to the ACP node. It is provisioning of the ACP domain certificate to the ACP node. It is
intended to persist unchanged through the lifetime of the ACP node. 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 explained above, ACP nodes
for a single ACP domain can be enrolled by multiple distributed and for a single ACP domain can be enrolled by multiple distributed and
uncoordinated entities called ACP registrars. These ACP registrars uncoordinated entities called ACP registrars. These ACP registrars
skipping to change at page 51, line 30 skipping to change at page 51, line 30
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
Once ULA address are set up all autonomic entities should run a Once ULA address are set up all autonomic entities should run a
routing protocol within the autonomic control plane context. This routing protocol within the autonomic control plane context. This
routing protocol distributes the ULA created in the previous section routing protocol distributes the ULA created in the previous section
for reachability. The use of the autonomic control plane specific for reachability. The use of the autonomic control plane specific
context eliminates the probable clash with the global routing table context eliminates the probable clash with 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 autonomic control plane are by default secured, and
this routing runs only inside the ACP. this routing runs only inside the ACP.
The routing protocol inside the ACP is RPL ([RFC6550]). See The routing protocol inside the ACP is RPL ([RFC6550]). See
Section 11.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 Section 11.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. Summary
skipping to change at page 81, line 21 skipping to change at page 81, line 21
proxy, a design that can be adopted for various protocols that proxy, a design that can be adopted for various protocols that
Pledges/candidate ACP nodes could want to use, for example BRSKI over Pledges/candidate ACP nodes could want to use, for example BRSKI over
CoAP (Constrained Application Protocol), or proxying of Netconf. CoAP (Constrained Application Protocol), or proxying of Netconf.
To reach a trust anchor unaware of the ACP, the ACP registrar would To reach a trust anchor unaware of the ACP, the ACP registrar would
use the Data-Plane. ACP and Data-Plane in an ACP registrar could use the Data-Plane. ACP and Data-Plane in an ACP registrar could
(and by default should be) completely isolated from each other at the (and by default should be) completely isolated from each other at the
network level. Only applications like the ACP registrar would need network level. Only applications like the ACP registrar would need
the ability for their transport stacks to access both. the ability for their transport stacks to access both.
In non autonomic enrollment options, the data plane between a ACP In non autonomic enrollment options, the Data-Plane between a ACP
registrar and the candidate ACP node needs to be configured first. registrar and the candidate ACP node needs to be configured first.
This includes the ACP registrar and the candidate ACP node. Then any This includes the ACP registrar and the candidate ACP node. Then any
appropriate set of protocols can be used between ACP registrar and appropriate set of protocols can be used between ACP registrar and
candidate ACP node to discover the other side, and then connect and candidate ACP node to discover the other side, and then connect and
enroll (configure) the candidate ACP node with an ACP domain enroll (configure) the candidate ACP node with an ACP domain
certificate. Netconf ZeroTouch ([I-D.ietf-netconf-zerotouch]) is an certificate. Netconf ZeroTouch ([I-D.ietf-netconf-zerotouch]) is an
example protocol that could be used for this. BRSKI using optional example protocol that could be used for this. BRSKI using optional
discovery mechanisms is equally a possibility for candidate ACP nodes discovery mechanisms is equally a possibility for candidate ACP nodes
attempting to be enrolled across non-ACP networks, such as the attempting to be enrolled across non-ACP networks, such as the
Internet. Internet.
When candidate ACP nodes have secure bootstrap, like BRSKI Pledges, When candidate ACP nodes have secure bootstrap, like BRSKI Pledges,
they will not trust to be configured/enrolled across the network, they will not trust to be configured/enrolled across the network,
unless being presented with a voucher (see [RFC8366]) authorizing the unless being presented with a voucher (see [RFC8366]) authorizing the
network to take posession of the node. An ACP registrar will then network to take possession of the node. An ACP registrar will then
need a method to retrieve such a voucher, either offline, or online need a method to retrieve such a voucher, either offline, or online
from a MASA (Manufacturer Authorized Signing Authority). BRSKI and from a MASA (Manufacturer Authorized Signing Authority). BRSKI and
Netconf ZeroTouch are two protocols that include capabilities to Netconf ZeroTouch are two protocols that include capabilities to
present the voucher to the candidate ACP node. present the voucher to the candidate ACP node.
An ACP registrar could operate EST for ACP certificate renewal and/or An ACP registrar could operate EST for ACP certificate renewal and/or
act as a CRL Distribution point. A node performing these services act as a CRL Distribution point. A node performing these services
does not need to support performing (initial) enrollment, but it does does not need to support performing (initial) enrollment, but it does
require the same above described connectivity as an ACP registrar: require the same above described connectivity as an ACP registrar:
via the ACP to ACP nodes and via the Data-Plane to the trust anchor via the ACP to ACP nodes and via the Data-Plane to the trust anchor
skipping to change at page 85, line 45 skipping to change at page 85, line 45
shutdown". The "down" state disables all interface operations down shutdown". The "down" state disables all interface operations down
to the physical level. The "up" state enables the interface enough to the physical level. The "up" state enables the interface enough
for all possible L2/L3 services to operate on top of it and it may for all possible L2/L3 services to operate on top of it and it may
also auto-enable some subset of them. More commonly, the operations also auto-enable some subset of them. More commonly, the operations
of various L2/L3 services is controlled via additional node-wide or of various L2/L3 services is controlled via additional node-wide or
interface level options, but they all become only active when the interface level options, but they all become only active when the
interface is not "down". Therefore an easy way to ensure that all interface is not "down". Therefore an easy way to ensure that all
L2/L3 operations on an interface are inactive is to put the interface L2/L3 operations on an interface are inactive is to put the interface
into "down" state. The fact that this also physically shuts down the into "down" state. The fact that this also physically shuts down the
interface is in many cases just a side effect, but it may be interface is in many cases just a side effect, but it may be
important in other cases (see below). important in other cases (see below, Section 10.3.2.2).
To provide ACP/ANI resilience against operators configuring To provide ACP/ANI resilience against operators configuring
interfaces to "down" state, this document recommends to separate the interfaces to "down" state, this document recommends to separate the
"down" state of interfaces into an "admin down" state where the "down" state of interfaces into an "admin down" state where the
physical layer is kept running and ACP/ANI can use the interface and physical layer is kept running and ACP/ANI can use the interface and
a "physical down" state. Any existing "down" configurations would a "physical down" state. Any existing "down" configurations would
map to "admin down". In "admin down", any existing L2/L3 services of map to "admin down". In "admin down", any existing L2/L3 services of
the Data-Plane should see no difference to "physical down" state. To the Data-Plane should see no difference to "physical down" state. To
ensure that no Data-Plane packets could be sent/received, packet ensure that no Data-Plane packets could be sent/received, packet
filtering could be established automatically as described above in filtering could be established automatically as described above in
skipping to change at page 88, line 8 skipping to change at page 88, line 8
bringing down all packet transmissions for reflection/cable-length bringing down all packet transmissions for reflection/cable-length
measurements. Any of these options would disrupt ACP as well. measurements. Any of these options would disrupt ACP as well.
In cases where such low-level diagnostics of an operational link is In cases where such low-level diagnostics of an operational link is
desired but where the link could be a single point of failure for the desired but where the link could be a single point of failure for the
ACP, ASA on both nodes of the link could perform a negotiated ACP, ASA on both nodes of the link could perform a negotiated
diagnostics that automatically terminates in a predetermined manner diagnostics that automatically terminates in a predetermined manner
without dependence on external input ensuring the link will become without dependence on external input ensuring the link will become
operational again. operational again.
10.3.2.4. Power Consumption 10.3.2.4. Power Consumption Issues
Power consumption of "physical down" interfaces may be significantly Power consumption of "physical down" interfaces, may be significantly
lower than those in "admin down" state, for example on long range lower than those in "admin down" state, for example on long-range
fiber interfaces. Assuming reasonable clocks on devices, mechanisms fiber interfaces. Bringing up interfaces, for example to probe
for infrequent periodic probing could allow to automatically reachabiliy, may also consume additional power. This can make these
establish ACP connectivity across such links. Bring up interfaces type of interfaces inappropriate to operate purely for the ACP when
for 5 seconds to probe if there is an ACP neighbor on the remote end they are not currently needed for the Data-Plane.
every 500 seconds = 1% power consumption.
10.3.3. Interface level ACP/ANI enable 10.3.3. Interface level ACP/ANI enable
The interface level configuration option "ACP enable" enables ACP The interface level configuration option "ACP enable" enables ACP
operations on an interface, starting with ACP neighbor discovery via operations on an interface, starting with ACP neighbor discovery via
DULL GRAP. The interface level configuration option "ANI enable" on DULL GRAP. The interface level configuration option "ANI enable" on
nodes supporting BRSKI and ACP starts with BRSKI pledge operations nodes supporting BRSKI and ACP starts with BRSKI pledge operations
when there is no domain certificate on the node. On ACP/BRSKI nodes, when there is no domain certificate on the node. On ACP/BRSKI nodes,
"ACP enable" may not need to be supported, but only "ANI enable". "ACP enable" may not need to be supported, but only "ANI enable".
Unless overridden by global configuration options (see later), "ACP/ Unless overridden by global configuration options (see later), "ACP/
skipping to change at page 91, line 24 skipping to change at page 91, line 24
Nodes supporting full ANI functionality set "ANI enable" Nodes supporting full ANI functionality set "ANI enable"
automatically when they decide that they are greenfield, e.g., that automatically when they decide that they are greenfield, e.g., that
they are powering on from factory condition. They will then put all they are powering on from factory condition. They will then put all
native interfaces into "admin down" state and start to perform BRSKI native interfaces into "admin down" state and start to perform BRSKI
pledge functionality - and once a domain certificate is enrolled they pledge functionality - and once a domain certificate is enrolled they
automatically enable ACP. automatically enable ACP.
Attempts for BRSKI pledge operations in greenfield state should Attempts for BRSKI pledge operations in greenfield state should
terminate automatically when another method of configuring the node terminate automatically when another method of configuring the node
is used. Methods that indicate some form of physical possession of is used. Methods that indicate some form of physical possession of
the device such as configuration via the serial console could lead to the device such as configuration via the serial console port could
immediate termination of BRSKI, while other parallel auto lead to immediate termination of BRSKI, while other parallel auto
configuration methods subject to remote attacks might lead to BRSKI configuration methods subject to remote attacks might lead to BRSKI
termination only after they were successful. Details of this may termination only after they were successful. Details of this may
vary widely over different type of nodes. When BRSKI pledge vary widely over different type of nodes. When BRSKI pledge
operation terminates, this will automatically unset "ANI enable" and operation terminates, this will automatically unset "ANI enable" and
should terminate any temporarily needed state on the device to should terminate any temporarily needed state on the device to
perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration perform BRSKI - DULL GRASP, BRSKI pledge and any IPv6 configuration
on interfaces. on interfaces.
10.3.6. Undoing ANI/ACP enable 10.3.6. Undoing ANI/ACP enable
skipping to change at page 92, line 29 skipping to change at page 92, line 29
Interface level "ACP/ANI enable" control per-interface operations. Interface level "ACP/ANI enable" control per-interface operations.
It is enabled by default on native interfaces and has to be It is enabled by default on native interfaces and has to be
configured explicitly on other interfaces. configured explicitly on other interfaces.
Disabling "ACP/ANI enable" global and per-interface should have Disabling "ACP/ANI enable" global and per-interface should have
additional checks to minimize undesired breakage of ACP. The degree additional checks to minimize undesired breakage of ACP. The degree
of control could be a domain wide parameter in the domain of control could be a domain wide parameter in the domain
certificates. certificates.
11. Background and Futures (Informative) 11. Security Considerations
The following sections discuss additional background information
about aspects of the normative parts of this document or associated
mechanisms such as BRSKI (such as why specific choices where made by
the ACP) and they provide discussion about possble future variations
of the ACP.
11.1. ACP Address Space Schemes
This document defines the Zone, Vlong and Manual sub address schemes
primarily to support address prefix assignment via distributed,
potentially uncoordinated ACP registrars as defined in
Section 6.10.7. This costs 48/46 bit identifier so that these ACP
registrar can assign non-conflicting address prefixes. This design
does not leave enough bits to simultaneously support a large number
of nodes (Node-ID) plus a large prefix of local addresses for every
node plus a large enough set of bits to identify a routing Zone. In
result, Zone, Vlong 8/16 attempt to support all features, but in via
separate prefixes.
In networks that always expect to rely on a centralized PMS as
described above (Section 10.2.5), the 48/46 bits for the Registrar-ID
could be saved. Such variations of the ACP addressing mecchanisms
could be introduct through future work in different ways. If the
prefix rfcSELF in the ACP information field was changed, incompatible
ACP variations could be created where every design aspect of the ACP
could be changed. Including all addressing choices. If instead a
new addressing sub-type would be defined, it could be a backward
compatible extension of this ACP specification. Information such as
the size of a zone-prefix and the length of the prefix assigned to
the ACP node itself could be encoded via the extension field of the
ACP domain information.
Note that an explicitly defined "Manual" addressing sub-scheme is
always beneficial to provide an easy way for ACP nodes to prohibit
incorrect manual configuration of any non-"Manual" ACP address spaces
and therefore ensure hat "Manual" operations will never impact
correct routing for any non-"Manual" ACP addresses assigned via ACP
domain certificates.
11.2. BRSKI Bootstrap (ANI)
[I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes
with an IDevID certificate can securely and zero-touch enroll with a
domain certificate (LDevID) to support the ACP. BRSKI also leverages
the ACP to enable zero-touch bootstrap of new nodes across networks
without any configuration requirements across the transit nodes
(e.g., no DHCP/DNS forwarding/server setup). This includes otherwise
not configured networks as described in Section 3.2. Therefore BRSKI
in conjunction with ACP provides for a secure and zero-touch
management solution for complete networks. Nodes supporting such an
infrastructure (BRSKI and ACP) are called ANI nodes (Autonomic
Networking Infrastructure), see [I-D.ietf-anima-reference-model].
Nodes that do not support an IDevID but only an (insecure) vendor
specific Unique Device Identifier (UDI) or nodes whose manufacturer
does not support a MASA could use some future security reduced
version of BRSKI.
When BRSKI is used to provision a domain certificate (which is called
enrollment), the BRSKI registrar (acting as an enhanced EST server)
must include the subjectAltName / rfc822Name encoded ACP address and
domain name to the enrolling node (called pledge) via its response to
the pledges EST CSR Attribute request that is mandatory in BRSKI.
The Certificate Authority in an ACP network must not change the
subjectAltName / rfc822Name in the certificate. The ACP nodes can
therefore find their ACP address and domain using this field in the
domain certificate, both for themselves, as well as for other nodes.
The use of BRSKI in conjunction with the ACP can also help to further
simplify maintenance and renewal of domain certificates. Instead of
relying on CRL, the lifetime of certificates can be made extremely
small, for example in the order of hours. When a node fails to
connect to the ACP within its certificate lifetime, it cannot connect
to the ACP to renew its certificate across it (using just EST), but
it can still renew its certificate as an "enrolled/expired pledge"
via the BRSKI bootstrap proxy. This requires only that the BRSKI
registrar honors expired domain certificates and that the pledge
first attempts to perform TLS authentication for BRSKI bootstrap with
its expired domain certificate - and only reverts to its IDevID when
this fails. This mechanism could also render CRLs unnecessary
because the BRSKI registrar in conjunction with the CA would not
renew revoked certificates - only a "Do-not-renew" list would be
necessary on BRSKI registrars/CA.
In the absence of BRSKI or less secure variants thereof, provisioning
of certificates may involve one or more touches or non-standardized
automation. Node vendors usually support provisioning of
certificates into nodes via PKCS#7 (see [RFC2315]) and may support
this provisioning through vendor specific models via Netconf
([RFC6241]). If such nodes also support Netconf Zero-Touch
([I-D.ietf-netconf-zerotouch]) then this can be combined to zero-
touch provisioning of domain certificates into nodes. Unless there
are equivalent integration of Netconf connections across the ACP as
there is in BRSKI, this combination would not support zero-touch
bootstrap across a not configured network though.
11.3. ACP Neighbor discovery protocol selection
This section discusses why GRASP DULL was chosen as the discovery
protocol for L2 adjacent candidate ACP neighbors. The contenders
considered where GRASP, mDNS or LLDP.
11.3.1. LLDP
LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example
of L2 discovery protocols that terminate their messages on L2 ports.
If those protocols would be chosen for ACP neighbor discovery, ACP
neighbor discovery would therefore also terminate on L2 ports. This
would prevent ACP construction over non-ACP capable but LLDP or CDP
enabled L2 switches. LLDP has extensions using different MAC
addresses and this could have been an option for ACP discovery as
well, but the additional required IEEE standardization and definition
of a profile for such a modified instance of LLDP seemed to be more
work than the benefit of "reusing the existing protocol" LLDP for
this very simple purpose.
11.3.2. mDNS and L2 support
Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD)
Resource Records (RRs) as defined in [RFC6763] is a key contender as
an ACP discovery protocol. because it relies on link-local IP
multicast, it does operates at the subnet level, and is also found in
L2 switches. The authors of this document are not aware of mDNS
implementation that terminate their mDNS messages on L2 ports instead
of the subnet level. If mDNS was used as the ACP discovery mechanism
on an ACP capable (L3)/L2 switch as outlined in Section 7, then this
would be necessary to implement. It is likely that termination of
mDNS messages could only be applied to all mDNS messages from such a
port, which would then make it necessary to software forward any non-
ACP related mDNS messages to maintain prior non-ACP mDNS
functionality. Adding support for ACP into such L2 switches with
mDNS could therefore create regression problems for prior mDNS
functionality on those nodes. With low performance of software
forwarding in many L2 switches, this could also make the ACP risky to
support on such L2 switches.
11.3.3. Why DULL GRASP
LLDP was not considered because of the above mentioned issues. mDNS
was not selected because of the above L2 mDNS considerations and
because of the following additional points:
If mDNS was not already existing in a node, it would be more work to
implement than DULL GRASP, and if an existing implementation of mDNS
was used, it would likely be more code space than a separate
implementation of DULL GRASP or a shared implementation of DULL GRASP
and GRASP in the ACP.
11.4. Choice of routing protocol (RPL)
This section motivates why RPL - "IPv6 Routing Protocol for Low-Power
and Lossy Networks ([RFC6550] was chosen as the default (and in this
specification only) routing protocol for the ACP. The choice and
above explained profile was derived from a pre-standard
implementation of ACP that was successfully deployed in operational
networks.
Requirements for routing in the ACP are:
o Self-management: The ACP must build automatically, without human
intervention. Therefore routing protocol must also work
completely automatically. RPL is a simple, self-managing
protocol, which does not require zones or areas; it is also self-
configuring, since configuration is carried as part of the
protocol (see Section 6.7.6 of [RFC6550]).
o Scale: The ACP builds over an entire domain, which could be a
large enterprise or service provider network. The routing
protocol must therefore support domains of 100,000 nodes or more,
ideally without the need for zoning or separation into areas. RPL
has this scale property. This is based on extensive use of
default routing. RPL also has other scalability improvements,
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
infrastructure, thus runs in addition to traditional protocols.
The ACP, and specifically the routing protocol must have low
resource consumption both in terms of memory and CPU requirements.
Specifically, at edge nodes, where memory and CPU are scarce,
consumption should be minimal. RPL builds a destination-oriented
directed acyclic graph (DODAG), where the main resource
consumption is at the root of the DODAG. The closer to the edge
of the network, the less state needs to be maintained. This
adapts nicely to the typical network design. Also, all changes
below a common parent node are kept below that parent node.
o Support for unstructured address space: In the Autonomic
Networking Infrastructure, node addresses are identifiers, and may
not be assigned in a topological way. Also, nodes may move
topologically, without changing their address. Therefore, the
routing protocol must support completely unstructured address
space. RPL is specifically made for mobile ad-hoc networks, with
no assumptions on topologically aligned addressing.
o Modularity: To keep the initial implementation small, yet allow
later for more complex methods, it is highly desirable that the
routing protocol has a simple base functionality, but can import
new functional modules if needed. RPL has this property with the
concept of "objective function", which is a plugin to modify
routing behavior.
o Extensibility: Since the Autonomic Networking Infrastructure is a
new concept, it is likely that changes in the way of operation
will happen over time. RPL allows for new objective functions to
be introduced later, which allow changes to the way the routing
protocol creates the DAGs.
o Multi-topology support: It may become necessary in the future to
support more than one DODAG for different purposes, using
different objective functions. RPL allow for the creation of
several parallel DODAGs, should this be required. This could be
used to create different topologies to reach different roots.
o No need for path optimization: RPL does not necessarily compute
the optimal path between any two nodes. However, the ACP does not
require this today, since it carries mainly non-delay-sensitive
feedback loops. It is possible that different optimization
schemes become necessary in the future, but RPL can be expanded
(see point "Extensibility" above).
11.5. ACP Information Distribution and multicast
IP multicast is not used by the ACP because the ANI (Autonomic
Networking Infrastructure) itself does not require IP multicast but
only service announcement/discovery. Using IP multicast for that
would have made it necessary to develop a zero-touch auto configuring
solution for ASM (Any Source Multicast - the original form of IP
multicast defined in [RFC1112]), which would be quite complex and
difficult to justify. One aspect of complexity where no attempt at a
solution has been described in IETF documents is the automatic-
selection of routers that should be PIM Sparse Mode (PIM-SM)
Rendezvous Points (RPs) (see [RFC7761]). The other aspects of
complexity are the implementation of MLD ([RFC4604]), PIM-SM and
Anycast-RP (see [RFC4610]). If those implementations already exist
in a product, then they would be very likely tied to accelerated
forwarding which consumes hardware resources, and that in return is
difficult to justify as a cost of performing only service discovery.
Some future ASA may need high performance in-network data
replication. That is the case when the use of IP multicast is
justified. Such an ASA can then use service discovery from ACP
GRASP, and then they do not need ASM but only SSM (Source Specific
Multicast, see [RFC4607]) for the IP multicast replication. SSM
itself can simply be enabled in the Data-Plane (or even in an update
to the ACP) without any other configuration than just enabling it on
all nodes and only requires a simpler version of MLD (see [RFC5790]).
LSP (Link State Protocol) based IGP routing protocols typically have
a mechanism to flood information, and such a mechanism could be used
to flood GRASP objectives by defining them to be information of that
IGP. This would be a possible optimization in future variations of
the ACP that do use an LSP routing protocol. Note though that such a
mechanism would not work easily for GRASP M_DISCOVERY messages which
are intelligently (constrained) flooded not across the whole ACP, but
only up to a node where a responder is found. We do expect that many
future services in ASA will have only few consuming ASA, and for
those cases, M_DISCOVERY is the more efficient method than flooding
across the whole domain.
Because the ACP uses RPL, one desirable future extension is to use
RPLs existing notion of loop-free distribution trees (DODAG) to make
GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See
Section 6.12.5 how this will be specifically beneficial when using
NBMA interfaces. This is not currently specified in this document
because it is not quite clear yet what exactly the implications are
to make GRASP flooding depend on RPL DODAG convergence and how
difficult it would be to let GRASP flooding access the DODAG
information.
11.6. Extending ACP channel negotiation (via GRASP)
The mechanism described in the normative part of this document to
support multiple different ACP secure channel protocols without a
single network wide MTI protocol is important to allow extending
secure ACP channel protocols beyond what is specified in this
document, but it will run into problem if it would be used for
multiple protocols:
The need to potentially have multiple of these security associations
even temporarily run in parallel to determine which of them works
best does not support the most lightweight implementation options.
The simple policy of letting one side (Alice) decide what is best may
not lead to the mutual best result.
The two limitations can easier be solved if the solution was more
modular and as few as possible initial secure channel negotiation
protocols would be used, and these protocols would then take on the
responsibility to support more flexible objectives to negotiate the
mutually preferred ACP security channel protocol.
IKEv2 is the IETF standard protocol to negotiate network security
associations. It is meant to be extensible, but it is unclear
whether it would be feasible to extend IKEv2 to support possible
future requirements for ACP secure channel negotiation:
Consider the simple case where the use of native IPsec vs. IPsec via
GRE is to be negotiated and the objective is the maximum throughput.
Both sides would indicate some agreed upon performance metric and the
preferred encapsulation is the one with the higher performance of the
slower side. IKEv2 does not support negotiation with this objective.
Consider DTLS and some form of MacSec are to be added as negotiation
options - and the performance objective should work across all IPsec,
dDTLS and MacSec options. In the case of MacSEC, the negotiation
would also need to determine a key for the peering. It is unclear if
it would be even appropriate to consider extending the scope of
negotiation in IKEv2 to those cases. Even if feasible to define, it
is unclear if implementations of IKEv2 would be eager to adopt those
type of extension given the long cycles of security testing that
necessarily goes along with core security protocols such as IKEv2
implementations.
A more modular alternative to extending IKEv2 could be to layer a
modular negotiation mechanism on top of the multitude of existing or
possible future secure channel protocols. For this, GRASP over TLS
could be considered as a first ACP secure channel negotiation
protocol. The following are initial considerations for such an
approach. A full specification is subject to a separate document:
To explicitly allow negotiation of the ACP channel protocol, GRASP
over a TLS connection using the GRASP_LISTEN_PORT and the nodes and
peers link-local IPv6 address is used. When Alice and Bob support
GRASP negotiation, they do prefer it over any other non-explicitly
negotiated security association protocol and should wait trying any
non-negotiated ACP channel protocol until after it is clear that
GRASP/TLS will not work to the peer.
When Alice and Bob successfully establish the GRASP/TSL session, they
will negotiate the channel mechanism to use using objectives such as
performance and perceived quality of the security. After agreeing on
a channel mechanism, Alice and Bob start the selected Channel
protocol. Once the secure channel protocol is successfully running,
the GRASP/TLS connection can be kept alive or timed out as long as
the selected channel protocol has a secure association between Alice
and Bob. When it terminates, it needs to be re-negotiated via GRASP/
TLS.
Notes:
o Negotiation of a channel type may require IANA assignments of code
points.
o TLS is subject to reset attacks, which IKEv2 is not. Normally,
ACP connections (as specified in this document) will be over link-
local addresses so the attack surface for this one issue in TCP
should be reduced (note that this may not be true when ACP is
tunneled as described in Section 8.2.2.
o GRASP packets received inside a TLS connection established for
GRASP/TLS ACP negotiation are assigned to a separate GRASP domain
unique to that TLS connection.
11.7. CAs, domains and routing subdomains
There is a wide range of setting up different ACP solution by
appropriately using CAs and the domain and rsub elements in the
domain information field of the domain certificate. We summarize
these options here as they have been explained in different parts of
the document in before and discuss possible and desirable extensions:
An ACP domain is the set of all ACP nodes using certificates from the
same CA using the same domain field. GRASP inside the ACP is run
across all transitively connected ACP nodes in a domain.
The rsub element in the domain information field permits the use of
addresses from different ULA prefixes. One use case is to create
multiple networks that initially may be separated, but where it
should be possible to connect them without further extensions to ACP
when necessary.
Another use case for routing subdomains is as the starting point for
structuring routing inside an ACP. For example, different routing
subdomains could run different routing protocols or different
instances of RPL and auto-aggregation / distribution of routes could
be done across inter routing subdomain ACP channels based on
negotiation (e.g., via GRASP). This is subject for further work.
RPL scales very well. It is not necessary to use multiple routing
subdomains to scale ACP domains in a way it would be possible if
other routing protocols where used. They exist only as options for
the above mentioned reasons.
If different ACP domains are to be created that should not allow to
connect to each other by default, these ACP domains simply need to
have different domain elements in the domain information field.
These domain elements can be arbitrary, including subdomains of one
another: Domains "example.com" and "research.example.com" are
separate domains if both are domain elements in the domain
information element of certificates.
It is not necessary to have a separate CA for different ACP domains:
an operator can use a single CA to sign certificates for multiple ACP
domains that are not allowed to connect to each other because the
checks for ACP adjacencies includes comparison of the domain part.
If multiple independent networks choose the same domain name but had
their own CA, these would not form a single ACP domain because of CA
mismatch. Therefore there is no problem in choosing domain names
that are potentially also used by others. Nevertheless it is highly
recommended to use domain names that one can have high probability to
be unique. It is recommended to use domain names that start with a
DNS domain names owned by the assigning organization and unique
within it. For example "acp.example.com" if you own "example.com".
Future extensions, primarily through intent can create more flexible
options how to build ACP domains.
Intent could modify the ACP connection check to permit connections
between different domains.
If different domains use the same CA one would change the ACP setup
to permit for the ACP to be established between the two ACP nodes,
but no routing nor ACP GRASP to be built across this adjacency. The
main difference over routing subdomains is to not permit for the ACP
GRASP instance to be built across the adjacency. Instead, one would
only build a point to point GRASP instance between those peers to
negotiate what type of exchanges are desired across that connection.
This would include routing negotiation, how much GRASP information to
transit and what Data-Plane forwarding should be done. This approach
could also allow for Intent to only be injected into the network from
one side and propagate via this GRASP connection.
If different domains have different CAs, they should start to trust
each other by intent injected into both domains that would add the
other domains CA as a trust point during the ACP connection setup -
and then following up with the previous point of inter-domain
connections across domains with the same CA (e.g., GRASP
negotiation).
11.8. Adopting ACP concepts for other environments
The ACP as specified in this document is very explicit about the
choice of options to allow interoperable implementations. The
choices made may not be the best for all environments, but the
concepts used by the ACP can be used to build derived solutions:
The ACP specifies the use of ULA and deriving its prefix from the
domain name so that no address allocation is required to deploy the
ACP. The ACP will equally work not using ULA but any other /50 IPv6
prefix. This prefix could simply be a configuration of the ACP
registrars (for example when using BRSKI) to enroll the domain
certificates - instead of the ACP registrar deriving the /50 ULA
prefix from the AN domain name.
Some solutions may already have an auto-addressing scheme, for
example derived from existing unique device identifiers (e.g., MAC
addresses). In those cases it may not be desirable to assign
addresses to devices via the ACP address information field in the way
described in this document. The certificate may simply serve to
identify the ACP domain, and the address field could be empty/unused.
The only fix required in the remaining way the ACP operate is to
define another element in the domain certificate for the two peers to
decide who is Alice and who is Bob during secure channel building.
Note though that future work may leverage the acp address to
authenticate "ownership" of the address by the device. If the
address used by a device is derived from some pre-existing permanent
local ID (such as MAC address), then it would be useful to store that
address in the certificate using the format of the access address
information field or in a similar way.
The ACP is defined as a separate VRF because it intends to support
well managed networks with a wide variety of configurations.
Therefore, reliable, configuration-indestructible connectivity cannot
be achieved from the Data-Plane itself. In solutions where all
transit connectivity impacting functions are fully automated
(including security), indestructible and resilient, it would be
possible to eliminate the need for the ACP to be a separate VRF.
Consider the most simple example system in which there is no separate
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
addressing for user equipment. This gap can then be closed for
example by adding a solution derived from
[I-D.ietf-anima-prefix-management].
TCP/TLS as the protocols to provide reliability and security to GRASP
in the ACP may not be the preferred choice in constrained networks.
For example, CoAP/DTLS (Constrained Application Protocol) may be
preferred where they are already used, allowing to reduce the
additional code space footprint for the ACP on those devices.
Because the transport for GRASP is not only hop-by-hop, but end-to-
end across the ACP, this would require the definition of an
incompatible variant of the ACP. Non-constrained devices could
support both variants (the ACP as defined here, and one using CoAP/
DTLS for GRASP), and the variant used in a deployment could be chosen
for example through a parameter of the domain certificate.
The routing protocol chosen by the ACP design (RPL) does explicitly
not optimize for shortest paths and fastest convergence. Variations
of the ACP may want to use a different routing protocol or introduce
more advanced RPL profiles.
Variations such as what routing protocol to use, or whether to
instantiate an ACP in a VRF or (as suggested above) as the actual
Data-Plane, can be automatically chosen in implementations built to
support multiple options by deriving them from future parameters in
the certificate. Parameters in certificates should be limited to
those that would not need to be changed more often than certificates
would need to be updated anyhow; Or by ensuring that these parameters
can be provisioned before the variation of an ACP is activated in a
node. Using BRSKI, this could be done for example as additional
follow-up signaling directly after the certificate enrollment, still
leveraging the BRSKI TLS connection and therefore not introducing any
additional connectivity requirements.
Last but not least, secure channel protocols including their
encapsulation are easily added to ACP solutions. Secure channels may
even be replaced by simple neighbor authentication to create
simplified ACP variations for environments where no real security is
required but just protection against non-malicious misconfiguration.
Or for environments where all traffic is known or forced to be end-
to-end protected and other means for infrastructure protection are
used. Any future network OAM should always use end-to-end security
anyhow and can leverage the domain certificates and is therefore not
dependent on security to be provided for by ACP secure channels.
12. Security Considerations
An ACP is self-protecting and there is no need to apply configuration An ACP is self-protecting and there is no need to apply configuration
to make it secure. Its security therefore does not depend on to make it secure. Its security therefore does not depend on
configuration. configuration.
However, the security of the ACP depends on a number of other However, the security of the ACP depends on a number of other
factors: factors:
o The usage of domain certificates depends on a valid supporting PKI o The usage of domain certificates depends on a valid supporting PKI
infrastructure. If the chain of trust of this PKI infrastructure infrastructure. If the chain of trust of this PKI infrastructure
skipping to change at page 104, line 25 skipping to change at page 93, line 28
outside, but also by attacks from compromised inside attackers - by outside, but also by attacks from compromised inside attackers - by
relying not only on hop-by-hop security of ACP secure channels, but relying not only on hop-by-hop security of ACP secure channels, but
adding end-to-end security for those GRASP messages. See adding end-to-end security for those GRASP messages. See
Section 6.8.2. Section 6.8.2.
ACP provides for secure, resilient zero-touch discovery of EST ACP provides for secure, resilient zero-touch discovery of EST
servers for certificate renewal. See Section 6.1.3. servers for certificate renewal. See Section 6.1.3.
ACP provides extensible, auto-configuring hop-by-hop protection of ACP provides extensible, auto-configuring hop-by-hop protection of
the ACP infrastructure via the negotiation of hop-by-hop secure the ACP infrastructure via the negotiation of hop-by-hop secure
channel protocols. See Section 6.5 and Section 11.6. channel protocols. See Section 6.5 and Appendix A.6.
The ACP is designed to minimize attacks from the outside by The ACP is designed to minimize attacks from the outside by
minimizing its dependency against any non-ACP operations on a node. minimizing its dependency against any non-ACP operations on a node.
The only dependency in the specification in this document is the need The only dependency in the specification in this document is the need
to share link-local addresses for the ACP secure channel to share link-local addresses for the ACP secure channel
encapsulation with the Data-Plane. See Section 6.12.2. encapsulation with the Data-Plane. See Section 6.12.2.
In combination with BRSKI, ACP enables a resilient, fully zero-touch In combination with BRSKI, ACP enables a resilient, fully zero-touch
network solution for short-lived certificates that can be renewed or network solution for short-lived certificates that can be renewed or
re-enrolled even after unintentional expiry (e.g., because of re-enrolled even after unintentional expiry (e.g., because of
interrupted connectivity). See Section 11.2. interrupted connectivity). See Appendix A.2.
13. 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,
skipping to change at page 105, line 20 skipping to change at page 94, line 25
"ACP Address Type" Table. The value in this table are numeric values "ACP Address Type" Table. The value in this table are numeric values
0...3 paired with a name (string). Future values MUST be assigned 0...3 paired with a name (string). Future values MUST be assigned
using the Standards Action policy defined by [RFC8126]. The using the Standards Action policy defined by [RFC8126]. The
following initial values are assigned by this document: following initial values are assigned by this document:
0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 9) / ACP Manual 0: ACP Zone Addressing Sub-Scheme (ACP RFC Figure 9) / ACP Manual
Addressing Sub-Scheme (ACP RFC Section 6.10.4) Addressing Sub-Scheme (ACP RFC Section 6.10.4)
1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5) 1: ACP Vlong Addressing Sub-Scheme (ACP RFC Section 6.10.5)
14. 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
Richardson, Ravi Kumar Vadapalli. Richardson, Ravi Kumar Vadapalli.
Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and Special thanks to Brian Carpenter, Elwyn Davies, Joel Halpern and
Sheng Jiang for their thorough reviews and to Pascal Thubert and Sheng Jiang for their thorough reviews and to Pascal Thubert and
Michael Richardson to provide the details for the recommendations of Michael Richardson to provide the details for the recommendations of
the use of RPL in the ACP. the use of RPL in the ACP.
Further input, review or suggestions were received from: Rene Struik, Further input, review or suggestions were received from: Rene Struik,
Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang. Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang.
15. Change log [RFC Editor: Please remove] 14. Change log [RFC Editor: Please remove]
15.1. Initial version 14.1. Initial version
First version of this document: draft-behringer-autonomic-control- First version of this document: draft-behringer-autonomic-control-
plane plane
15.2. draft-behringer-anima-autonomic-control-plane-00 14.2. draft-behringer-anima-autonomic-control-plane-00
Initial version of the anima document; only minor edits. Initial version of the anima document; only minor edits.
15.3. draft-behringer-anima-autonomic-control-plane-01 14.3. draft-behringer-anima-autonomic-control-plane-01
o Clarified that the ACP should be based on, and support only IPv6. o Clarified that the ACP should be based on, and support only IPv6.
o Clarified in intro that ACP is for both, between devices, as well o Clarified in intro that ACP is for both, between devices, as well
as for access from a central entity, such as an NMS. as for access from a central entity, such as an NMS.
o Added a section on how to connect an NMS system. o Added a section on how to connect an NMS system.
o Clarified the hop-by-hop crypto nature of the ACP. o Clarified the hop-by-hop crypto nature of the ACP.
o Added several references to GDNP as a candidate protocol. o Added several references to GDNP as a candidate protocol.
o Added a discussion on network split and merge. Although, this o Added a discussion on network split and merge. Although, this
should probably go into the certificate management story longer should probably go into the certificate management story longer
term. term.
15.4. draft-behringer-anima-autonomic-control-plane-02 14.4. draft-behringer-anima-autonomic-control-plane-02
Addresses (numerous) comments from Brian Carpenter. See mailing list Addresses (numerous) comments from Brian Carpenter. See mailing list
for details. The most important changes are: for details. The most important changes are:
o Introduced a new section "overview", to ease the understanding of o Introduced a new section "overview", to ease the understanding of
the approach. the approach.
o Merged the previous "problem statement" and "use case" sections o Merged the previous "problem statement" and "use case" sections
into a mostly re-written "use cases" section, since they were into a mostly re-written "use cases" section, since they were
overlapping. overlapping.
o Clarified the relationship with draft-ietf-anima-stable- o Clarified the relationship with draft-ietf-anima-stable-
connectivity connectivity
15.5. draft-behringer-anima-autonomic-control-plane-03 14.5. draft-behringer-anima-autonomic-control-plane-03
o Took out requirement for IPv6 --> that's in the reference doc. o Took out requirement for IPv6 --> that's in the reference doc.
o Added requirement section. o Added requirement section.
o Changed focus: more focus on autonomic functions, not only virtual o Changed focus: more focus on autonomic functions, not only virtual
out-of-band. This goes a bit throughout the document, starting out-of-band. This goes a bit throughout the document, starting
with a changed abstract and intro. with a changed abstract and intro.
15.6. draft-ietf-anima-autonomic-control-plane-00 14.6. draft-ietf-anima-autonomic-control-plane-00
No changes; re-submitted as WG document. No changes; re-submitted as WG document.
15.7. draft-ietf-anima-autonomic-control-plane-01 14.7. draft-ietf-anima-autonomic-control-plane-01
o Added some paragraphs in addressing section on "why IPv6 only", to o Added some paragraphs in addressing section on "why IPv6 only", to
reflect the discussion on the list. reflect the discussion on the list.
o Moved the Data-Plane ACP out of the main document, into an o Moved the Data-Plane ACP out of the main document, into an
appendix. The focus is now the virtually separated ACP, since it appendix. The focus is now the virtually separated ACP, since it
has significant advantages, and isn't much harder to do. has significant advantages, and isn't much harder to do.
o Changed the self-creation algorithm: Part of the initial steps go o Changed the self-creation algorithm: Part of the initial steps go
into the reference document. This document now assumes an into the reference document. This document now assumes an
skipping to change at page 107, line 42 skipping to change at page 96, line 46
o Introduce a section for the capability negotiation protocol o Introduce a section for the capability negotiation protocol
(section 7). This needs to be worked out in more detail. This (section 7). This needs to be worked out in more detail. This
will likely be based on GRASP. will likely be based on GRASP.
o Introduce a new parameter: ACP tunnel type. And defines it in the o Introduce a new parameter: ACP tunnel type. And defines it in the
IANA considerations section. Suggest GRE protected with IPSec IANA considerations section. Suggest GRE protected with IPSec
transport mode as the default tunnel type. transport mode as the default tunnel type.
o Updated links, lots of small edits. o Updated links, lots of small edits.
15.8. draft-ietf-anima-autonomic-control-plane-02 14.8. draft-ietf-anima-autonomic-control-plane-02
o Added explicitly text for the ACP channel negotiation. o Added explicitly text for the ACP channel negotiation.
o Merged draft-behringer-anima-autonomic-addressing-02 into this o Merged draft-behringer-anima-autonomic-addressing-02 into this
document, as suggested by WG chairs. document, as suggested by WG chairs.
15.9. draft-ietf-anima-autonomic-control-plane-03 14.9. draft-ietf-anima-autonomic-control-plane-03
o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap o Changed Neighbor discovery protocol from GRASP to mDNS. Bootstrap
protocol team decided to go with mDNS to discover bootstrap proxy, protocol team decided to go with mDNS to discover bootstrap proxy,
and ACP should be consistent with this. Reasons to go with mDNS and ACP should be consistent with this. Reasons to go with mDNS
in bootstrap were a) Bootstrap should be reuseable also outside of in bootstrap were a) Bootstrap should be reuseable also outside of
full anima solutions and introduce as few as possible new full anima solutions and introduce as few as possible new
elements. mDNS was considered well-known and very-likely even pre- elements. mDNS was considered well-known and very-likely even pre-
existing in low-end devices (IoT). b) Using GRASP both for the existing in low-end devices (IoT). b) Using GRASP both for the
insecure neighbor discovery and secure ACP operatations raises the insecure neighbor discovery and secure ACP operatations raises the
risk of introducing security issues through implementation issues/ risk of introducing security issues through implementation issues/
skipping to change at page 108, line 37 skipping to change at page 97, line 37
planned, and the paragraph in the main text referring to it. planned, and the paragraph in the main text referring to it.
o Deleted one sub-addressing scheme, focusing on a single scheme o Deleted one sub-addressing scheme, focusing on a single scheme
now. now.
o Included information on how ANIMA information must be encoded in o Included information on how ANIMA information must be encoded in
the domain certificate in section "preconditions". the domain certificate in section "preconditions".
o Editorial changes, updated draft references, etc. o Editorial changes, updated draft references, etc.
15.10. draft-ietf-anima-autonomic-control-plane-04 14.10. draft-ietf-anima-autonomic-control-plane-04
Changed discovery of ACP neighbor back from mDNS to GRASP after Changed discovery of ACP neighbor back from mDNS to GRASP after
revisiting the L2 problem. Described problem in discovery section revisiting the L2 problem. Described problem in discovery section
itself to justify. Added text to explain how ACP discovery relates itself to justify. Added text to explain how ACP discovery relates
to BRSKY (bootstrap) discovery and pointed to Michael Richardsons to BRSKY (bootstrap) discovery and pointed to Michael Richardsons
draft detailing it. Removed appendix section that contained the draft detailing it. Removed appendix section that contained the
original explanations why GRASP would be useful (current text is original explanations why GRASP would be useful (current text is
meant to be better). meant to be better).
15.11. draft-ietf-anima-autonomic-control-plane-05 14.11. draft-ietf-anima-autonomic-control-plane-05
o Section 5.3 (candidate ACP neighbor selection): Add that Intent o Section 5.3 (candidate ACP neighbor selection): Add that Intent
can override only AFTER an initial default ACP establishment. can override only AFTER an initial default ACP establishment.
o Section 6.10.1 (addressing): State that addresses in the ACP are o Section 6.10.1 (addressing): State that addresses in the ACP are
permanent, and do not support temporary addresses as defined in permanent, and do not support temporary addresses as defined in
RFC4941. RFC4941.
o Modified Section 6.3 to point to the GRASP objective defined in o Modified Section 6.3 to point to the GRASP objective defined in
draft-carpenter-anima-ani-objectives. (and added that reference) draft-carpenter-anima-ani-objectives. (and added that reference)
skipping to change at page 109, line 33 skipping to change at page 98, line 33
cloud could be automated. cloud could be automated.
o Added a CRL check in Section 6.7. o Added a CRL check in Section 6.7.
o Added a note on the possibility of source-address spoofing into o Added a note on the possibility of source-address spoofing into
the security considerations section. the security considerations section.
o Other editoral changes, including those proposed by Michael o Other editoral changes, including those proposed by Michael
Richardson on 30 Nov 2016 (see ANIMA list). Richardson on 30 Nov 2016 (see ANIMA list).
15.12. draft-ietf-anima-autonomic-control-plane-06 14.12. draft-ietf-anima-autonomic-control-plane-06
o Added proposed RPL profile. o Added proposed RPL profile.
o detailed DTLS profile - DTLS with any additional negotiation/ o detailed DTLS profile - DTLS with any additional negotiation/
signaling channel. signaling channel.
o Fixed up text for ACP/GRE encap. Removed text claiming its o Fixed up text for ACP/GRE encap. Removed text claiming its
incompatible with non-GRE IPsec and detailled it. incompatible with non-GRE IPsec and detailled it.
o Added text to suggest admin down interfaces should still run ACP. o Added text to suggest admin down interfaces should still run ACP.
15.13. draft-ietf-anima-autonomic-control-plane-07 14.13. draft-ietf-anima-autonomic-control-plane-07
o Changed author association. o Changed author association.
o Improved ACP connect setion (after confusion about term came up in o Improved ACP connect setion (after confusion about term came up in
the stable connectivity draft review). Added picture, defined the stable connectivity draft review). Added picture, defined
complete terminology. complete terminology.
o Moved ACP channel negotiation from normative section to appendix o Moved ACP channel negotiation from normative section to appendix
because it can in the timeline of this document not be fully because it can in the timeline of this document not be fully
specified to be implementable. Aka: work for future document. specified to be implementable. Aka: work for future document.
skipping to change at page 111, line 29 skipping to change at page 100, line 29
do not specify which one is to be used but that the ACP should be do not specify which one is to be used but that the ACP should be
used to reach the URL included in the certificate to get to the used to reach the URL included in the certificate to get to the
CRL storage or OCSP server. CRL storage or OCSP server.
o Changed ACP via IPsec to ACP via IKEv2 and restructured the o Changed ACP via IPsec to ACP via IKEv2 and restructured the
sections to make IPsec native and IPsec via GRE subsections. sections to make IPsec native and IPsec via GRE subsections.
o No need for any assigned DTLS port if ACP is run across DTLS o No need for any assigned DTLS port if ACP is run across DTLS
because it is signaled via GRASP. because it is signaled via GRASP.
15.14. draft-ietf-anima-autonomic-control-plane-08 14.14. draft-ietf-anima-autonomic-control-plane-08
Modified mentioning of BRSKI to make it consistent with current Modified mentioning of BRSKI to make it consistent with current
(07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices (07/2017) target for BRSKI: MASA and IDevID are mandatory. Devices
with only insecure UDI would need a security reduced variant of with only insecure UDI would need a security reduced variant of
BRSKI. Also added mentioning of Netconf Zero-Touch. Made BRSKI non- BRSKI. Also added mentioning of Netconf Zero-Touch. Made BRSKI non-
normative for ACP because wrt. ACP it is just one option how the normative for ACP because wrt. ACP it is just one option how the
domain certificate can be provisioned. Instead, BRSKI is mandatory domain certificate can be provisioned. Instead, BRSKI is mandatory
when a device implements ANI which is ACP+BRSKI. when a device implements ANI which is ACP+BRSKI.
Enhanced text for ACP across tunnels to decribe two options: one Enhanced text for ACP across tunnels to decribe two options: one
skipping to change at page 113, line 5 skipping to change at page 102, line 5
domain" is. Scheme is called "routing subdomain" to have a unique domain" is. Scheme is called "routing subdomain" to have a unique
name. name.
Added V8 (now called Vlong) addressing sub-scheme according to Added V8 (now called Vlong) addressing sub-scheme according to
suggestion from mcr in his mail from 30 Nov 2016 suggestion from mcr in his mail from 30 Nov 2016
(https://mailarchive.ietf.org/arch/msg/anima/ (https://mailarchive.ietf.org/arch/msg/anima/
nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the nZpEphrTqDCBdzsKMpaIn2gsIzI). Also modified the explanation of the
single V bit in the first sub-scheme now renamed to Zone sub-scheme single V bit in the first sub-scheme now renamed to Zone sub-scheme
to distinguish it. to distinguish it.
15.15. draft-ietf-anima-autonomic-control-plane-09 14.15. draft-ietf-anima-autonomic-control-plane-09
Added reference to RFC4191 and explained how it should be used on ACP Added reference to RFC4191 and explained how it should be used on ACP
edge routers to allow auto configuration of routing by NMS hosts. edge routers to allow auto configuration of routing by NMS hosts.
This came after review of stable connectivity draft where ACP connect This came after review of stable connectivity draft where ACP connect
is being referred to. is being referred to.
V8 addressing Sub-Scheme was modified to allow not only /8 device- V8 addressing Sub-Scheme was modified to allow not only /8 device-
local address space but also /16. This was in response to the local address space but also /16. This was in response to the
possible need to have maybe as much as 2^12 local addresses for possible need to have maybe as much as 2^12 local addresses for
future encaps in BRSKI like IPinIP. It also would allow fully future encaps in BRSKI like IPinIP. It also would allow fully
skipping to change at page 115, line 5 skipping to change at page 104, line 5
revocation. revocation.
Added fixes from 08-mcr-review-reply.txt (on github): Added fixes from 08-mcr-review-reply.txt (on github):
o AN Domain Names are FQDNs. o AN Domain Names are FQDNs.
o Fixed bit length of schemes, numerical writing of bits (00b/01b). o Fixed bit length of schemes, numerical writing of bits (00b/01b).
o Lets use US american english. o Lets use US american english.
15.16. draft-ietf-anima-autonomic-control-plane-10 14.16. draft-ietf-anima-autonomic-control-plane-10
Used the term routing subdomain more consistently where previously Used the term routing subdomain more consistently where previously
only subdomain was used. Clarified use of routing subdomain in only subdomain was used. Clarified use of routing subdomain in
creation of ULA "global ID" addressing prefix. creation of ULA "global ID" addressing prefix.
6.7.1.* Changed native IPsec encapsulation to tunnel mode 6.7.1.* Changed native IPsec encapsulation to tunnel mode
(necessary), explaned why. Added notion that ESP is used, added (necessary), explaned why. Added notion that ESP is used, added
explanations why tunnel/transport mode in native vs. GRE cases. explanations why tunnel/transport mode in native vs. GRE cases.
6.10.3/6.10.5 Added term "ACP address range/set" to be able to better 6.10.3/6.10.5 Added term "ACP address range/set" to be able to better
skipping to change at page 116, line 44 skipping to change at page 105, line 44
specified what needs to be done (e.g., in 2 switches doing ACP per L2 specified what needs to be done (e.g., in 2 switches doing ACP per L2
port). port).
12. Added explanations and cross-references to various security 12. Added explanations and cross-references to various security
aspects of ACP discussed elsewhere in the document. aspects of ACP discussed elsewhere in the document.
13. Added IANA requirements. 13. Added IANA requirements.
Added RFC2119 boilerplate. Added RFC2119 boilerplate.
15.17. draft-ietf-anima-autonomic-control-plane-11 14.17. draft-ietf-anima-autonomic-control-plane-11
Same text as -10 Unfortunately when uploading -10 .xml/.txt to Same text as -10 Unfortunately when uploading -10 .xml/.txt to
datatracker, a wrong version of .txt got uploaded, only the .xml was datatracker, a wrong version of .txt got uploaded, only the .xml was
correct. This impacts the -10 html version on datatra cker and the correct. This impacts the -10 html version on datatra cker and the
PDF versions as well. Because rfcdiff also compares the .txt PDF versions as well. Because rfcdiff also compares the .txt
version, this -11 version was crea ted so that one can compare version, this -11 version was crea ted so that one can compare
changes from -09 and changes to the next version (-12). changes from -09 and changes to the next version (-12).
15.18. draft-ietf-anima-autonomic-control-plane-12 14.18. draft-ietf-anima-autonomic-control-plane-12
Sheng Jiangs extensive review. Thanks! See Github file draft-ietf- Sheng Jiangs extensive review. Thanks! See Github file draft-ietf-
anima-autonomic-control-plane/09-sheng-review-reply.txt for more anima-autonomic-control-plane/09-sheng-review-reply.txt for more
details. Many of the larger changes listed below where inspired by details. Many of the larger changes listed below where inspired by
the review. the review.
Removed the claim that the document is updating RFC4291,RFC4193 and Removed the claim that the document is updating RFC4291,RFC4193 and
the section detailling it. Done on suggestion of Michael Richardson the section detailling it. Done on suggestion of Michael Richardson
- just try to describe use of addressing in a way that would not - just try to describe use of addressing in a way that would not
suggest a need claim update to architecture. suggest a need claim update to architecture.
skipping to change at page 118, line 33 skipping to change at page 107, line 33
10.3 Introduced informational section (enabling/disabling) ACP. 10.3 Introduced informational section (enabling/disabling) ACP.
Important to discuss this for security reasons (e.g., why to never Important to discuss this for security reasons (e.g., why to never
never auto-enable ANI on brownfield devices), for implementers and to never auto-enable ANI on brownfield devices), for implementers and to
answer ongoing questions during WG meetings about how to deal with answer ongoing questions during WG meetings about how to deal with
shutdown interface. shutdown interface.
10.8 Added informational section discussing possible future 10.8 Added informational section discussing possible future
variations of the ACP for potential adopters that cannot directly use variations of the ACP for potential adopters that cannot directly use
the complete solution described in this document unmodified. the complete solution described in this document unmodified.
15.19. draft-ietf-anima-autonomic-control-plane-13 14.19. draft-ietf-anima-autonomic-control-plane-13
Swap author list (with permission). Swap author list (with permission).
6.1.1. Eliminate blank lines in definition by making it a picture 6.1.1. Eliminate blank lines in definition by making it a picture
(reformatting only). (reformatting only).
6.10.3.1 New paragraph: Explained how nodes using Zone-ID != 0 need 6.10.3.1 New paragraph: Explained how nodes using Zone-ID != 0 need
to use Zone-ID != 0 in GRASP so that we can avoid routing/forwarding to use Zone-ID != 0 in GRASP so that we can avoid routing/forwarding
of Zone-ID = 0 prefixes. of Zone-ID = 0 prefixes.
skipping to change at page 120, line 29 skipping to change at page 109, line 29
6.10.1 Removed comment about assigned ULA addressing. Decision not 6.10.1 Removed comment about assigned ULA addressing. Decision not
to use it now ancient history of WG decision making process, not to use it now ancient history of WG decision making process, not
worth nothing anymore in the RFC. worth nothing anymore in the RFC.
Review from Yongkang Zhang: Review from Yongkang Zhang:
6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub- 6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub-
Scheme. Scheme.
15.20. draft-ietf-anima-autonomic-control-plane-14 14.20. draft-ietf-anima-autonomic-control-plane-14
Disclaimer: All new text introduced by this revision provides only Disclaimer: All new text introduced by this revision provides only
additional explanations/ details based on received reviews and additional explanations/ details based on received reviews and
analysis by the authors. No changes to beavior already specified in analysis by the authors. No changes to beavior already specified in
prior revisions. prior revisions.
Joel Halpern, review part 3: Joel Halpern, review part 3:
Define/explain "ACP registrar" in reply to Joel Halpern review part Define/explain "ACP registrar" in reply to Joel Halpern review part
3, resolving primarily 2 documentation issues:: 3, resolving primarily 2 documentation issues::
skipping to change at page 124, line 28 skipping to change at page 113, line 28
6.12.5 Clarified how link-local ACP channel address can be derived, 6.12.5 Clarified how link-local ACP channel address can be derived,
and how not. and how not.
8.2.1 Fixed up text to distinguish between configuration and model 8.2.1 Fixed up text to distinguish between configuration and model
describing parameters of the configuration (spec only provides describing parameters of the configuration (spec only provides
parameter model). parameter model).
Various Nits. Various Nits.
15.21. draft-ietf-anima-autonomic-control-plane-15 14.21. draft-ietf-anima-autonomic-control-plane-15
Only reshuffling and formatting changes, but wanted to allow Only reshuffling and formatting changes, but wanted to allow
reviewers later to easily compare -13 with -14, and these changes in reviewers later to easily compare -13 with -14, and these changes in
-15 mess that up too much. -15 mess that up too much.
increased TOC depth to 4. increased TOC depth to 4.
Separated and reordered section 10 into an operational and a Separated and reordered section 10 into an operational and a
background and futures section. The background and futures could background and futures section. The background and futures could
also become appendices if the layout of appendices in RFC format also become appendices if the layout of appendices in RFC format
wasn't so horrible that you really only want to avoid using them (all wasn't so horrible that you really only want to avoid using them (all
the way after a lot of text like references that stop most readers the way after a lot of text like references that stop most readers
from proceeding any further). from proceeding any further).
15.22. wish-list 14.22. draft-ietf-anima-autonomic-control-plane-16
Mirja Kuehlewind:
Tightened requirements for ACP related GRASP objective timers.
Better text to introduce/explaine baseline and constrained ACP
profiles.
IANA guideline: MUST only accept extensible last allocation for
address sub-scheme.
Moved section 11 into appendix.
Warren Kumari:
Removed "global routing table", replacced with "Data-Plane routing
(and forwarding) tables.
added text to indicate how routing protocols do like to have data-
plane dependencies.
Changed power consumption section re. admin-down state. Power needed
to bring up such interfaces make t inappropriate to probe. Need to
think more about best sugests -> beyond scope.
Replaced "console" with out-of-band... (console/management ethernet).
Various nits.
Joel Halpern:
Fixed up domain information field ABNF to eliminate confusion that
rsub is not an FQDN but only a prefix to routing-subdomain.
Corrected certcheck to separate out cert verification into lifetime
validity and proof of ownership of private key.
Fixed pagination for "ACP as security and transport substrate for
GRASP" picture.
14.23. wish-list
From -13 review from Pascal Thubert: Picture to show dual-NOC routing From -13 review from Pascal Thubert: Picture to show dual-NOC routing
limitation. limitation.
[RFC Editor: Question: Is it possible to change the first occurences [RFC Editor: Question: Is it possible to change the first occurences
of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC of [RFCxxxx] references to "rfcxxx title" [RFCxxxx]? the XML2RFC
format does not seem to offer such a format, but i did not want to format does not seem to offer such a format, but i did not want to
duplicate 50 first references to be duplicate - one reference for duplicate 50 first references to be duplicate - one reference for
title mentioning and one for RFC number.] title mentioning and one for RFC number.]
16. References 15. References
15.1. Normative References
16.1. Normative References
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR data structures", draft-ietf-cbor-cddl-02 express CBOR data structures", draft-ietf-cbor-cddl-02
skipping to change at page 127, line 24 skipping to change at page 117, line 19
[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>.
16.2. Informative References 15.2. Informative References
[AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and [AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
skipping to change at page 127, line 52 skipping to change at page 117, line 47
[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-06 (work in
progress), February 2018. progress), February 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, "Zero Touch
Provisioning for Networking Devices", draft-ietf-netconf- Provisioning for Networking Devices", draft-ietf-netconf-
zerotouch-21 (work in progress), March 2018. zerotouch-22 (work in progress), June 2018.
[I-D.ietf-roll-applicability-template] [I-D.ietf-roll-applicability-template]
Richardson, M., "ROLL Applicability Statement Template", Richardson, M., "ROLL Applicability Statement Template",
draft-ietf-roll-applicability-template-09 (work in draft-ietf-roll-applicability-template-09 (work in
progress), May 2016. progress), May 2016.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-23 (work in progress), May 2018. useofrplinfo-23 (work in progress), May 2018.
skipping to change at page 131, line 41 skipping to change at page 121, line 41
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)", Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018, RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>. <https://www.rfc-editor.org/info/rfc8368>.
Appendix A. Background and Futures (Informative)
The following sections discuss additional background information
about aspects of the normative parts of this document or associated
mechanisms such as BRSKI (such as why specific choices where made by
the ACP) and they provide discussion about possble future variations
of the ACP.
A.1. ACP Address Space Schemes
This document defines the Zone, Vlong and Manual sub address schemes
primarily to support address prefix assignment via distributed,
potentially uncoordinated ACP registrars as defined in
Section 6.10.7. This costs 48/46 bit identifier so that these ACP
registrar can assign non-conflicting address prefixes. This design
does not leave enough bits to simultaneously support a large number
of nodes (Node-ID) plus a large prefix of local addresses for every
node plus a large enough set of bits to identify a routing Zone. In
result, Zone, Vlong 8/16 attempt to support all features, but in via
separate prefixes.
In networks that always expect to rely on a centralized PMS as
described above (Section 10.2.5), the 48/46 bits for the Registrar-ID
could be saved. Such variations of the ACP addressing mecchanisms
could be introduct through future work in different ways. If the
prefix rfcSELF in the ACP information field was changed, incompatible
ACP variations could be created where every design aspect of the ACP
could be changed. Including all addressing choices. If instead a
new addressing sub-type would be defined, it could be a backward
compatible extension of this ACP specification. Information such as
the size of a zone-prefix and the length of the prefix assigned to
the ACP node itself could be encoded via the extension field of the
ACP domain information.
Note that an explicitly defined "Manual" addressing sub-scheme is
always beneficial to provide an easy way for ACP nodes to prohibit
incorrect manual configuration of any non-"Manual" ACP address spaces
and therefore ensure hat "Manual" operations will never impact
correct routing for any non-"Manual" ACP addresses assigned via ACP
domain certificates.
A.2. BRSKI Bootstrap (ANI)
[I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how nodes
with an IDevID certificate can securely and zero-touch enroll with a
domain certificate (LDevID) to support the ACP. BRSKI also leverages
the ACP to enable zero-touch bootstrap of new nodes across networks
without any configuration requirements across the transit nodes
(e.g., no DHCP/DNS forwarding/server setup). This includes otherwise
not configured networks as described in Section 3.2. Therefore BRSKI
in conjunction with ACP provides for a secure and zero-touch
management solution for complete networks. Nodes supporting such an
infrastructure (BRSKI and ACP) are called ANI nodes (Autonomic
Networking Infrastructure), see [I-D.ietf-anima-reference-model].
Nodes that do not support an IDevID but only an (insecure) vendor
specific Unique Device Identifier (UDI) or nodes whose manufacturer
does not support a MASA could use some future security reduced
version of BRSKI.
When BRSKI is used to provision a domain certificate (which is called
enrollment), the BRSKI registrar (acting as an enhanced EST server)
must include the subjectAltName / rfc822Name encoded ACP address and
domain name to the enrolling node (called pledge) via its response to
the pledges EST CSR Attribute request that is mandatory in BRSKI.
The Certificate Authority in an ACP network must not change the
subjectAltName / rfc822Name in the certificate. The ACP nodes can
therefore find their ACP address and domain using this field in the
domain certificate, both for themselves, as well as for other nodes.
The use of BRSKI in conjunction with the ACP can also help to further
simplify maintenance and renewal of domain certificates. Instead of
relying on CRL, the lifetime of certificates can be made extremely
small, for example in the order of hours. When a node fails to
connect to the ACP within its certificate lifetime, it cannot connect
to the ACP to renew its certificate across it (using just EST), but
it can still renew its certificate as an "enrolled/expired pledge"
via the BRSKI bootstrap proxy. This requires only that the BRSKI
registrar honors expired domain certificates and that the pledge
first attempts to perform TLS authentication for BRSKI bootstrap with
its expired domain certificate - and only reverts to its IDevID when
this fails. This mechanism could also render CRLs unnecessary
because the BRSKI registrar in conjunction with the CA would not
renew revoked certificates - only a "Do-not-renew" list would be
necessary on BRSKI registrars/CA.
In the absence of BRSKI or less secure variants thereof, provisioning
of certificates may involve one or more touches or non-standardized
automation. Node vendors usually support provisioning of
certificates into nodes via PKCS#7 (see [RFC2315]) and may support
this provisioning through vendor specific models via Netconf
([RFC6241]). If such nodes also support Netconf Zero-Touch
([I-D.ietf-netconf-zerotouch]) then this can be combined to zero-
touch provisioning of domain certificates into nodes. Unless there
are equivalent integration of Netconf connections across the ACP as
there is in BRSKI, this combination would not support zero-touch
bootstrap across a not configured network though.
A.3. ACP Neighbor discovery protocol selection
This section discusses why GRASP DULL was chosen as the discovery
protocol for L2 adjacent candidate ACP neighbors. The contenders
considered where GRASP, mDNS or LLDP.
A.3.1. LLDP
LLDP and Cisco's earlier Cisco Discovery Protocol (CDP) are example
of L2 discovery protocols that terminate their messages on L2 ports.
If those protocols would be chosen for ACP neighbor discovery, ACP
neighbor discovery would therefore also terminate on L2 ports. This
would prevent ACP construction over non-ACP capable but LLDP or CDP
enabled L2 switches. LLDP has extensions using different MAC
addresses and this could have been an option for ACP discovery as
well, but the additional required IEEE standardization and definition
of a profile for such a modified instance of LLDP seemed to be more
work than the benefit of "reusing the existing protocol" LLDP for
this very simple purpose.
A.3.2. mDNS and L2 support
Multicast DNNS (mDNS) [RFC6762] with DNS Service Discovery (DNS-SD)
Resource Records (RRs) as defined in [RFC6763] is a key contender as
an ACP discovery protocol. because it relies on link-local IP
multicast, it does operates at the subnet level, and is also found in
L2 switches. The authors of this document are not aware of mDNS
implementation that terminate their mDNS messages on L2 ports instead
of the subnet level. If mDNS was used as the ACP discovery mechanism
on an ACP capable (L3)/L2 switch as outlined in Section 7, then this
would be necessary to implement. It is likely that termination of
mDNS messages could only be applied to all mDNS messages from such a
port, which would then make it necessary to software forward any non-
ACP related mDNS messages to maintain prior non-ACP mDNS
functionality. Adding support for ACP into such L2 switches with
mDNS could therefore create regression problems for prior mDNS
functionality on those nodes. With low performance of software
forwarding in many L2 switches, this could also make the ACP risky to
support on such L2 switches.
A.3.3. Why DULL GRASP
LLDP was not considered because of the above mentioned issues. mDNS
was not selected because of the above L2 mDNS considerations and
because of the following additional points:
If mDNS was not already existing in a node, it would be more work to
implement than DULL GRASP, and if an existing implementation of mDNS
was used, it would likely be more code space than a separate
implementation of DULL GRASP or a shared implementation of DULL GRASP
and GRASP in the ACP.
A.4. Choice of routing protocol (RPL)
This section motivates why RPL - "IPv6 Routing Protocol for Low-Power
and Lossy Networks ([RFC6550] was chosen as the default (and in this
specification only) routing protocol for the ACP. The choice and
above explained profile was derived from a pre-standard
implementation of ACP that was successfully deployed in operational
networks.
Requirements for routing in the ACP are:
o Self-management: The ACP must build automatically, without human
intervention. Therefore routing protocol must also work
completely automatically. RPL is a simple, self-managing
protocol, which does not require zones or areas; it is also self-
configuring, since configuration is carried as part of the
protocol (see Section 6.7.6 of [RFC6550]).
o Scale: The ACP builds over an entire domain, which could be a
large enterprise or service provider network. The routing
protocol must therefore support domains of 100,000 nodes or more,
ideally without the need for zoning or separation into areas. RPL
has this scale property. This is based on extensive use of
default routing. RPL also has other scalability improvements,
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
infrastructure, thus runs in addition to traditional protocols.
The ACP, and specifically the routing protocol must have low
resource consumption both in terms of memory and CPU requirements.
Specifically, at edge nodes, where memory and CPU are scarce,
consumption should be minimal. RPL builds a destination-oriented
directed acyclic graph (DODAG), where the main resource
consumption is at the root of the DODAG. The closer to the edge
of the network, the less state needs to be maintained. This
adapts nicely to the typical network design. Also, all changes
below a common parent node are kept below that parent node.
o Support for unstructured address space: In the Autonomic
Networking Infrastructure, node addresses are identifiers, and may
not be assigned in a topological way. Also, nodes may move
topologically, without changing their address. Therefore, the
routing protocol must support completely unstructured address
space. RPL is specifically made for mobile ad-hoc networks, with
no assumptions on topologically aligned addressing.
o Modularity: To keep the initial implementation small, yet allow
later for more complex methods, it is highly desirable that the
routing protocol has a simple base functionality, but can import
new functional modules if needed. RPL has this property with the
concept of "objective function", which is a plugin to modify
routing behavior.
o Extensibility: Since the Autonomic Networking Infrastructure is a
new concept, it is likely that changes in the way of operation
will happen over time. RPL allows for new objective functions to
be introduced later, which allow changes to the way the routing
protocol creates the DAGs.
o Multi-topology support: It may become necessary in the future to
support more than one DODAG for different purposes, using
different objective functions. RPL allow for the creation of
several parallel DODAGs, should this be required. This could be
used to create different topologies to reach different roots.
o No need for path optimization: RPL does not necessarily compute
the optimal path between any two nodes. However, the ACP does not
require this today, since it carries mainly non-delay-sensitive
feedback loops. It is possible that different optimization
schemes become necessary in the future, but RPL can be expanded
(see point "Extensibility" above).
A.5. ACP Information Distribution and multicast
IP multicast is not used by the ACP because the ANI (Autonomic
Networking Infrastructure) itself does not require IP multicast but
only service announcement/discovery. Using IP multicast for that
would have made it necessary to develop a zero-touch auto configuring
solution for ASM (Any Source Multicast - the original form of IP
multicast defined in [RFC1112]), which would be quite complex and
difficult to justify. One aspect of complexity where no attempt at a
solution has been described in IETF documents is the automatic-
selection of routers that should be PIM Sparse Mode (PIM-SM)
Rendezvous Points (RPs) (see [RFC7761]). The other aspects of
complexity are the implementation of MLD ([RFC4604]), PIM-SM and
Anycast-RP (see [RFC4610]). If those implementations already exist
in a product, then they would be very likely tied to accelerated
forwarding which consumes hardware resources, and that in return is
difficult to justify as a cost of performing only service discovery.
Some future ASA may need high performance in-network data
replication. That is the case when the use of IP multicast is
justified. Such an ASA can then use service discovery from ACP
GRASP, and then they do not need ASM but only SSM (Source Specific
Multicast, see [RFC4607]) for the IP multicast replication. SSM
itself can simply be enabled in the Data-Plane (or even in an update
to the ACP) without any other configuration than just enabling it on
all nodes and only requires a simpler version of MLD (see [RFC5790]).
LSP (Link State Protocol) based IGP routing protocols typically have
a mechanism to flood information, and such a mechanism could be used
to flood GRASP objectives by defining them to be information of that
IGP. This would be a possible optimization in future variations of
the ACP that do use an LSP routing protocol. Note though that such a
mechanism would not work easily for GRASP M_DISCOVERY messages which
are intelligently (constrained) flooded not across the whole ACP, but
only up to a node where a responder is found. We do expect that many
future services in ASA will have only few consuming ASA, and for
those cases, M_DISCOVERY is the more efficient method than flooding
across the whole domain.
Because the ACP uses RPL, one desirable future extension is to use
RPLs existing notion of loop-free distribution trees (DODAG) to make
GRASPs flooding more efficient both for M_FLOOD and M_DISCOVERY) See
Section 6.12.5 how this will be specifically beneficial when using
NBMA interfaces. This is not currently specified in this document
because it is not quite clear yet what exactly the implications are
to make GRASP flooding depend on RPL DODAG convergence and how
difficult it would be to let GRASP flooding access the DODAG
information.
A.6. Extending ACP channel negotiation (via GRASP)
The mechanism described in the normative part of this document to
support multiple different ACP secure channel protocols without a
single network wide MTI protocol is important to allow extending
secure ACP channel protocols beyond what is specified in this
document, but it will run into problem if it would be used for
multiple protocols:
The need to potentially have multiple of these security associations
even temporarily run in parallel to determine which of them works
best does not support the most lightweight implementation options.
The simple policy of letting one side (Alice) decide what is best may
not lead to the mutual best result.
The two limitations can easier be solved if the solution was more
modular and as few as possible initial secure channel negotiation
protocols would be used, and these protocols would then take on the
responsibility to support more flexible objectives to negotiate the
mutually preferred ACP security channel protocol.
IKEv2 is the IETF standard protocol to negotiate network security
associations. It is meant to be extensible, but it is unclear
whether it would be feasible to extend IKEv2 to support possible
future requirements for ACP secure channel negotiation:
Consider the simple case where the use of native IPsec vs. IPsec via
GRE is to be negotiated and the objective is the maximum throughput.
Both sides would indicate some agreed upon performance metric and the
preferred encapsulation is the one with the higher performance of the
slower side. IKEv2 does not support negotiation with this objective.
Consider DTLS and some form of MacSec are to be added as negotiation
options - and the performance objective should work across all IPsec,
dDTLS and MacSec options. In the case of MacSEC, the negotiation
would also need to determine a key for the peering. It is unclear if
it would be even appropriate to consider extending the scope of
negotiation in IKEv2 to those cases. Even if feasible to define, it
is unclear if implementations of IKEv2 would be eager to adopt those
type of extension given the long cycles of security testing that
necessarily goes along with core security protocols such as IKEv2
implementations.
A more modular alternative to extending IKEv2 could be to layer a
modular negotiation mechanism on top of the multitude of existing or
possible future secure channel protocols. For this, GRASP over TLS
could be considered as a first ACP secure channel negotiation
protocol. The following are initial considerations for such an
approach. A full specification is subject to a separate document:
To explicitly allow negotiation of the ACP channel protocol, GRASP
over a TLS connection using the GRASP_LISTEN_PORT and the nodes and
peers link-local IPv6 address is used. When Alice and Bob support
GRASP negotiation, they do prefer it over any other non-explicitly
negotiated security association protocol and should wait trying any
non-negotiated ACP channel protocol until after it is clear that
GRASP/TLS will not work to the peer.
When Alice and Bob successfully establish the GRASP/TSL session, they
will negotiate the channel mechanism to use using objectives such as
performance and perceived quality of the security. After agreeing on
a channel mechanism, Alice and Bob start the selected Channel
protocol. Once the secure channel protocol is successfully running,
the GRASP/TLS connection can be kept alive or timed out as long as
the selected channel protocol has a secure association between Alice
and Bob. When it terminates, it needs to be re-negotiated via GRASP/
TLS.
Notes:
o Negotiation of a channel type may require IANA assignments of code
points.
o TLS is subject to reset attacks, which IKEv2 is not. Normally,
ACP connections (as specified in this document) will be over link-
local addresses so the attack surface for this one issue in TCP
should be reduced (note that this may not be true when ACP is
tunneled as described in Section 8.2.2.
o GRASP packets received inside a TLS connection established for
GRASP/TLS ACP negotiation are assigned to a separate GRASP domain
unique to that TLS connection.
A.7. CAs, domains and routing subdomains
There is a wide range of setting up different ACP solution by
appropriately using CAs and the domain and rsub elements in the
domain information field of the domain certificate. We summarize
these options here as they have been explained in different parts of
the document in before and discuss possible and desirable extensions:
An ACP domain is the set of all ACP nodes using certificates from the
same CA using the same domain field. GRASP inside the ACP is run
across all transitively connected ACP nodes in a domain.
The rsub element in the domain information field permits the use of
addresses from different ULA prefixes. One use case is to create
multiple networks that initially may be separated, but where it
should be possible to connect them without further extensions to ACP
when necessary.
Another use case for routing subdomains is as the starting point for
structuring routing inside an ACP. For example, different routing
subdomains could run different routing protocols or different
instances of RPL and auto-aggregation / distribution of routes could
be done across inter routing subdomain ACP channels based on
negotiation (e.g., via GRASP). This is subject for further work.
RPL scales very well. It is not necessary to use multiple routing
subdomains to scale ACP domains in a way it would be possible if
other routing protocols where used. They exist only as options for
the above mentioned reasons.
If different ACP domains are to be created that should not allow to
connect to each other by default, these ACP domains simply need to
have different domain elements in the domain information field.
These domain elements can be arbitrary, including subdomains of one
another: Domains "example.com" and "research.example.com" are
separate domains if both are domain elements in the domain
information element of certificates.
It is not necessary to have a separate CA for different ACP domains:
an operator can use a single CA to sign certificates for multiple ACP
domains that are not allowed to connect to each other because the
checks for ACP adjacencies includes comparison of the domain part.
If multiple independent networks choose the same domain name but had
their own CA, these would not form a single ACP domain because of CA
mismatch. Therefore there is no problem in choosing domain names
that are potentially also used by others. Nevertheless it is highly
recommended to use domain names that one can have high probability to
be unique. It is recommended to use domain names that start with a
DNS domain names owned by the assigning organization and unique
within it. For example "acp.example.com" if you own "example.com".
Future extensions, primarily through intent can create more flexible
options how to build ACP domains.
Intent could modify the ACP connection check to permit connections
between different domains.
If different domains use the same CA one would change the ACP setup
to permit for the ACP to be established between the two ACP nodes,
but no routing nor ACP GRASP to be built across this adjacency. The
main difference over routing subdomains is to not permit for the ACP
GRASP instance to be built across the adjacency. Instead, one would
only build a point to point GRASP instance between those peers to
negotiate what type of exchanges are desired across that connection.
This would include routing negotiation, how much GRASP information to
transit and what Data-Plane forwarding should be done. This approach
could also allow for Intent to only be injected into the network from
one side and propagate via this GRASP connection.
If different domains have different CAs, they should start to trust
each other by intent injected into both domains that would add the
other domains CA as a trust point during the ACP connection setup -
and then following up with the previous point of inter-domain
connections across domains with the same CA (e.g., GRASP
negotiation).
A.8. Adopting ACP concepts for other environments
The ACP as specified in this document is very explicit about the
choice of options to allow interoperable implementations. The
choices made may not be the best for all environments, but the
concepts used by the ACP can be used to build derived solutions:
The ACP specifies the use of ULA and deriving its prefix from the
domain name so that no address allocation is required to deploy the
ACP. The ACP will equally work not using ULA but any other /50 IPv6
prefix. This prefix could simply be a configuration of the ACP
registrars (for example when using BRSKI) to enroll the domain
certificates - instead of the ACP registrar deriving the /50 ULA
prefix from the AN domain name.
Some solutions may already have an auto-addressing scheme, for
example derived from existing unique device identifiers (e.g., MAC
addresses). In those cases it may not be desirable to assign
addresses to devices via the ACP address information field in the way
described in this document. The certificate may simply serve to
identify the ACP domain, and the address field could be empty/unused.
The only fix required in the remaining way the ACP operate is to
define another element in the domain certificate for the two peers to
decide who is Alice and who is Bob during secure channel building.
Note though that future work may leverage the acp address to
authenticate "ownership" of the address by the device. If the
address used by a device is derived from some pre-existing permanent
local ID (such as MAC address), then it would be useful to store that
address in the certificate using the format of the access address
information field or in a similar way.
The ACP is defined as a separate VRF because it intends to support
well managed networks with a wide variety of configurations.
Therefore, reliable, configuration-indestructible connectivity cannot
be achieved from the Data-Plane itself. In solutions where all
transit connectivity impacting functions are fully automated
(including security), indestructible and resilient, it would be
possible to eliminate the need for the ACP to be a separate VRF.
Consider the most simple example system in which there is no separate
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
addressing for user equipment. This gap can then be closed for
example by adding a solution derived from
[I-D.ietf-anima-prefix-management].
TCP/TLS as the protocols to provide reliability and security to GRASP
in the ACP may not be the preferred choice in constrained networks.
For example, CoAP/DTLS (Constrained Application Protocol) may be
preferred where they are already used, allowing to reduce the
additional code space footprint for the ACP on those devices.
Because the transport for GRASP is not only hop-by-hop, but end-to-
end across the ACP, this would require the definition of an
incompatible variant of the ACP. Non-constrained devices could
support both variants (the ACP as defined here, and one using CoAP/
DTLS for GRASP), and the variant used in a deployment could be chosen
for example through a parameter of the domain certificate.
The routing protocol chosen by the ACP design (RPL) does explicitly
not optimize for shortest paths and fastest convergence. Variations
of the ACP may want to use a different routing protocol or introduce
more advanced RPL profiles.
Variations such as what routing protocol to use, or whether to
instantiate an ACP in a VRF or (as suggested above) as the actual
Data-Plane, can be automatically chosen in implementations built to
support multiple options by deriving them from future parameters in
the certificate. Parameters in certificates should be limited to
those that would not need to be changed more often than certificates
would need to be updated anyhow; Or by ensuring that these parameters
can be provisioned before the variation of an ACP is activated in a
node. Using BRSKI, this could be done for example as additional
follow-up signaling directly after the certificate enrollment, still
leveraging the BRSKI TLS connection and therefore not introducing any
additional connectivity requirements.
Last but not least, secure channel protocols including their
encapsulation are easily added to ACP solutions. Secure channels may
even be replaced by simple neighbor authentication to create
simplified ACP variations for environments where no real security is
required but just protection against non-malicious misconfiguration.
Or for environments where all traffic is known or forced to be end-
to-end protected and other means for infrastructure protection are
used. Any future network OAM should always use end-to-end security
anyhow and can leverage the domain certificates and is therefore not
dependent on security to be provided for by ACP secure channels.
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
Michael H. Behringer (editor) Michael H. Behringer (editor)
Email: michael.h.behringer@gmail.com Email: michael.h.behringer@gmail.com
Steinthor Bjarnason Steinthor Bjarnason
Arbor Networks Arbor Networks
2727 South State Street, Suite 200 2727 South State Street, Suite 200
Ann Arbor MI 48104 Ann Arbor MI 48104
United States United States
Email: sbjarnason@arbor.net Email: sbjarnason@arbor.net
 End of changes. 98 change blocks. 
748 lines changed or deleted 802 lines changed or added

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