draft-ietf-anima-autonomic-control-plane-12.txt   draft-ietf-anima-autonomic-control-plane-13.txt 
ANIMA WG M. Behringer, Ed. ANIMA WG T. Eckert, Ed.
Internet-Draft Internet-Draft Huawei
Intended status: Standards Track T. Eckert, Ed. Intended status: Standards Track M. Behringer, Ed.
Expires: April 15, 2018 Huawei Expires: June 20, 2018
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
October 12, 2017 December 17, 2017
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-12 draft-ietf-anima-autonomic-control-plane-13
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 OAM (Operations Administration and out of band channel" for OAM (Operations Administration and
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 April 15, 2018. This Internet-Draft will expire on June 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 6 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . 6
3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 10 3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 11
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 10 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 11
3.2. Secure Bootstrap over a not configured Network . . . . . 10 3.2. Secure Bootstrap over a not configured Network . . . . . 11
3.3. Data-Plane Independent Permanent Reachability . . . . . . 11 3.3. Data-Plane Independent Permanent Reachability . . . . . . 11
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 14 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 14
6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 14 6.1. ACP Domain, Certificate and Network . . . . . . . . . . . 15
6.1.1. Certificate Domain Information Field . . . . . . . . 15 6.1.1. Certificate Domain Information Field . . . . . . . . 16
6.1.2. ACP domain membership check . . . . . . . . . . . . . 18 6.1.2. ACP domain membership check . . . . . . . . . . . . . 18
6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 18 6.1.3. Certificate Maintenance . . . . . . . . . . . . . . . 19
6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 20 6.2. ACP Adjacency Table . . . . . . . . . . . . . . . . . . . 21
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 21 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 21
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 23 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 24
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 24 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 25
6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 26 6.6. Candidate ACP Neighbor verification . . . . . . . . . . . 26
6.7. Security Association protocols . . . . . . . . . . . . . 26 6.7. Security Association protocols . . . . . . . . . . . . . 27
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 26 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 27
6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 27 6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 28
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 28 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 28
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 28 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 29
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 28 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 29
6.8.2. ACP as the Security and Transport substrate for GRASP 29 6.8.2. ACP as the Security and Transport substrate for GRASP 30
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 33 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 33
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 33 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 34
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 33 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 34
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 35 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 35
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 35 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 36
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 38 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 39
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 39 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 40
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 40 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 41
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 40 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 41
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 41 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 42
6.12. General ACP Considerations . . . . . . . . . . . . . . . 44 6.12. General ACP Considerations . . . . . . . . . . . . . . . 45
6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 44 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 45
6.12.2. Addressing of Secure Channels in the data-plane . . 45 6.12.2. Addressing of Secure Channels in the data-plane . . 46
6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 45 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 46
6.12.4. Multiple links between nodes . . . . . . . . . . . . 46 6.12.4. Multiple links between nodes . . . . . . . . . . . . 47
6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 46 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 47
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 49 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 50
7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 50 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 51
8. Support for Non-ACP Components (Normative) . . . . . . . . . 52 8. Support for Non-ACP Components (Normative) . . . . . . . . . 53
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 52 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 53
8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 52 8.1.1. Non-ACP Controller / NMS system . . . . . . . . . . . 53
8.1.2. Software Components . . . . . . . . . . . . . . . . . 54 8.1.2. Software Components . . . . . . . . . . . . . . . . . 55
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 55 8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 56
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 56 8.1.4. Combined ACP/Data-Plane Interface (VRF Select) . . . 57
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 57 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 58
8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 58 8.2. ACP through Non-ACP L3 Clouds (Remote ACP neighbors) . . 59
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 58 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 59
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 59 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 61
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 60 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 61
9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 60 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 61
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 60 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 61
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 61 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 63
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 61 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 63
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 62 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 63
9.3. The Administrator View . . . . . . . . . . . . . . . . . 63 9.3. The Administrator View . . . . . . . . . . . . . . . . . 64
10. Further Considerations (Informative) . . . . . . . . . . . . 63 10. Further Considerations (Informative) . . . . . . . . . . . . 65
10.1. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . 63 10.1. BRSKI Bootstrap (ANI) . . . . . . . . . . . . . . . . . 65
10.2. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 65 10.2. ACP (and BRSKI) Diagnostics . . . . . . . . . . . . . . 66
10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 69 10.3. Enabling and disabling ACP/ANI . . . . . . . . . . . . . 71
10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 70 10.3.1. Filtering for non-ACP/ANI packets . . . . . . . . . 71
10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 70 10.3.2. Admin Down State . . . . . . . . . . . . . . . . . . 72
10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 73 10.3.3. Interface level ACP/ANI enable . . . . . . . . . . . 74
10.3.4. Which interfaces to auto-enable ? . . . . . . . . . 73 10.3.4. Which interfaces to auto-enable ? . . . . . . . . . 75
10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 75 10.3.5. Node Level ACP/ANI enable . . . . . . . . . . . . . 76
10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 76 10.3.6. Undoing ANI/ACP enable . . . . . . . . . . . . . . . 78
10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 77 10.3.7. Summary . . . . . . . . . . . . . . . . . . . . . . 78
10.4. ACP Neighbor discovery protocol selection . . . . . . . 77 10.4. ACP Neighbor discovery protocol selection . . . . . . . 78
10.4.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 77 10.4.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 79
10.4.2. mDNS and L2 support . . . . . . . . . . . . . . . . 78 10.4.2. mDNS and L2 support . . . . . . . . . . . . . . . . 79
10.4.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 78 10.4.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 79
10.5. Choice of routing protocol (RPL) . . . . . . . . . . . . 78 10.5. Choice of routing protocol (RPL) . . . . . . . . . . . . 80
10.6. Extending ACP channel negotiation (via GRASP) . . . . . 80 10.6. Extending ACP channel negotiation (via GRASP) . . . . . 81
10.7. CAs, domains and routing subdomains . . . . . . . . . . 81 10.7. CAs, domains and routing subdomains . . . . . . . . . . 83
10.8. Adopting ACP concepts for other environments . . . . . . 83 10.8. Adopting ACP concepts for other environments . . . . . . 84
11. Security Considerations . . . . . . . . . . . . . . . . . . . 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 86
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 87
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 87 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 87 14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 88
14.1. Initial version . . . . . . . . . . . . . . . . . . . . 87 14.1. Initial version . . . . . . . . . . . . . . . . . . . . 88
14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 87 14.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 88
14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 87 14.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 88
14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 88 14.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 89
14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 88 14.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 89
14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 88 14.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 89
14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 88 14.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 89
14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 89 14.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 90
14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 89 14.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 90
14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 90 14.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 91
14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 90 14.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 91
14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 91 14.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 92
14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 91 14.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 92
14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 93 14.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 94
14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 94 14.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 95
14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 96 14.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 97
14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 98 14.17. draft-ietf-anima-autonomic-control-plane-11 . . . . . . 99
14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 98 14.18. draft-ietf-anima-autonomic-control-plane-12 . . . . . . 99
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 100 14.19. draft-ietf-anima-autonomic-control-plane-13 . . . . . . 101
15.1. Normative References . . . . . . . . . . . . . . . . . . 100 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 103
15.2. Informative References . . . . . . . . . . . . . . . . . 102 15.1. Normative References . . . . . . . . . . . . . . . . . . 103
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105 15.2. Informative References . . . . . . . . . . . . . . . . . 105
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 109
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 currently being defined in the Autonomic Networking in the IETF is currently being defined in the
document [I-D.ietf-anima-reference-model] document [I-D.ietf-anima-reference-model]
Autonomic functions need an autonomously built communications Autonomic functions need an autonomically built communications
infrastructure or network plane (there is no well-established name infrastructure or network plane (there is no well-established name
for this). This infrastructure needs to be secure, resilient and re- for this). This infrastructure needs to be secure, resilient and re-
usable by all autonomic functions. Section 5 of [RFC7575] introduces usable by all autonomic functions. Section 5 of [RFC7575] introduces
that infrastructure and calls it the "Autonomic Control Plane" (ACP). that infrastructure and calls it the "Autonomic Control Plane" (ACP).
More descriptively it would be the "Autonomic communications More descriptively it would be the "Autonomic communications
infrastructure for Management and Control". For naming consistency infrastructure for Management and Control". For naming consistency
with that prior document, this document continues to use the name ACP with that prior document, this document continues to use the name ACP
though. though.
Today, the management and control plane of networks typically runs in Today, the management and control plane of networks typically runs in
skipping to change at page 5, line 50 skipping to change at page 6, line 4
in between is not yet configured; no data-plane dependent in between is not yet configured; no data-plane dependent
bootstrap configuration is required. An example of such a secure bootstrap configuration is required. An example of such a secure
bootstrap process is described in bootstrap process is described in
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
This document describes these use cases for the ACP in Section 3, it This document describes these use cases for the ACP in Section 3, it
defines the requirements in Section 4. Section 5 gives an overview defines the requirements in Section 4. Section 5 gives an overview
how the ACP is constructed, and in Section 6 the process is defined how the ACP is constructed, and in Section 6 the process is defined
in detail. Section 7 defines how to support ACP on L2 switches. in detail. Section 7 defines how to support ACP on L2 switches.
Section 8 explains how non-ACP nodes and networks can be integrated. Section 8 explains how non-ACP nodes and networks can be integrated.
The following sections are non-normative: Section 7 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 additional explanations and describes additional details or provides additional explanations and describes additional details or
future work possibilities that where considered not to be appropriate future work possibilities that where considered not to be appropriate
for standardization in this document but nevertheless assumed to be for standardization in this document but nevertheless assumed to be
helpful for candidate adopters of the ACP. helpful for candidate adopters of the ACP.
The ACP as defined in this document can be implemented and operated The ACP as defined in this document can be implemented and operated
without dependency against other components of autonomous networks without dependency against other components of autonomic networks
except for the GRASP protocol on which it depends. The document except for the GRASP protocol on which it depends. The document
"Autonomic Network Stable Connectivity" "Autonomic Network Stable Connectivity"
[I-D.ietf-anima-stable-connectivity] describes how the ACP alone can [I-D.ietf-anima-stable-connectivity] describes how the ACP alone can
be used to provide stable connectivity for autonomic and non- be used to provide stable connectivity for autonomic and non-
autonomic OAM applications ("Operations Administration and autonomic OAM applications ("Operations Administration and
Management"). It also explains on how existing management solutions Management"). It also explains on how existing management solutions
can leverage the ACP in parallel with traditional management models, can leverage the ACP in parallel with traditional management models,
when to use the ACP and, how to integrate IPv4 based management, etc. when to use the ACP and, how to integrate IPv4 based management, etc.
Combining ACP with BRSKI ("Bootstrapping Remote Secure Key Combining ACP with BRSKI ("Bootstrapping Remote Secure Key
skipping to change at page 6, line 43 skipping to change at page 6, line 47
In the rest of the document we will refer to systems using the ACP as In the rest of the document we will refer to systems using the ACP as
"nodes". Typically such a node is a physical (network equipment) "nodes". Typically such a node is a physical (network equipment)
device, but it can equally be some virtualized system. Therefore, we device, but it can equally be some virtualized system. Therefore, we
do not refer to them as devices unless the context specifically calls do not refer to them as devices unless the context specifically calls
for a physical system. for a physical system.
This document introduces or uses the following terms (sorted This document introduces or uses the following terms (sorted
alphabetically). Terms introduced are explained on first use, so alphabetically). Terms introduced are explained on first use, so
this list is for reference only. this list is for reference only.
ACP: "Autonomic Control Plane". The Autonomic Function defined in ACP: "Autonomic Control Plane". The Autonomic Function as defined
this document. It provides secure zero-touch transitive (network in this document. It provides secure zero-touch transitive
wide) IPv6 connectivity for all nodes in the same ACP domain. The (network wide) IPv6 connectivity for all nodes in the same ACP
ACP is primarily meant to be used as a component of the ANI to domain as well as a GRASP instance running across this ACP IPv6
enable Autonomic Networks but it can equally be used in simple ANI connectivity. The ACP is primarily meant to be used as a
networks (with no other Autonomic Functions) or completely by component of the ANI to enable Autonomic Networks but it can
itself. equally be used in simple ANI networks (with no other Autonomic
Functions) or completely by itself.
ACP address: An IPv6 address assigned to the ACP node. It is stored ACP address: An IPv6 address assigned to the ACP node. It is stored
in the domain information field of the ACP domain certificate. in the domain information field of the ACP domain certificate
(Paragraph 21).
ACP address range/set: The ACP address may imply a range or set of ACP address range/set: The ACP address may imply a range or set of
addresses that the node can assign for different purposes. This addresses that the node can assign for different purposes. This
address range/set is derived by the node from the format of the address range/set is derived by the node from the format of the
ACP address called the "addressing sub-scheme". ACP address called the "addressing sub-scheme".
ACP connect: An interface on an ACP node providing access to the ACP ACP connect: An interface on an ACP node providing access to the ACP
for non ACP capable nodes without using an ACP secure channel. for non ACP capable nodes without using an ACP secure channel.
See Section 8.1.1. See Section 8.1.1.
ACP domain: The ACP domain is the set of nodes with domain ACP domain: The ACP domain is the set of nodes with domain
certificates that allow them to authenticate each other as members certificates that allow them to authenticate each other as members
of the ACP domain. See Section 6.1.2. of the ACP domain. See Section 6.1.2.
domain information (field): An rfc822Name information element (e.g.: domain information (field): An rfc822Name information element (e.g.:
field) in the domain certificate in which the ACP relevant field) in the domain certificate in which the ACP relevant
information is encoded: the domain name and the ACP address. information is encoded: the domain name and the ACP address.
ACP loopback interface: The interface in the ACP VRF that has the ACP loopback interface: The loopback interface in the ACP VRF that
ACP address assigned to it. has the ACP address assigned to it.
ACP network: The ACP network constitutes all the nodes that have ACP network: The ACP network constitutes all the nodes that have
access to the ACP. It is the set of active and transitively access to the ACP. It is the set of active and transitively
connected nodes of an ACP domain plus all nodes that get access to connected nodes of an ACP domain plus all nodes that get access to
the ACP of that domain via ACP edge nodes. the ACP of that domain via ACP edge nodes.
ACP (ULA) prefix(es): The prefixes routed across the ACP. In the ACP (ULA) prefix(es): The prefixes routed across the ACP. In the
normal/simple case, the ACP has one ULA prefix, see Section 6.10. normal/simple case, the ACP has one ULA prefix, see Section 6.10.
The ACP routing table may include multiple ULA prefixes if the The ACP routing table may include multiple ULA prefixes if the
"rsub" option is used to create addresses from more than one ULA "rsub" option is used to create addresses from more than one ULA
skipping to change at page 9, line 30 skipping to change at page 9, line 34
IDevID: An "Initial Device IDentity" X.509 certificate installed by IDevID: An "Initial Device IDentity" X.509 certificate installed by
the vendor on new equipment. Contains information that the vendor on new equipment. Contains information that
establishes the identity of the node in the context of its vendor/ establishes the identity of the node in the context of its vendor/
manufacturer such as device model/type and serial number. See manufacturer such as device model/type and serial number. See
[AR8021]. [AR8021].
Intent: Northbound operator and automation facing interface of an Intent: Northbound operator and automation facing interface of an
Autonomic Network according to [I-D.ietf-anima-reference-model]. Autonomic Network according to [I-D.ietf-anima-reference-model].
loopback interface: The conventional name for an internal IP
interface to which addresses may be assigned, but which transmits
no external traffic.
LDevID: A "Local Device IDentity" is an X.509 certificate installed LDevID: A "Local Device IDentity" is an X.509 certificate installed
during "enrollment". The Domain Certificate used by the ACP is an during "enrollment". The Domain Certificate used by the ACP is an
LDevID. See [AR8021]. LDevID. See [AR8021].
MIC: "Manufacturer Installed Certificate". Another word not used in MIC: "Manufacturer Installed Certificate". Another word not used in
this document to describe an IDevID. this document to describe an IDevID.
native interface: Interfaces existing on a node without native interface: Interfaces existing on a node without
configuration of the already running node. On physical nodes configuration of the already running node. On physical nodes
these are usually physical interfaces. On virtual nodes their these are usually physical interfaces. On virtual nodes their
skipping to change at page 10, line 18 skipping to change at page 10, line 25
UDI: "Unique Device Identifier". In the context of this document UDI: "Unique Device Identifier". In the context of this document
unsecured identity information of a node typically consisting of unsecured identity information of a node typically consisting of
at least device model/type and serial number, often in a vendor at least device model/type and serial number, often in a vendor
specific format. See sUDI and LDevID. specific format. See sUDI and LDevID.
ULA: A "Unique Local Address" (ULA) is an IPv6 address in the block ULA: A "Unique Local Address" (ULA) is an IPv6 address in the block
fc00::/7, defined in [RFC4193]. It is the approximate IPv6 fc00::/7, defined in [RFC4193]. It is the approximate IPv6
counterpart of the IPv4 private address ([RFC1918]). counterpart of the IPv4 private address ([RFC1918]).
(ACP) VRF: The ACP is modelled in this document as a "Virtual (ACP) VRF: The ACP is modelled in this document as a "Virtual
Routing and Forwarding" (VRF) component in a network node. Routing and Forwarding" instance (VRF). This means that it is
based on a "virtual router" consisting of a separate IPv6
forwarding table to which the ACP virtual interfaces are attached
and an associated separate IPv6 routing table. Unlike the VRFs on
MPLS/VPN-PE ([RFC4364]) or LISP XTR ([RFC6830]), the ACP VRF does
not have any special "core facing" functionality or routing/
mapping protocols shared across multiple VRFs. In vendor products
a VRF such as the ACP-VRF may also be referred to as a so called
VRF-lite.
(ACP) Zone: An ACP zone is a connected region of the ACP where nodes
derive from their non-aggregatable ACP address (identifier
address) an aggregateable ACP zone address (locator address). See
the definition of the ACP Zone Addressing Sub-Scheme
(Section 6.10.3). The complete definition of zones is subject to
future work because this document does not describe the routing
protocols details for aggregation of ACP zone addresses, but only
their addressing scheme.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119] when they appear in ALL CAPS. When these words are not in [RFC2119] when they appear in ALL CAPS. When these words are not in
ALL CAPS (such as "should" or "Should"), they have their usual ALL CAPS (such as "should" or "Should"), they have their usual
English meanings, and are not to be interpreted as [RFC2119] key English meanings, and are not to be interpreted as [RFC2119] key
words. words.
3. Use Cases for an Autonomic Control Plane 3. Use Cases for an Autonomic Control Plane
skipping to change at page 12, line 30 skipping to change at page 13, line 6
plane. Reason: traceability, debug-ability, separation from plane. Reason: traceability, debug-ability, separation from
data-plane, security (can block easily at edge). data-plane, security (can block easily at edge).
ACP3: The ACP MUST use autonomically managed address space. Reason: ACP3: The ACP MUST use autonomically managed address space. Reason:
easy bootstrap and setup ("autonomic"); robustness (admin easy bootstrap and setup ("autonomic"); robustness (admin
can't mess things up so easily). This document suggests to can't mess things up so easily). This document suggests to
use ULA addressing for this purpose ("Unique Local Address", use ULA addressing for this purpose ("Unique Local Address",
see [RFC4193]). see [RFC4193]).
ACP4: The ACP MUST be generic. Usable by all the functions and ACP4: The ACP MUST be generic. Usable by all the functions and
protocols of the AN infrastructure. It MUST NOT be tied to a protocols of the AN infrastructure. Clients of the ACP MUST
particular application or transport protocol. NOT be tied to a particular application or transport protocol.
ACP5: The ACP MUST provide security: Messages coming through the ACP ACP5: The ACP MUST provide security: Messages coming through the ACP
MUST be authenticated to be from a trusted node, and SHOULD MUST be authenticated to be from a trusted node, and SHOULD
(very strong SHOULD) be encrypted. (very strong SHOULD) be encrypted.
The ACP operates hop-by-hop, because this interaction can be built on The ACP operates hop-by-hop, because this interaction can be built on
IPv6 link local addressing, which is autonomic, and has no dependency IPv6 link local addressing, which is autonomic, and has no dependency
on configuration (requirement 1). It may be necessary to have ACP on configuration (requirement 1). It may be necessary to have ACP
connectivity across non-ACP nodes, for example to link ACP nodes over connectivity across non-ACP nodes, for example to link ACP nodes over
the general Internet. This is possible, but introduces a dependency the general Internet. This is possible, but introduces a dependency
skipping to change at page 13, line 13 skipping to change at page 13, line 37
instance, or a similar virtual context. instance, or a similar virtual context.
2. It determines, following a policy, a candidate peer list. This 2. It determines, following a policy, a candidate peer list. This
is the list of nodes to which it should establish an Autonomic is the list of nodes to which it should establish an Autonomic
Control Plane. Default policy is: To all link-layer adjacent Control Plane. Default policy is: To all link-layer adjacent
nodes supporting ACP. nodes supporting ACP.
3. For each node in the candidate peer list, it authenticates that 3. For each node in the candidate peer list, it authenticates that
node and negotiates a mutually acceptable channel type. node and negotiates a mutually acceptable channel type.
4. It then establishes a secure tunnel of the negotiated channel 4. For each node in the candidate peer list, it then establishes a
type. These tunnels are placed into the previously set up VRF. secure tunnel of the negotiated type. The resulting tunnels are
This creates an overlay network with hop-by-hop tunnels. then placed into the previously set up VRF. This creates an
overlay network with hop-by-hop tunnels.
5. Inside the ACP VRF, each node sets up a loopback interface with 5. Inside the ACP VRF, each node sets up a loopback interface with
its ULA IPv6 address. its ULA IPv6 address.
6. Each node runs a lightweight routing protocol, to announce 6. Each node runs a lightweight routing protocol, to announce
reachability of the virtual addresses inside the ACP (see reachability of the virtual addresses inside the ACP (see
Section 6.12.5). Section 6.12.5).
Note: Note:
o Non-autonomic NMS ("Network Management Systems") or SDN o Non-autonomic NMS ("Network Management Systems") or SDN
controllers have to be manually connected into the ACP. controllers have to be explicitly configured for connection into
the ACP.
o Connecting over non-ACP Layer-3 clouds initially requires a tunnel o Connecting over non-ACP Layer-3 clouds initially requires a tunnel
between ACP nodes. between ACP nodes.
o None of the above operations (except manual ones) is reflected in o None of the above operations (except explicit configured ones) are
the configuration of the node. reflected in the configuration of the node.
The following figure illustrates the ACP. The following figure illustrates the ACP.
ACP node 1 ACP node 2 ACP node 1 ACP node 2
................... ................... ................... ...................
secure . . secure . . secure secure . . secure . . secure
tunnel : +-----------+ : tunnel : +-----------+ : tunnel tunnel : +-----------+ : tunnel : +-----------+ : tunnel
..--------| ACP VRF |---------------------| ACP VRF |---------.. ..--------| ACP VRF |---------------------| ACP VRF |---------..
: / \ / \ <--routing--> / \ / \ : : / \ / \ <--routing--> / \ / \ :
: \ / \ / \ / \ / : : \ / \ / \ / \ / :
skipping to change at page 14, line 39 skipping to change at page 15, line 19
trust, the ACP requires certificates: An ACP node MUST have keying trust, the ACP requires certificates: An ACP node MUST have keying
material consisting of a certificate (LDevID), with which it can material consisting of a certificate (LDevID), with which it can
cryptographically assert its membership in the ACP domain and trust cryptographically assert its membership in the ACP domain and trust
anchor(s) associated with that certificate with which it can verify anchor(s) associated with that certificate with which it can verify
the membership of other nodes (see Section 6.1.2). The certificate the membership of other nodes (see Section 6.1.2). The certificate
is called the ACP domain certificate, the trust anchor(s) are the CA is called the ACP domain certificate, the trust anchor(s) are the CA
("Certificate Authority") of the ACP domain. ("Certificate Authority") 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
following ACP specific information field in its domain certificate as Domain information field as specified in Section 6.1.1 in its domain
well as those of candidate ACP peers. See Section 10.1 for more certificate as well as those of candidate ACP peers. See
information about enrollment or provisioning options. Section 10.1 for more information about enrollment or provisioning
options.
Note: LDevID ("Local Device IDentification") is the term used to Note: LDevID ("Local Device IDentification") is the term used to
indicate a certificate that was provisioned by the owner of a node as indicate a certificate that was provisioned by the owner of a node as
opposed to IDevID ("Initial Device IDentifier") that may has been opposed to IDevID ("Initial Device IDentifier") that may has been
loaded on the node during manufacturing time. Those IDevID do not loaded on the node during manufacturing time. Those IDevID do not
include owner and deployment specific information to allows autonomic include owner and deployment specific information to allows autonomic
establishment of trust for the operations of an ACP domain (e.g.: establishment of trust for the operations of an ACP domain (e.g.:
between two ACP nodes without relying on any third party). between two ACP nodes without relying on any third party).
This document uses the term ACP in many places where its reference This document uses the term ACP in many places where its reference
skipping to change at page 15, line 40 skipping to change at page 16, 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 with [RFC Editor: Please substitute SELF in all occurences of rfcSELF with
the RFC number assigned to this document and remove this comment the RFC number assigned to this document and remove this comment
line] line]
domain-information = local-part "@" domain domain-information = local-part "@" domain
local-part = key "." local-info
local-part = key "." local-info key = "rfcSELF"
local-info = [ acp-address ] [ "+" rsub extensions ]
key = "rfcSELF" acp-address = 32hex-dig
hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
local-info = [ acp-address ] [ "+" rsub extensions ] rsub = [ domain-name ] ; empty if not used
domain = domain-name
acp-address = 32hex-dig routing-subdomain = [ rsub " ." ] domain
domain-name = ; <domain> ; as of RFC1034, section 3.5
hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" extensions = *( "+" extension )
rsub = [ domain-name ] ; empty if not used extension = ; future definition.
; Must fit RFC5322 simple dot-atom format.
domain = domain-name
routing-subdomain = [ rsub " ." ] domain
domain-name = ; <domain> according to section 3.5 of [RFC1034]
extensions = *( "+" extension )
extension = ; future definition. Must fit into [RFC5322] simple dot-
atom format.
Example:
domain-information = rfcSELF+fda379a6f6ee00000200000064000000+area5
1.research@acp.example.com
routing-subdomain = area51.research.acp.example.com Example:
domain-information = rfcSELF+fd89b714f3db00000200000064000000
+area51.research@acp.example.com
routing-subdomain = area51.research.acp.example.com
"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.
skipping to change at page 16, line 44 skipping to change at page 17, line 12
nodes trust each other and are willing to build ACP channel to each nodes trust each other and are willing to build ACP channel to each
other. See Section 6.1.2. Domain SHOULD be the FQDN of a domain other. See Section 6.1.2. Domain SHOULD be the FQDN of a domain
owned by the operator assigning the certificate. This is a simple owned by the operator assigning the certificate. This is a simple
method to ensure that the domain is globally unique and collision of method to ensure that the domain is globally unique and collision of
ACP addresses would therefore only happen due to ULA hash collisions. ACP addresses would therefore only happen due to ULA hash collisions.
If the operator does not own any FQDN, it should choose a string in If the operator does not own any FQDN, it should choose a string in
FQDN format that intends to be equally unique. 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 prefix of the ACP address of the node. calculate the hash for the ULA prefix of the ACP address of the node.
"rsub" is optional and should only be used when its impacts are "rsub" is optional; its syntax is defined in this document, but its
understood. When "rsub" is not used, "routing-subdomain" is the same semantics are for further study. Understanding the benefits of using
as "domain". rsub may depend on the results of future work on enhancing routing
for the ACP. When "rsub" is not used, "routing-subdomain" is the
same as "domain".
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.
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]).
The subjectAltName / rfc822Name encoding of the ACP domain name and The subjectAltName / rfc822Name encoding of the ACP domain name and
ACP address is used for the following reasons: ACP address is used for the following reasons:
skipping to change at page 18, line 45 skipping to change at page 19, line 15
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 domain name in that
peers domain information field is the same as in this ACP node peers domain information field is the same as in this ACP node
certificate. Note that future Intent rules may modify this. See certificate. Note that future Intent rules may modify this. See
Section 10.7. Section 10.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. The functionality across the ACP so that EST renewal is useable. The
mechanism by which the domain certificate was initially provisioned mechanism by which the domain certificate was initially provisioned
SHOULD provide a mechanism to store the URL of one EST server with SHOULD provide a mechanism to store the URL of one EST server with
its ACP address into the node for later renewal. This server does its ACP address into the node for later renewal. This server does
not have to be the same as the one performing the initial certificate not have to be the same as the one performing the initial certificate
enrolment. enrolment.
ACP nodes that are EST servers MUST announce their service via GRASP ACP nodes that are EST servers MUST announce their service via GRASP
in the ACP through M_FLOOD messages: in the ACP through M_FLOOD messages:
Example: Example:
[M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 210000, [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000,
["SRV.est", 4, 255, "EST-TLS"], ["SRV.est", 4, 255 ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fda379a6f6ee0000200000064000001', TCP, 80] h'fd89b714f3db0000200000064000001', TCP, 80]
] ]
The formal CDDL definition is: The formal CDDL definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["SRV.est", objective-flags, loop-count, objective = ["SRV.est", objective-flags, loop-count,
objective-value] objective-value]
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 255 ; recommended loop-count = 255 ; recommended
objective-value = text ; name of the (list of) of supported objective-value = ; Not used (yet)
; protocols: "EST-TLS" for RFC7030.
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. [RFC7030] compliant EST server because "est" is an [RFC6335]
registered service name for [RFC7030]. Future backward compatible
extensions/alternatives to [RFC7030] may be indicated through
objective-value. Future non-backward compatible certificate renewal
options must use a different objective-name.
The M_FLOOD message MUST be sent periodically. The default SHOULD be The M_FLOOD message MUST be sent periodically. The default SHOULD be
60 seconds, the value SHOULD be operator configurable. It must be so 60 seconds, the value SHOULD be operator configurable. It must be so
high that the aggregate amount of periodic M_FLOODs from all flooded high that the aggregate amount of periodic M_FLOODs from all flooded
objectives causes only negligible traffic across the ACP. The ttl objectives causes only negligible traffic across the ACP. The ttl
parameter SHOULD be 3.5 times the period so that up to three parameter SHOULD be 3.5 times the period so that up to three
consecutive messages can be dropped before considering an consecutive messages can be dropped before considering an
announcement expired. In the example above, the ttl is 210000 msec, announcement expired. In the example above, the ttl is 210000 msec,
3.5 times 60 seconds. 3.5 times 60 seconds.
skipping to change at page 20, line 35 skipping to change at page 21, line 13
short lived certificates. short lived certificates.
See Section 10.1 for further optimizations of certificate maintenance See Section 10.1 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.2. ACP Adjacency Table 6.2. ACP Adjacency Table
To know to which nodes to establish an ACP channel, every ACP node To know to which nodes to establish an ACP channel, every ACP node
maintains an adjacency table. The adjacency table contains maintains an adjacency table. The adjacency table contains
information about adjacent ACP nodes, at a minimum: node-ID, Link- information about adjacent ACP nodes, at a minimum: Node-ID,
local IPv6 address (discovered by GRASP as explained below), domain, interface on which neighbor was discovered (by GRASP as explained
certificate. An ACP node MUST maintain this adjacency table up to below), link-local IPv6 address of neighbor on that interface,
date. This table is used to determine to which neighbor an ACP certificate (including domain information field). An ACP node MUST
connection is established. maintain this adjacency table up to date. This table is used to
determine to which neighbor an ACP connection is established.
Where the next ACP node is not directly adjacent, the information in Where the next ACP node is not directly adjacent, the information in
the adjacency table can be supplemented by configuration. For the adjacency table can be supplemented by configuration. For
example, the node-ID and IP address could be configured. example, the node-ID and IP address could be configured.
The adjacency table MAY contain information about the validity and The adjacency table MAY contain information about the validity and
trust of the adjacent ACP node's certificate. However, subsequent trust of the adjacent ACP node's certificate. However, subsequent
steps MUST always start with authenticating the peer. steps MUST always start with authenticating the peer.
The adjacency table contains information about adjacent ACP nodes in The adjacency table contains information about adjacent ACP nodes in
skipping to change at page 22, line 13 skipping to change at page 22, line 41
"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: Example:
[M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 180000, [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 180000,
["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" ],
[O_IPv6_LOCATOR,
h'fe80000000000000c0011001FEEF0000, UDP, 17000]
] ]
The formal CDDL definition is: The formal CDDL definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_ACP", objective-flags, loop-count, objective = ["AN_ACP", objective-flags, loop-count,
objective-value] objective-value]
objective-flags = sync-only ; as in the GRASP specification objective-flags = sync-only ; as in the GRASP specification
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; limit to link-local operation loop-count = 1 ; limit to link-local operation
objective-value = text ; name of the (list of) secure objective-value = method
; channel negotiation protocol(s) method = "IKEv2" / "dTLS" ; or future methods
The objective-flags field is set to indicate synchronization. The objective-flags field is set to indicate synchronization.
The loop-count is fixed at 1 since this is a link-local operation. The loop-count is fixed at 1 since this is a link-local operation.
In the above (recommended) example the period of sending of the In the above (recommended) example the period of sending of the
objective could be 60 seconds the indicated ttl of 180000 msec means objective could be 60 seconds the indicated ttl of 180000 msec means
that the objective would be cached by ACP nodes even when two out of that the objective would be cached by ACP nodes even when two out of
three messages are dropped in transit. three messages are dropped in transit.
The session-id is a random number used for loop prevention The session-id is a random number used for loop prevention
(distinguishing a message from a prior instance of the same message). (distinguishing a message from a prior instance of the same message).
In DULL this field is irrelevant but must still be set according to In DULL this field is irrelevant but must still be set according to
the GRASP specification. the GRASP specification.
The originator MUST be the IPv6 link local address of the originating The originator MUST be the IPv6 link local address of the originating
ACP node on the sending interface. ACP node on the sending interface.
The 'objective-value' parameter is (normally) a string indicating the The 'objective-value' parameter is a string indicating the secure
secure channel protocol available at the specified or implied channel protocol available at the specified or implied locator.
locator.
The locator is optional and only required when the secure channel The locator-option is optional and only required when the secure
protocol is not offered at a well-defined port number, or if there is channel protocol is not offered at a well-defined port number, or if
no well-defined port number. "IKEv2" is the abbreviation for there is no well-defined port number.
"Internet Key Exchange protocol version 2", as defined in [RFC7296].
It is the main protocol used by the Internet IP security architecture "IKEv2" is the abbreviation for "Internet Key Exchange protocol
("IPsec", see [RFC4301]). We therefore use the term "IKEv2" and not version 2", as defined in [RFC7296]. It is the main protocol used by
"IPsec" in the GRASP definitions below and example above. "IKEv2" the Internet IP security architecture ("IPsec", see [RFC4301]). We
has a well-defined port number 500, but in the above example, the therefore use the term "IKEv2" and not "IPsec" in the GRASP
candidate ACP neighbor is offering ACP secure channel negotiation via definitions and example above. "IKEv2" has a well-defined port
IKEv2 on port 15000 (for the sake of creating a non-standard number 500, but in the above example, the candidate ACP neighbor is
example). offering ACP secure channel negotiation via IKEv2 on port 15000 (for
the sake of creating a non-standard example).
If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6 If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6
address MUST be the same as the initiator address (these are DULL address MUST be the same as the initiator address (these are DULL
requirements to minimize third party DoS attacks). requirements to minimize third party DoS attacks).
The secure channel methods defined in this document use the objective The secure channel methods defined in this document use the objective
values of "IKEv2" and "dTLS". There is no distinction between IKEv2 values of "IKEv2" and "dTLS". There is no distinction between IKEv2
native and GRE-IKEv2 because this is purely negotiated via IKEv2. native and GRE-IKEv2 because this is purely negotiated via IKEv2.
A node that supports more than one secure channel protocol needs to A node that supports more than one secure channel protocol method
flood multiple versions of the "AN_ACP" objective, each accompanied needs to flood multiple versions of the "AN_ACP" objective so that
by its own locator. This can be in a single GRASP M_FLOOD message. each method can be accompanied by its own locator-option. This can
use a single GRASP M_FLOOD message as shown in above example.
If multiple secure channel protocols are supported that all are run
on well-defined ports, then they can be announced via a single AN_ACP
objective using a list of string names as the objective value without
a following locator-option.
Note that a node serving both as an ACP node and BRSKI Join Proxy may Note that a node serving both as an ACP node and BRSKI Join Proxy may
choose to distribute the "AN_ACP" objective and the respective BRSKI choose to distribute the "AN_ACP" objective and the respective BRSKI
in the same M_FLOOD message, since GRASP allows multiple objectives in the same M_FLOOD message, since GRASP allows multiple objectives
in one message. This may be impractical though if ACP and BRSKI in one message. This may be impractical though if ACP and BRSKI
operations are implemented via separate software modules / ASAs. operations are implemented via separate software modules / ASAs.
The result of the discovery is the IPv6 link-local address of the The result of the discovery is the IPv6 link-local address of the
neighbor as well as its supported secure channel protocols (and non- neighbor as well as its supported secure channel protocols (and non-
standard port they are running on). It is stored in the ACP standard port they are running on). It is stored in the ACP
skipping to change at page 26, line 34 skipping to change at page 27, line 20
6.7.1. ACP via IKEv2 6.7.1. ACP via IKEv2
An ACP node announces its ability to support IKEv2 as the ACP secure An ACP node announces its ability to support IKEv2 as the ACP secure
channel protocol in GRASP as "IKEv2". channel protocol in GRASP as "IKEv2".
6.7.1.1. Native IPsec 6.7.1.1. Native IPsec
To run ACP via IPsec natively, no further IANA assignments/ To run ACP via IPsec natively, no further IANA assignments/
definitions are required. An ACP node supporting native IPsec MUST definitions are required. An ACP node supporting native IPsec MUST
use IPsec security setup via IKEv2, tunnel mode, local and peer link- use IPsec security setup via IKEv2, tunnel mode, local and peer link-
local IPv6 addresses used for encapsulation, ESP with AES256 for local IPv6 addresses used for encapsulation. It MUST support ESP
encryption and SHA256 hash. with AES256 for encryption and SHA256 hash and MUST NOT permit weaker
crypto options.
In terms of IKEv2, this means the initiator will offer to support In terms of IKEv2, this means the initiator will offer to support
IPsec tunnel mode with next protocol equal 41 (IPv6). IPsec tunnel mode with next protocol equal 41 (IPv6).
IPsec tunnel mode is required because the ACP will route/forward IPsec tunnel mode is required because the ACP will route/forward
packets received from any other ACP node across the ACP secure packets received from any other ACP node across the ACP secure
channels, and not only its own generated ACP packets. With IPsec channels, and not only its own generated ACP packets. With IPsec
transport mode, it would only be possible to send packets originated transport mode, it would only be possible to send packets originated
by the ACP node itself. by the ACP node itself.
skipping to change at page 27, line 45 skipping to change at page 28, line 27
6.7.2. ACP via dTLS 6.7.2. ACP via dTLS
We define the use of ACP via dTLS in the assumption that it is likely We define the use of ACP via dTLS in the assumption that it is likely
the first transport encryption code basis supported in some classes the first transport encryption code basis supported in some classes
of constrained devices. of constrained devices.
To run ACP via UDP and dTLS v1.2 [RFC6347] a locally assigned UDP To run ACP via UDP and dTLS v1.2 [RFC6347] a locally assigned UDP
port is used that is announced as a parameter in the GRASP AN_ACP port is used that is announced as a parameter in the GRASP AN_ACP
objective to candidate neighbors. All ACP nodes supporting dTLS as a objective to candidate neighbors. All ACP nodes supporting dTLS as a
secure channel protocol MUST support AES256 encryption and not permit secure channel protocol MUST support AES256 encryption and MUST NOT
weaker crypto options. permit weaker crypto options.
There is no additional session setup or other security association There is no additional session setup or other security association
besides this simple dTLS setup. As soon as the dTLS session is besides this simple dTLS setup. As soon as the dTLS session is
functional, the ACP peers will exchange ACP IPv6 packets as the functional, the ACP peers will exchange ACP IPv6 packets as the
payload of the dTLS transport connection. Any dTLS defined security payload of the dTLS transport connection. Any dTLS defined security
association mechanisms such as re-keying are used as they would be association mechanisms such as re-keying are used as they would be
for any transport application relying solely on dTLS. for any transport application relying solely on dTLS.
6.7.3. ACP Secure Channel Requirements 6.7.3. ACP Secure Channel Requirements
skipping to change at page 28, line 39 skipping to change at page 29, line 22
of the ACP services. They function in GRASP that makes it of the ACP services. They function in GRASP that makes it
fundamental as a service is the ability for ACP wide service fundamental as a service is the ability for ACP wide service
discovery (called objectives in GRASP). In most other solution discovery (called objectives in GRASP). In most other solution
designs such distributed discovery does not exist at all or was added designs such distributed discovery does not exist at all or was added
as an afterthought and relied upon inconsistently. as an afterthought and relied upon inconsistently.
ACP provides IP unicast routing via the RPL routing protocol ACP provides IP unicast routing via the RPL routing protocol
(described below). (described below).
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. Instead, the ACP provides service discovery IP multicast services (the handling of GRASP link-local multicast
via the objective discovery/announcement and negotiation mechanisms messages is explained in the following section). Instead, the ACP
of the ACP GRASP instance (services are a form of objectives). These provides service discovery via the objective discovery/announcement
mechanisms use hop-by-hop reliable flooding of GRASP messages for and negotiation mechanisms of the ACP GRASP instance (services are a
both service discovery (GRASP M_DISCOVERY messages) and service form of objectives). These mechanisms use hop-by-hop reliable
announcement (GRASP M_FLOOD messages). flooding of GRASP messages for both service discovery (GRASP
M_DISCOVERY messages) and service announcement (GRASP M_FLOOD
messages).
IP multicast is not used by the ACP because the ANI (Autonomic IP multicast is not used by the ACP because the ANI (Autonomic
Networking Infrastructure) itself does not require IP multicast but Networking Infrastructure) itself does not require IP multicast but
only service announcement/discovery. Using IP multicast for that only service announcement/discovery. Using IP multicast for that
would have made it necessary to develop a zero-touch autoconfiguring would have made it necessary to develop a zero-touch autoconfiguring
solution for ASM (Any Source Multicast - original form of IP solution for ASM (Any Source Multicast - original form of IP
multicast defined in [RFC1112]), which would be quite complex and multicast defined in [RFC1112]), which would be quite complex and
difficult to justify. One aspect of complexity that has never been difficult to justify. One aspect of complexity that has never been
attempted to be solved in IETF documents is the automatic-selection attempted to be solved in IETF documents is the automatic-selection
of routers that should be PIM-SM rendezvous points (RPs) (see of routers that should be PIM-SM rendezvous points (RPs) (see
skipping to change at page 30, line 8 skipping to change at page 30, line 41
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 to ensure that this instance This means that the ACP is responsible to ensure that this instance
of GRASP is only sending messages across the ACP GRASP virtual of GRASP is only sending messages across the ACP GRASP virtual
interfaces. Whenever the ACP adds or deletes such an interface interfaces. Whenever the ACP adds or deletes such an interface
because of new ACP secure channels or loss thereof, the ACP needs to because of new ACP secure channels or loss thereof, the ACP needs to
indicate this to the ACP instance of GRASP. The ACP exists also in indicate this to the ACP instance of GRASP. The ACP exists also in
the absence of any active ACP neighbors. It is created when the node the absence of any active ACP neighbors. It is created when the node
has a domain certificate. In this case ASAs using GRASP running on has a domain certificate, and continues to exist even if all of its
the same node would still need to be able to discover each other's neighbors cease operation.
objectives. When the ACP does not exist, ASAs leveraging the ACP
instance of GRASP via APIs MUST still be able to operate, and MUST be In this case ASAs using GRASP running on the same node would still
able to understand that there is no ACP and that therefore the ACP need to be able to discover each other's objectives. When the ACP
instance of GRASP can not operate. 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
there is no ACP and that therefore the ACP instance of GRASP can not
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 [RFC Editor: please try to put the following picture on a single page
and remove this note. We cannot figure out how to do this with XML. and remove this note. We cannot figure out how to do this with XML.
The picture does fit on a single page.] The picture does fit on a single page.]
ACP: ACP:
............................................................... ...............................................................
skipping to change at page 31, line 34 skipping to change at page 32, line 22
GRASP unicast messages inside the ACP always use the ACP address. GRASP unicast messages inside the ACP always use the ACP address.
Link-local ACP addresses must not be used inside objectives. GRASP Link-local ACP addresses must not be used inside objectives. GRASP
unicast messages inside the ACP are transported via TLS 1.2 unicast messages inside the ACP are transported via TLS 1.2
([RFC5246]) connections with AES256 encryption and SHA256. Mutual ([RFC5246]) connections with AES256 encryption and SHA256. Mutual
authentication uses the ACP domain membership check defined in authentication uses the ACP domain membership check defined in
(Section 6.1.2). (Section 6.1.2).
GRASP link-local multicast messages are targeted for a specific ACP GRASP link-local multicast messages are targeted for a specific ACP
virtual interface (as defined Section 6.12.5) but are sent by the ACP virtual interface (as defined Section 6.12.5) but are sent by the ACP
into an equally built ACP GRASP virtual interface constructed from into an ACP GRASP virtual interface that is constructed from the TCP
the TCP connection(s) to the IPv6 link-local neighbor address(es) on connection(s) to the IPv6 link-local neighbor address(es) on the
the underlying ACP virtual interface. If the ACP GRASP virtual underlying ACP virtual interface. If the ACP GRASP virtual interface
interface has two or more neighbors, the GRASP link-local multicast has two or more neighbors, the GRASP link-local multicast messages
messages are replicated to all neighbor TCP connections. are replicated to all neighbor TCP connections.
TLS and TLS connections for GRASP in the ACP use the IANA assigned TLS and TLS connections for GRASP in the ACP use the IANA assigned
TCP port for GRASP (7107). Effectively the transport stack is TCP port for GRASP (7107). Effectively the transport stack is
expected to be TLS for connections from/to the ACP address (e.g.: expected to be TLS for connections from/to the ACP address (e.g.:
global scope address(es)) and TCP for connections from/to link-local global scope address(es)) and TCP for connections from/to link-local
addresses on the ACP virtual interfaces. The latter ones are only addresses on the ACP virtual interfaces. The latter ones are only
used for flooding of GRASP messages. used for flooding of GRASP messages.
6.8.2.1. Discussion 6.8.2.1. Discussion
skipping to change at page 33, line 41 skipping to change at page 34, line 29
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.
With the algorithm introduced here, all ACP nodes in the same routing With the algorithm introduced here, all ACP nodes in the same routing
subdomain have the same /48 ULA global ID prefix. Conversely, ULA subdomain have the same /48 ULA global ID prefix. Conversely, ULA
global IDs from different domains are unlikely to clash, such that global IDs from different domains are unlikely to clash, such that
two networks can be merged, as long as the policy allows that merge. two networks can be merged, as long as the policy allows that merge.
See also Section 9.1 for a discussion on merging domains. See also Section 9.1 for a discussion on merging domains.
Links inside the ACP only use link-local IPv6 addressing, such that Links inside the ACP only use link-local IPv6 addressing, such that
each node only requires one routable virtual address. each nodes ACP only requires one routable virtual address.
6.10.1. Fundamental Concepts of Autonomic Addressing 6.10.1. Fundamental Concepts of Autonomic Addressing
o Usage: Autonomic addresses are exclusively used for self- o Usage: Autonomic addresses are exclusively used for self-
management functions inside a trusted domain. They are not used management functions inside a trusted domain. They are not used
for user traffic. Communications with entities outside the for user traffic. Communications with entities outside the
trusted domain use another address space, for example normally trusted domain use another address space, for example normally
managed routable address space (called "data-plane" in this managed routable address space (called "data-plane" in this
document). document).
skipping to change at page 34, line 16 skipping to change at page 35, line 6
address space and other address realms. This supports the address space and other address realms. This supports the
robustness requirement. robustness requirement.
o Loopback-only: Only ACP loopback interfaces (and potentially those o Loopback-only: Only ACP loopback interfaces (and potentially those
configured for "ACP connect", see Section 8.1) carry routable configured for "ACP connect", see Section 8.1) carry routable
address(es); all other interfaces (called ACP virtual interfaces) address(es); all other interfaces (called ACP virtual interfaces)
only use IPv6 link local addresses. The usage of IPv6 link local only use IPv6 link local addresses. The usage of IPv6 link local
addressing is discussed in [RFC7404]. addressing is discussed in [RFC7404].
o Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local o Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local
Addresses (ULA), as specified in [RFC4193]. An alternative scheme Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193]
was discussed, using assigned ULA addressing. The consensus was with L=1].
to use ULA-random [[RFC4193] with L=1], because it was deemed to
be sufficient.
o No external connectivity: They do not provide access to the o No external connectivity: They do not provide access to the
Internet. If a node requires further reaching connectivity, it Internet. If a node requires further reaching connectivity, it
should use another, traditionally managed address scheme in should use another, traditionally managed address scheme in
parallel. parallel.
o Addresses in the ACP are permanent, and do not support temporary o Addresses in the ACP are permanent, and do not support temporary
addresses as defined in [RFC4941]. addresses as defined in [RFC4941].
o Addresses in the ACP are not considered sensitive on privacy o Addresses in the ACP are not considered sensitive on privacy
skipping to change at page 35, line 28 skipping to change at page 36, line 16
which a type field is added: which a type field is added:
o "fd" identifies a locally defined ULA address. o "fd" identifies a locally defined ULA address.
o The 40 bits ULA "global ID" (term from [RFC4193]) for ACP o The 40 bits ULA "global ID" (term from [RFC4193]) for ACP
addresses carried in the domain information field of domain addresses carried in the domain information field of domain
certificates are the first 40 bits of the SHA256 hash of the certificates are the first 40 bits of the SHA256 hash of the
routing subdomain from the same domain information field. In the routing subdomain from the same domain information field. In the
example of Section 6.1.1, the routing subdomain is example of Section 6.1.1, the routing subdomain is
"area51.research.acp.example.com" and the 40 bits ULA "global ID" "area51.research.acp.example.com" and the 40 bits ULA "global ID"
a379a6f6ee. 89b714f3db.
o To allow for extensibility, the fact that the ULA "global ID" is a o To allow for extensibility, the fact that the ULA "global ID" is a
hash of the routing subdomain SHOULD NOT be assumed by any ACP hash of the routing subdomain SHOULD NOT be assumed by any ACP
node during normal operations. The hash function is only executed node during normal operations. The hash function is only executed
during the creation of the certificate. If BRSKI is used then the during the creation of the certificate. If BRSKI is used then the
registrar will create the domain information field in response to registrar will create the domain information field in response to
the CSR Attribute Request by the pledge. the CSR Attribute Request 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
skipping to change at page 36, line 38 skipping to change at page 37, line 24
identifies the registrar which assigned the Node-ID to the node. identifies the registrar which assigned the Node-ID to the node.
A MAC address of the registrar can be used for this purpose. A MAC address of the registrar can be used for this purpose.
o Node-Number: A number which is unique for a given registrar, to o Node-Number: A number which is unique for a given registrar, to
identify the node. This can be a sequentially assigned number. identify the node. This can be a sequentially assigned number.
o V (1 bit): Virtualization bit: 0: Indicates the ACP itself ("ACP o V (1 bit): Virtualization bit: 0: Indicates the ACP itself ("ACP
node base system); 1: Indicates the optional "host" context on the node base system); 1: Indicates the optional "host" context on the
ACP node (see below). ACP node (see below).
In the Zone addressing sub-scheme, the ACP address in the certificate In the ACP Zone Addressing Sub-Scheme, the ACP address in the
has Zone and V fields as all zero bits. The ACP address set includes certificate has Zone-ID and V fields as all zero bits. The ACP
addresses with any Zone value and any V value. address set includes addresses with any Zone-ID value and any V
value.
The "Node-ID" itself is unique in a domain (i.e., the Zone-ID is not The "Node-ID" itself is unique in a domain (i.e., the Zone-ID is not
required for uniqueness). Therefore, a node can be addressed either required for uniqueness). Therefore, a node can be addressed either
as part of a flat hierarchy (zone ID = 0), or with an aggregation as part of a flat hierarchy (Zone-ID = 0), or with an aggregation
scheme (any other zone ID). A address with zone-ID = 0 is an scheme (any other Zone-ID). An address with Zone-ID = 0 is an
identifier, with another zone-ID as a locator. See Section 6.10.3.1 identifier, with a Zone-ID !=0 it is a locator. See Section 6.10.3.1
for a description of the zone bits. for more details.
The Virtual bit in this sub-scheme allows to easily add the ACP as a The Virtual bit in this sub-scheme allows to easily add the ACP as a
component to existing systems without causing problems in the port component to existing systems without causing problems in the port
number space between the services in the ACP and the existing system. number space between the services in the ACP and the existing system.
V:0 is the ACP router (autonomic node base system), V:1 is the host
V:0 is the ACP router (autonomous node base system), V:1 is the host
with pre-existing transport endpoints on it that could collide with with pre-existing transport endpoints on it that could collide with
the transport endpoints used by the ACP router. The ACP host could the transport endpoints used by the ACP router. The ACP host could
for example have a p2p virtual interface with the V:0 address as its for example have a p2p virtual interface with the V:0 address as its
router into the ACP. Depending on the SW design of ASA (outside the router into the ACP. Depending on the SW design of ASA (outside the
scope of this specification), they may use the V:0 or V:1 address. scope of this specification), they may use the V:0 or V:1 address.
The location of the V bit(s) at the end of the address allows to The location of the V bit(s) at the end of the address allows to
announce a single prefix for each ACP node. For example, in a announce a single prefix for each ACP node. For example, in a
network with 20,000 ACP nodes, this avoid 20,000 additional routes in network with 20,000 ACP nodes, this avoid 20,000 additional routes in
the routing table. the routing table.
6.10.3.1. Usage of the Zone Field 6.10.3.1. Usage of the Zone-ID Field
The "Zone-ID" allows for the introduction of structure in the The Zone-ID allows for the introduction of structure in the
addressing scheme. addressing scheme.
Zone = zero is the default addressing scheme in an ACP domain. Every Zone-ID = 0 is the default addressing scheme in an ACP domain. Every
ACP node MUST respond to its ACP address with zone=0. Used on its ACP node with a Zone Addressing Sub-Scheme address MUST respond to
own this leads to a non-hierarchical address scheme, which is its ACP address with Zone-ID = 0. Used on its own this leads to a
suitable for networks up to a certain size. In this case, the non-hierarchical address scheme, which is suitable for networks up to
addresses primarily act as identifiers for the nodes, and aggregation a certain size. Zone-ID = 0 addresses act as identifiers for the
is not possible. nodes, and aggregation of these address in the ACP routing table is
not possible.
If aggregation is required, the 13 bit value allows for up to 8192 If aggregation is required, the 13 bit Zone-ID value allows for up to
zones. The allocation of zone numbers may either happen 8191 zones. The allocation of Zone-ID's may either happen
automatically through a to-be-defined algorithm; or it could be automatically through a to-be-defined algorithm; or it could be
configured and maintained manually. configured and maintained explicitly.
If a node learns through an autonomic method or through configuration If a node learns through a future autonomic method or through
that it is part of a zone, it MUST also respond to its ACP address configuration that it is part of a zone, it MUST also respond to its
with that zone number. In this case the ACP loopback is configured ACP address with that Zone-ID. In this case the ACP loopback is
with two ACP addresses: One for zone 0 and one for the assigned zone. configured with two ACP addresses: One for Zone-ID = 0 and one for
This method allows for a smooth transition between a flat addressing the assigned Zone-ID. This method allows for a smooth transition
scheme and an hierarchical one. between a flat addressing scheme and an hierarchical one.
(Theoretically, the 13 bits for the Zone-ID would allow also for two A node knowing it is in a zone MUST also use that Zone-ID != 0
levels of zones, introducing a sub-hierarchy. We do not think this address in GRASP locator fields. This eliminates the use of the
is required at this point, but a new type could be used in the future identifier address (Zone-ID = 0) in forwarding and the need for
to support such a scheme.) network wide reachability of those non-aggregateable identifier
addresses. Zone-ID != 0 addresses are assumed to be aggregateable in
routing/forwarding based on how they are allocated in the ACP
topology (subject to future work).
Note: Theoretically, the 13 bits for the Zone-ID would allow also for
two levels of zones, introducing a sub-hierarchy. We do not think
this is required at this point, but a new type could be used in the
future to support such a scheme.
Note: The Zone-ID is one method to introduce structure or hierarchy Note: The Zone-ID is one method to introduce structure or hierarchy
into the ACP. Another way is the use of the routing subdomain field into the ACP. Another way is the use of the routing subdomain field
in the ACP that leads to different /40 ULA prefixes within an ACP in the ACP that leads to different /40 ULA prefixes within an ACP
domain. This gives future work two options to consider. domain. This gives future work two options to consider.
Note: Zones and Zone-ID as defined here are not related to [RFC4007]
zones or zone_id. ACP zone addresses are not scoped (reachable only
from within an RFC4007 zone) but reachable across the whole ACP. An
RFC4007 zone_id is a zone index that has only local significance on a
node, whereas an ACP Zone-ID is an identifier for an ACP zone that is
unique across that ACP.
6.10.4. ACP Manual Addressing Sub-Scheme 6.10.4. ACP Manual Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 00b (zero) The sub-scheme defined here is defined by the Type value 00b (zero)
in the base scheme. in the base scheme.
64 64 64 64
+---------------------+---------+---++-----------------------------+ +---------------------+---------+---++-----------------------------+
| (base scheme) |Subnet-ID| Z || Interface Identifier | | (base scheme) |Subnet-ID| Z || Interface Identifier |
+---------------------+---------+---++-----------------------------+ +---------------------+---------+---++-----------------------------+
50 13 1 50 13 1
skipping to change at page 38, line 40 skipping to change at page 39, line 42
"Manual" means that allocations of the Subnet-ID need to be done "Manual" means that allocations of the Subnet-ID need to be done
today with pre-existing, non-autonomic mechanisms. Every subnet that today with pre-existing, non-autonomic mechanisms. Every subnet that
uses this addressing sub-scheme needs to use a unique Subnet-ID uses this addressing sub-scheme needs to use a unique Subnet-ID
(unless some anycast setup is done). Future work may define (unless some anycast setup is done). Future work may define
mechanisms for auto-coordination between ACP nodes and auto- mechanisms for auto-coordination between ACP nodes and auto-
allocation of Subnet-IDs between them. allocation of Subnet-IDs between them.
The Z field is following the Subnet-ID field so that future work The Z field is following the Subnet-ID field so that future work
could allocate/coordinate both Zone-ID and Subnet-ID consistently and could allocate/coordinate both Zone-ID and Subnet-ID consistently and
use an integrated aggregatable routing approach across them. Z=0 use an integrated aggregatable routing approach across them. Z=0
(Zone sub-scheme) would then be used for network wide unique, (Zone-ID sub-scheme) would then be used for network wide unique,
registrar assigned (and certificate protected) Node-IDs primarily for registrar assigned (and certificate protected) Node-IDs primarily for
ACP nodes while Z=1 would be used for node-level assigned Interface ACP nodes while Z=1 would be used for node-level assigned Interface
Identifiers primarily for non-ACP-nodes (on logical subnets where the Identifiers primarily for non-ACP-nodes (on logical subnets where the
ACP node is a router). ACP node is a router).
Manual addressing sub-scheme addresses SHOULD only be used in domain Manual addressing sub-scheme addresses SHOULD only be used in domain
certificates assigned to nodes that cannot fully participate in the certificates assigned to nodes that cannot fully participate in the
automatic establishment of ACP secure channels or ACP routing. The automatic establishment of ACP secure channels or ACP routing. The
intended use are nodes connecting to the ACP via an ACP edge node and intended use are nodes connecting to the ACP via an ACP edge node and
ACP connect (see Section 8.1) - such as legacy NOC equipment. They ACP connect (see Section 8.1) - such as legacy NOC equipment. They
skipping to change at page 39, line 21 skipping to change at page 40, line 26
6.10.5. ACP Vlong Addressing Sub-Scheme 6.10.5. ACP Vlong Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 01b (one) in The sub-scheme defined here is defined by the Type value 01b (one) in
the base scheme. the base scheme.
50 78 50 78
+---------------------++-----------------------------+----------+ +---------------------++-----------------------------+----------+
| (base scheme) || Node-ID | | (base scheme) || Node-ID |
| || Registrar-ID | Node-Number| V | | || Registrar-ID | Node-Number| V |
+---------------------++--------------+--------------+----------+ +---------------------++--------------+--------------+----------+
46 33/17 8/16 50 46 24/16 8/16
Figure 6: ACP Vlong Addressing Sub-Scheme Figure 6: ACP Vlong Addressing Sub-Scheme
This addressing scheme foregoes the Zone field to allow for larger, This addressing scheme foregoes the Zone-ID field to allow for
flatter routed networks (e.g.: as in IoT) with more than 2^32 Node- larger, flatter routed networks (e.g.: as in IoT) with 8421376 Node-
Numbers. It also allows for up to 2^16 - 65536 different virtualized Numbers (2^23+2^15). It also allows for up to 2^16 - 65536 different
addresses, which could be used to address individual software virtualized addresses within a node, which could be used to address
components in an ACP node. individual software components in an ACP node.
The fields are the same as in the Zone sub-scheme with the following The fields are the same as in the Zone-ID sub-scheme with the
refinements: following refinements:
o V: Virtualization bit: Values 0 and 1 as in Zone sub-scheme, o V: Virtualization bit: Values 0 and 1 as in Zone-ID sub-scheme,
further values use via definition in future work. further values use via definition in future work.
o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is o Registrar-ID: To maximize Node-Number and V, the Registrar-ID is
reduced to 46 bits. This still allows to use the MAC address of a reduced to 46 bits. This still allows to use the MAC address of a
registrar by removing the V and U bits from the 48 bits of a MAC registrar by removing the V and U bits from the 48 bits of a MAC
address (those two bits are never unique, so they cannot be used address (those two bits are never unique, so they cannot be used
to distinguish MAC addresses). to distinguish MAC addresses).
o If the first bit of the "Node-Number" is "1", then the Node-Number o If the first bit of the "Node-Number" is "1", then the Node-Number
is 17 bit long and the V field is 16 bit long. Otherwise the is 16 bit long and the V field is 16 bit long. Otherwise the
Node-Number is 33 bit long and the V field is 8 bit long. "0" bit Node-Number is 24 bit long and the V field is 8 bit long. "0" bit
Node-Numbers are intended to be used for "general purpose" ACP Node-Numbers are intended to be used for "general purpose" ACP
nodes that would potentially have a limited number (< 256) of nodes that would potentially have a limited number (< 256) of
clients (ASA/Autonomic Functions or legacy services) nof the ACP clients (ASA/Autonomic Functions or legacy services) of the ACP
that require separate V(irtual) addresses. "1" bit Node-Numbers that require separate V(irtual) addresses. "1" bit Node-Numbers
are intended for ACP nodes that are ACP edge nodes (see are intended for ACP nodes that are ACP edge nodes (see
Section 8.1.1) or that have a large number of clients requiring Section 8.1.1) or that have a large number of clients requiring
separate V(irtual) addresses. For example large SDN controllers separate V(irtual) addresses. For example large SDN controllers
with container modular software architecture (see Section 8.1.2). with container modular software architecture (see Section 8.1.2).
In the Vlong addressing sub-scheme, the ACP address in the In the Vlong addressing sub-scheme, the ACP address in the
certificate has all V field bits as zero. The ACP address set for certificate has all V field bits as zero. The ACP address set for
the node includes any V value. the node includes any V value.
6.10.6. Other ACP Addressing Sub-Schemes 6.10.6. Other ACP Addressing Sub-Schemes
Before further addressing sub-schemes are defined, experience with Before further addressing sub-schemes are defined, experience with
the schemes defined here should be collected. The schemes defined in the schemes defined here should be collected. The schemes defined in
this document have been devised to allow hopefully sufficiently this document have been devised to allow hopefully sufficiently
flexible setup of ACPs for a variety of situation. These reasons flexible setup of ACPs for a variety of situation. These reasons
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-schemes is intended to enable optimized routing in Addressing Sub-Scheme is intended to enable optimized routing in
large networks by reserving bits for zones. 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 to be possible, so the last addressing scheme should consider to be
extensible in itself (e.g.: by reserving bits from it for further extensible in itself (e.g.: by reserving bits from it for further
extensions. extensions.
skipping to change at page 40, line 44 skipping to change at page 41, line 48
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 the global routing table
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 manual 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 10.5 for more details on the choice of RPL. Section 10.5 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 10.7 for more including all its routing subdomains. See Section 10.7 for more
skipping to change at page 43, line 41 skipping to change at page 44, line 49
6.11.1.10. P2P communications 6.11.1.10. P2P communications
Not used. Not used.
6.11.1.11. IPv6 address configuration 6.11.1.11. IPv6 address configuration
Every ACP node (RPL node) announces an IPv6 prefix covering the Every ACP node (RPL node) announces an IPv6 prefix covering the
address(es) used in the ACP node. The prefix length depends on the address(es) used in the ACP node. The prefix length depends on the
chosen addressing sub-scheme of the ACP address provisioned into the chosen addressing sub-scheme of the ACP address provisioned into the
certificate of the ACP node, e.g.: /127 for Zone addressing sub- certificate of the ACP node, e.g.: /127 for Zone Addressing Sub-
scheme or /112 or /120 for Vlong addressing sub-scheme. See Scheme or /112 or /120 for Vlong addressing sub-scheme. See
Section 6.10 for more details. Section 6.10 for more details.
Every ACP node MUST install a black hole (aka null) route for Every ACP node MUST install a black hole (aka null) route for
whatever ACP address space that it advertises (i.e.: the /96 or whatever ACP address space that it advertises (i.e.: the /96 or
/127). This is avoid routing loops for addresses that an ACP node /127). This is avoid routing loops for addresses that an ACP node
has not (yet) used. has not (yet) used.
6.11.1.12. Administrative parameters 6.11.1.12. Administrative parameters
Administrative Preference ([RFC6552], 3.2.6 - to become root): Administrative Preference ([RFC6552], 3.2.6 - to become root):
skipping to change at page 55, line 49 skipping to change at page 56, line 49
NMS hosts and/or software components. The ACP edge node uses route NMS hosts and/or software components. The ACP edge node uses route
prefix option of RFC4191 to announce the default route (::/) with a prefix option of RFC4191 to announce the default route (::/) with a
lifetime of 0 and aggregated prefixes for routes in the ACP routing lifetime of 0 and aggregated prefixes for routes in the ACP routing
table with normal lifetimes. This will ensure that the ACP edge node table with normal lifetimes. This will ensure that the ACP edge node
does not become a default router, but that the NMS hosts and software does not become a default router, but that the NMS hosts and software
components will route the prefixes used in the ACP to the ACP edge components will route the prefixes used in the ACP to the ACP edge
node. node.
Aggregated prefix means that the ACP edge node needs to only announce Aggregated prefix means that the ACP edge node needs to only announce
the /48 ULA prefixes used in the ACP but none of the actual /64 the /48 ULA prefixes used in the ACP but none of the actual /64
(Manual Addressing Sub-Scheme), /127 (Zone Addressing Sub-Scheme), (Manual Addressing Sub-Scheme), /127 (ACP Zone Addressing Sub-
/112 or /120 (Vlong Addressing Sub-Scheme) routes of actual ACP Scheme), /112 or /120 (Vlong Addressing Sub-Scheme) routes of actual
nodes. If ACP interfaces are configured with non ULA prefixes, then ACP nodes. If ACP interfaces are configured with non ULA prefixes,
those prefixes cannot be aggregated without further configured policy then those prefixes cannot be aggregated without further configured
on the ACP edge node. This explains the above recommendation to use policy on the ACP edge node. This explains the above recommendation
ACP ULA prefix covered prefixes for ACP connect interfaces: They to use ACP ULA prefix covered prefixes for ACP connect interfaces:
allow for a shorter list of prefixes to be signaled via RFC4191 to They allow for a shorter list of prefixes to be signaled via RFC4191
NMS hosts and software components. to NMS hosts and software components.
The ACP edge nodes that have a Vlong ACP address MAY allocate a The ACP edge nodes that have a Vlong ACP address MAY allocate a
subset of their /112 or /120 address prefix to ACP connect subset of their /112 or /120 address prefix to ACP connect
interface(s) to eliminate the need to non-autonomically configure/ interface(s) to eliminate the need to non-autonomically configure/
provision the address prefixes for such ACP connect interfaces. provision the address prefixes for such ACP connect interfaces.
8.1.4. Combined ACP/Data-Plane Interface (VRF Select) 8.1.4. Combined ACP/Data-Plane Interface (VRF Select)
Combined ACP and Data-Plane interface Combined ACP and Data-Plane interface
. .
skipping to change at page 57, line 41 skipping to change at page 58, line 41
together with whatever dafault router parameters are used for the together with whatever dafault router parameters are used for the
data-plane. data-plane.
In result, RFC6724 source address selection Rule 5.5 may result in In result, RFC6724 source address selection Rule 5.5 may result in
the same correct source address selection behavior of NMS hosts the same correct source address selection behavior of NMS hosts
without further configuration on it as the separate ACP connect and without further configuration on it as the separate ACP connect and
data-plane interfaces. As described in the text for Rule 5.5, this data-plane interfaces. As described in the text for Rule 5.5, this
is only a may, because IPv6 hosts are not required to track next-hop is only a may, because IPv6 hosts are not required to track next-hop
information. If an NMS Host does not do this, then separate ACP information. If an NMS Host does not do this, then separate ACP
connect and data-plane interfaces are the preferable method of connect and data-plane interfaces are the preferable method of
attachment. attachment. Hosts implementing [RFC8028] should (instead of may)
implement [RFC6724] Rule 5.5, so it is preferred for hosts to support
[RFC8028].
ACP edge nodes MAY support the Combined ACP and Data-Plane interface. ACP edge nodes MAY support the Combined ACP and Data-Plane interface.
8.1.5. Use of GRASP 8.1.5. Use of GRASP
GRASP can and should be possible to use across ACP connect GRASP can and should be possible to use across ACP connect
interfaces, especially in the architectural correct solution when it interfaces, especially in the architectural correct solution when it
is used as a mechanism to connect Software (e.g.: ASA or legacy NMS is used as a mechanism to connect Software (e.g.: ASA or legacy NMS
applications) to the ACP. Given how the ACP is the security and applications) to the ACP. Given how the ACP is the security and
transport substrate for GRASP, the trustworthiness of nodes/software transport substrate for GRASP, the trustworthiness of nodes/software
skipping to change at page 58, line 42 skipping to change at page 59, line 44
Not all nodes in a network may support the ACP. If non-ACP Layer-2 Not all nodes in a network may support the ACP. If non-ACP Layer-2
devices are between ACP nodes, the ACP will work across it since it devices are between ACP nodes, the ACP will work across it since it
is IP based. However, the autonomic discovery of ACP neighbors via is IP based. However, the autonomic discovery of ACP neighbors via
DULL GRASP is only intended to work across L2 connections, so it is DULL GRASP is only intended to work across L2 connections, so it is
not sufficient to autonomically create ACP connections across non-ACP not sufficient to autonomically create ACP connections across non-ACP
Layer-3 devices. Layer-3 devices.
8.2.1. Configured Remote ACP neighbor 8.2.1. Configured Remote ACP neighbor
On the ACP node, remote ACP neighbors are configured as follows: On the ACP node, remote ACP neighbors are configured as follows.
Future work could transform this into a YANG ([RFC7950]) data model.
remote-peer = [ local-address, method, remote-address ] connection = [ method , local-addr, remote-addr, ?pmtu ]
local-address = ip-address method = [ "IKEv2" , ?port ]
remote-address = transport-address method //= [ "dTLS", port ]
transport-address = local-addr = [ address , ?vrf ]
[ (ip-address | pattern) ?( , protocol ?(, port)) (, pmtu) ] remote-addr = [ address ]
ip-address = (ipv4-address | ipv6-address ) address = ("any" | ipv4-address | ipv6-address )
method = "IKEv2" / "dTLS" / .. vrf = tstr ; Name of a VRF on this node with local-address
pattern = some IP address set
For each candidate configured remote ACP neighbor, the secure channel Explicit configuration of a remote-peer provides all the information
protocol "method" is configured with its expected local IP address to build a secure channel without requiring a tunnel to that peer and
and remote transport endpoint. Transport protocol and port number running DULL GRASP inside of it.
for the remote transport endpoint are usually not necessary to
configure if defaults for the secure channel protocol method exist.
This is the same information that would be communicated via DULL for The configuration includes the parameters otherwise signaled via DULL
L2 adjacent candidate ACP neighbors. DULL is not used because the GRASP: local address, remote (peer) locator and method. The
remote IP address would need to be configured anyhow and if the differences over DULL GRASP local neighbor discovery and secure
remote transport address would not be configured but learned via DULL channel creation are as follows:
then this would create a third party attack vector.
The secure channel method leverages the configuration to filter o The local and remote address can be IPv4 or IPv6 and are typically
incoming connection requests by the remote IP address. This is global scope addresses.
supplemental security. The primary security is via the mutual domain
certificate based authentication of the secure channel protocol.
On a hub node, the remote IP address may be set to some pattern o The vrf across which the connection is built (and in which local-
instead of explicit IP addresses. In this case, the node does not addr exists) can to be specified. If vrf is not specified, it is
attempt to initiate secure channel connections but only acts as their the default vrf on the node. In DULL GRASP the VRF is implied by
responder. This allows for simple hub&spoke setups for the ACP where the interface across which DULL GRASP operates.
some method (subject to further specification) provisions the
transport-address of hubs into spokes and hubs accept connections
from any spokes. The typical use case for this are spokes connecting
via the Internet to hubs. For example, this would be simple
extension to BRSKI to allow zero-touch security across the Internet.
Unlike adjacent ACP neighbor connections, configured remote ACP o If local address is "any", the local address used when initiating
neighbor connections can also be across IPv4. Not all (future) a secure channel connection is decided by source address selection
secure channel methods may support running IPv6 (as used in the ACP ([RFC6724] for IPv6). As a responder, the connection listens on
across the secure channel connection) over IPv4 encapsulation. all addresses of the node in the selected vrf.
Unless the secure channel method supports PMTUD, it needs to be set o Configuration of port is only required for methods where no
up with minimum MTU or the path mtu (pmtu) should be configured. defaults exist (e.g.: "dTLS").
o If remote address is "any", the connection is only a responder.
It is a "hub" that can be used by multiple remote peers to connect
simultaneously - without having to know or configure their
addresses. Example: Hub site for remote "spoke" sites reachable
over the Internet.
o Pmtu should be configurable to overcome issues/limitations of
PMTUD (Path MTU Discovery).
o IKEv2/IPsec to remote peers should support the optional NAT-T
procedures (NAT Traversal).
8.2.2. Tunneled Remote ACP Neighbor 8.2.2. Tunneled Remote ACP Neighbor
An IPinIP, GRE or other form of pre-existing tunnel is configured An IPinIP, GRE or other form of pre-existing tunnel is configured
between two remote ACP peers and the virtual interfaces representing between two remote ACP peers and the virtual interfaces representing
the tunnel are configured to "ACP enable". This will enable IPv6 the tunnel are configured to "ACP enable". This will enable IPv6
link local addresses and DULL on this tunnel. In result, the tunnel link local addresses and DULL on this tunnel. In result, the tunnel
is used for normal "L2 adjacent" candidate ACP neighbor discovery is used for normal "L2 adjacent" candidate ACP neighbor discovery
with DULL and secure channel setup procedures described in this with DULL and secure channel setup procedures described in this
document. document.
skipping to change at page 72, line 14 skipping to change at page 73, line 29
10.3.2.2. Fast state propagation and Diagnostics 10.3.2.2. Fast state propagation and Diagnostics
"Physical down" state propagates on many interface types (e.g.: "Physical down" state propagates on many interface types (e.g.:
Ethernet) to the other side. This can trigger fast L2/L3 protocol Ethernet) to the other side. This can trigger fast L2/L3 protocol
reaction on the other side and "admin down" would not have the same reaction on the other side and "admin down" would not have the same
(fast) result. (fast) result.
Bringing interfaces to "physical down" state is to the best of our Bringing interfaces to "physical down" state is to the best of our
knowledge always a result of operator action, but today, never the knowledge always a result of operator action, but today, never the
result of (autonomous) L2/L3 services running on the nodes. result of (autonomic) L2/L3 services running on the nodes. Therefore
Therefore one option is to change the operator action to not rely on one option is to change the operator action to not rely on link-state
link-state propagation anymore. This may not be possible when both propagation anymore. This may not be possible when both sides are
sides are under different operator control, but in that case it is under different operator control, but in that case it is unlikely
unlikely that the ACP is running across the link and actually putting that the ACP is running across the link and actually putting the
the interface into "physical down" state may still be a good option. interface into "physical down" state may still be a good option.
Ideally, fast physical state propagation is replaced by fast software Ideally, fast physical state propagation is replaced by fast software
driven state propagation. For example a DULL GRASP "admin-state" driven state propagation. For example a DULL GRASP "admin-state"
objective could be used to autoconfigure a BFD session between the objective could be used to autoconfigure a BFD session between the
two sides of the link that would be used to propagate the "up" vs. two sides of the link that would be used to propagate the "up" vs.
admin down state. admin down state.
Triggering physical down state may also be used as a mean of Triggering physical down state may also be used as a mean of
diagnosing cabling in the absence of easier methods. It is more diagnosing cabling in the absence of easier methods. It is more
complex than automated neighbor diagnostics because it requires complex than automated neighbor diagnostics because it requires
skipping to change at page 87, line 18 skipping to change at page 88, line 33
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 and Sheng Jiang for their thorough Special thanks to Brian Carpenter and Sheng Jiang for their thorough
reviews and to Pascal Thubert and Michael Richardson to provide the reviews and to Pascal Thubert and Michael Richardson to provide the
details for the recommendations of the use of RPL in the ACP details for the recommendations of the use of RPL in the ACP
Further input and suggestions were received from: Rene Struik, Brian Further input, review or suggestions were received from: Rene Struik,
Carpenter, Benoit Claise. Brian Carpenter, Benoit Claise, William Atwood and Yongkang Zhang.
14. Change log [RFC Editor: Please remove] 14. Change log [RFC Editor: Please remove]
14.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
14.2. draft-behringer-anima-autonomic-control-plane-00 14.2. draft-behringer-anima-autonomic-control-plane-00
skipping to change at page 100, line 5 skipping to change at page 101, line 15
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.
14.19. draft-ietf-anima-autonomic-control-plane-13
Swap author list (with permission).
6.1.1. Eliminate blank lines in definition by making it a picture
(reformatting only).
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
of Zone-ID = 0 prefixes.
Rest of feedback from review of -12, see
https://raw.githubusercontent.com/anima-wg/autonomic-control-
plane/master/draft-ietf-anima-autonomic-control-plane/12-feedback-
reply.txt
Review from Brian Carpenter:
various: Autonomous -> autonomic(ally) in all remaining occurances.
various: changed "manual (configured)" to "explicitly (configured)"
to not exclude the option of (SDN controller) automatic configuration
(no humans involved).
1. Fixed reference to section 9.
2. Added definition of loopback interface == internal interface.
After discus on WG mailing lists, including 6man.
6.1.3 Removed "EST-TLS", no objective value needed or beneficial,
added explanation paragraph why.
6.2 Added to adjacency table the interface that a neighbor is
discovered on.
6.3 Simplified CDDL syntax: Only one method per AN_ACP objective
(because of locators). Example with two objectives in GRASP message.
6.8.1 Added note about link-local GRASP multicast message to avoid
confusion.
8.1.4 Added RFC8028 as recommended on hosts to better support VRF-
select with ACP.
8.2.1 Rewrote and Simplified CDDL for configured remote peer and
explanations. Removed pattern option for remote peer. Not important
enough to be mandated.
Review thread started by William Atwood:
2. Refined definition of VRF (vs. MPLS/VPN, LISP, VRF-LITE).
2. Refined definition of ACP (ACP includes ACP GRASP instance).
2. Added explanation for "zones" to terminology section and into
Zone Addressing Sub Scheme section, relating it to RFC4007 zones
(from Brian Carpenter).
4. Fixed text for ACP4 requirement (Clients of the ACP must not be
tied to specific protocol.).
5. Fixed step 4. with proposed text.
6.1.1 Included suggested explanation for rsub semantics.
6.1.3 must->MUST for at least one EST server in ACP network to
autonomically renew certs.
6.7.2 normative: AND MUST NOT (permit weaker crypto options.
6.7.1.1 also included text denying weaker IPsec profile options.
6.8.2 Fixed description how to build ACP GRASP virtual interfaces.
Added text that ACP continues to exist in absence of ACP neighbors.
various: Make sure all "zone" words are used consistently.
6.10.2/various: fixed 40 bit RFC4193 ULA prefix in all examples to
89b714f3db (thanks MichaelR).
6.10.1 Removed comment about assigned ULA addressing. Decision not
to use it now ancient history of WG decision making process, not
worth nothing anymore in the RFC.
Review from Yongkang Zhang:
6.10.5 Fixed length of Node-Numbers in ACP Vlong Addressing Sub-
Scheme.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
skipping to change at page 102, line 16 skipping to change at page 105, line 21
[AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and [AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-07 (work in progress), July 2017. keyinfra-09 (work in progress), October 2017.
[I-D.ietf-anima-prefix-management] [I-D.ietf-anima-prefix-management]
Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic
IPv6 Edge Prefix Management in Large-scale Networks", IPv6 Edge Prefix Management in Large-scale Networks",
draft-ietf-anima-prefix-management-05 (work in progress), draft-ietf-anima-prefix-management-06 (work in progress),
August 2017. October 2017.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
Reference Model for Autonomic Networking", draft-ietf- Reference Model for Autonomic Networking", draft-ietf-
anima-reference-model-04 (work in progress), July 2017. anima-reference-model-05 (work in progress), October 2017.
[I-D.ietf-anima-stable-connectivity] [I-D.ietf-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft-ietf- Plane for Stable Connectivity of Network OAM", draft-ietf-
anima-stable-connectivity-06 (work in progress), September anima-stable-connectivity-07 (work in progress), October
2017. 2017.
[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 NETCONF or RESTCONF based Management", Provisioning for NETCONF or RESTCONF based Management",
draft-ietf-netconf-zerotouch-17 (work in progress), draft-ietf-netconf-zerotouch-19 (work in progress),
September 2017. October 2017.
[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-16 (work in progress), July 2017. useofrplinfo-19 (work in progress), October 2017.
[MACSEC] IEEE SA-Standards Board, "IEEE Standard for Local and [MACSEC] IEEE SA-Standards Board, "IEEE Standard for Local and
Metropolitan Area Networks: Media Access Control (MAC) Metropolitan Area Networks: Media Access Control (MAC)
Security", June 2006, Security", June 2006,
<https://standards.ieee.org/findstds/ <https://standards.ieee.org/findstds/
standard/802.1AE-2006.html>. standard/802.1AE-2006.html>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989, RFC 1112, DOI 10.17487/RFC1112, August 1989,
<https://www.rfc-editor.org/info/rfc1112>. <https://www.rfc-editor.org/info/rfc1112>.
skipping to change at page 103, line 22 skipping to change at page 106, line 28
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<https://www.rfc-editor.org/info/rfc2315>. <https://www.rfc-editor.org/info/rfc2315>.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, DOI 10.17487/RFC2821, April 2001, RFC 2821, DOI 10.17487/RFC2821, April 2001,
<https://www.rfc-editor.org/info/rfc2821>. <https://www.rfc-editor.org/info/rfc2821>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006,
<https://www.rfc-editor.org/info/rfc4541>. <https://www.rfc-editor.org/info/rfc4541>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
skipping to change at page 104, line 46 skipping to change at page 108, line 13
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404, Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014, DOI 10.17487/RFC7404, November 2014,
<https://www.rfc-editor.org/info/rfc7404>. <https://www.rfc-editor.org/info/rfc7404>.
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
Defined Networking (SDN): Layers and Architecture Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, DOI 10.17487/RFC7426, January Terminology", RFC 7426, DOI 10.17487/RFC7426, January
2015, <https://www.rfc-editor.org/info/rfc7426>. 2015, <https://www.rfc-editor.org/info/rfc7426>.
skipping to change at page 105, line 33 skipping to change at page 109, line 5
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>. 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Authors' Addresses Authors' Addresses
Michael H. Behringer (editor)
Email: michael.h.behringer@gmail.com
Toerless Eckert (editor) Toerless Eckert (editor)
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)
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. 95 change blocks. 
339 lines changed or deleted 497 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/