draft-ietf-anima-autonomic-control-plane-09.txt   draft-ietf-anima-autonomic-control-plane-10.txt 
ANIMA WG M. Behringer, Ed. ANIMA WG M. Behringer, Ed.
Internet-Draft Internet-Draft
Updates: 4291,4193 (if approved) T. Eckert, Ed. Updates: 4291,4193 (if approved) T. Eckert, Ed.
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: February 3, 2018 S. Bjarnason Expires: March 19, 2018 S. Bjarnason
Arbor Networks Arbor Networks
August 2, 2017 September 15, 2017
An Autonomic Control Plane (ACP) An Autonomic Control Plane (ACP)
draft-ietf-anima-autonomic-control-plane-09 draft-ietf-anima-autonomic-control-plane-10
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 Control Plane depends on some addressing and routing. This Autonomic Control Plane
should ideally be self-managing, and as independent as possible of should ideally be self-managing, and as independent as possible of
configuration. This document defines an "Autonomic Control Plane", configuration. This document defines an "Autonomic Control Plane",
with the primary use as a control plane for autonomic functions. It with the primary use as a control plane for autonomic functions. It
also serves as a "virtual out of band channel" for OAM communications also serves as a "virtual out of band channel" for OAM communications
over a network that is not configured, or mis-configured. over a network that is not configured, or mis-configured.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 3, 2018. This Internet-Draft will expire on March 19, 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
(http://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 8 3. Use Cases for an Autonomic Control Plane . . . . . . . . . . 8
3.1. An Infrastructure for Autonomic Functions . . . . . . . . 8 3.1. An Infrastructure for Autonomic Functions . . . . . . . . 8
3.2. Secure Bootstrap over an Unconfigured Network . . . . . . 8 3.2. Secure Bootstrap over an Unconfigured Network . . . . . . 8
3.3. Data Plane Independent Permanent Reachability . . . . . . 9 3.3. Data Plane Independent Permanent Reachability . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 12 6. Self-Creation of an Autonomic Control Plane (ACP) (Normative) 12
6.1. Domain Certificate . . . . . . . . . . . . . . . . . . . 12 6.1. Domain Certificate . . . . . . . . . . . . . . . . . . . 12
6.1.1. ACP information . . . . . . . . . . . . . . . . . . . 12 6.1.1. ACP information . . . . . . . . . . . . . . . . . . . 13
6.1.2. Maintenance . . . . . . . . . . . . . . . . . . . . . 14 6.1.2. Maintenance . . . . . . . . . . . . . . . . . . . . . 15
6.2. AN Adjacency Table . . . . . . . . . . . . . . . . . . . 16 6.2. AN Adjacency Table . . . . . . . . . . . . . . . . . . . 17
6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 17 6.3. Neighbor Discovery with DULL GRASP . . . . . . . . . . . 18
6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 19 6.4. Candidate ACP Neighbor Selection . . . . . . . . . . . . 20
6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 20 6.5. Channel Selection . . . . . . . . . . . . . . . . . . . . 21
6.6. Candidate ACP Neighbor certificate verification . . . . . 21 6.6. Candidate ACP Neighbor certificate verification . . . . . 23
6.7. Security Association protocols . . . . . . . . . . . . . 22 6.7. Security Association protocols . . . . . . . . . . . . . 23
6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 22 6.7.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 23
6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 23 6.7.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 24
6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 23 6.7.3. ACP Secure Channel Requirements . . . . . . . . . . . 25
6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 24 6.8. GRASP in the ACP . . . . . . . . . . . . . . . . . . . . 25
6.8.1. GRASP as a core service of the ACP . . . . . . . . . 24 6.8.1. GRASP as a core service of the ACP . . . . . . . . . 25
6.8.2. ACP as the Security and Transport substrate for GRASP 24 6.8.2. ACP as the Security and Transport substrate for GRASP 26
6.9. Context Separation . . . . . . . . . . . . . . . . . . . 25 6.9. Context Separation . . . . . . . . . . . . . . . . . . . 28
6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 25 6.10. Addressing inside the ACP . . . . . . . . . . . . . . . . 28
6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 26 6.10.1. Fundamental Concepts of Autonomic Addressing . . . . 28
6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 27 6.10.2. The ACP Addressing Base Scheme . . . . . . . . . . . 29
6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 27 6.10.3. ACP Zone Addressing Sub-Scheme . . . . . . . . . . . 30
6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 30 6.10.4. ACP Manual Addressing Sub-Scheme . . . . . . . . . . 32
6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 31 6.10.5. ACP Vlong Addressing Sub-Scheme . . . . . . . . . . 33
6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 32 6.10.6. Other ACP Addressing Sub-Schemes . . . . . . . . . . 34
6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 32 6.11. Routing in the ACP . . . . . . . . . . . . . . . . . . . 35
6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 32 6.11.1. RPL Profile . . . . . . . . . . . . . . . . . . . . 35
6.12. General ACP Considerations . . . . . . . . . . . . . . . 36 6.12. General ACP Considerations . . . . . . . . . . . . . . . 39
6.12.1. Addressing of Secure Channels in the data plane . . 36 6.12.1. Performance . . . . . . . . . . . . . . . . . . . . 39
6.12.2. MTU . . . . . . . . . . . . . . . . . . . . . . . . 36 6.12.2. Addressing of Secure Channels in the data plane . . 39
6.12.3. Multiple links between nodes . . . . . . . . . . . . 37 6.12.3. MTU . . . . . . . . . . . . . . . . . . . . . . . . 40
6.12.4. ACP interfaces . . . . . . . . . . . . . . . . . . . 37 6.12.4. Multiple links between nodes . . . . . . . . . . . . 40
7. ACP support on L2 switches/ports (Normative) . . . . . . . . 38 6.12.5. ACP interfaces . . . . . . . . . . . . . . . . . . . 40
7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 40 7. ACP support on L2 switches/ports (Normative) . . . . . . . . 43
8. Support for Non-Autonomic Components (Normative) . . . . . . 41 7.1. Why . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 41 7.2. How (per L2 port DULL GRASP) . . . . . . . . . . . . . . 44
8.1.1. Non-Autonomic Controller / NMS system . . . . . . . . 41 8. Support for Non-Autonomic Components (Normative) . . . . . . 46
8.1.2. Software Components . . . . . . . . . . . . . . . . . 44 8.1. ACP Connect . . . . . . . . . . . . . . . . . . . . . . . 46
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 45 8.1.1. Non-Autonomic Controller / NMS system . . . . . . . . 46
8.1.2. Software Components . . . . . . . . . . . . . . . . . 48
8.1.3. Auto Configuration . . . . . . . . . . . . . . . . . 49
8.1.4. Combined ACP and Data Data Plane Interface (VRF 8.1.4. Combined ACP and Data Data Plane Interface (VRF
Select) . . . . . . . . . . . . . . . . . . . . . . . 45 Select) . . . . . . . . . . . . . . . . . . . . . . . 50
8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 47 8.1.5. Use of GRASP . . . . . . . . . . . . . . . . . . . . 52
8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP 8.2. ACP through Non-Autonomic L3 Clouds (Remote ACP
neighbors) . . . . . . . . . . . . . . . . . . . . . . . 48 neighbors) . . . . . . . . . . . . . . . . . . . . . . . 52
8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 48 8.2.1. Configured Remote ACP neighbor . . . . . . . . . . . 52
8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 49 8.2.2. Tunneled Remote ACP Neighbor . . . . . . . . . . . . 54
8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 50 8.2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 54
9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 50 9. Benefits (Informative) . . . . . . . . . . . . . . . . . . . 54
9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 50 9.1. Self-Healing Properties . . . . . . . . . . . . . . . . . 54
9.2. Self-Protection Properties . . . . . . . . . . . . . . . 51 9.2. Self-Protection Properties . . . . . . . . . . . . . . . 56
9.2.1. From the outside . . . . . . . . . . . . . . . . . . 51 9.2.1. From the outside . . . . . . . . . . . . . . . . . . 56
9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 52 9.2.2. From the inside . . . . . . . . . . . . . . . . . . . 56
9.3. The Administrator View . . . . . . . . . . . . . . . . . 53 9.3. The Administrator View . . . . . . . . . . . . . . . . . 57
10. Further Considerations (Informative) . . . . . . . . . . . . 53 10. Further Considerations (Informative) . . . . . . . . . . . . 57
10.1. Domain Certificate provisioning / enrollment . . . . . . 53 10.1. Domain Certificate provisioning / enrollment . . . . . . 58
10.2. ACP Neighbor discovery protocol selection . . . . . . . 55 10.2. ACP Neighbor discovery protocol selection . . . . . . . 59
10.2.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 55 10.2.1. LLDP . . . . . . . . . . . . . . . . . . . . . . . . 59
10.2.2. mDNS and L2 support . . . . . . . . . . . . . . . . 55 10.2.2. mDNS and L2 support . . . . . . . . . . . . . . . . 59
10.2.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 55 10.2.3. Why DULL GRASP . . . . . . . . . . . . . . . . . . . 60
10.3. Choice of routing protocol (RPL) . . . . . . . . . . . . 56 10.3. Choice of routing protocol (RPL) . . . . . . . . . . . . 60
10.4. Extending ACP channel negotiation (via GRASP) . . . . . 57 10.4. Extending ACP channel negotiation (via GRASP) . . . . . 61
10.5. CAs, domains and routing subdomains . . . . . . . . . . 59 10.5. CAs, domains and routing subdomains . . . . . . . . . . 63
11. RFC4291/RFC4193 Updates Considerations . . . . . . . . . . . 61 11. RFC4291/RFC4193 Updates Considerations . . . . . . . . . . . 65
12. Security Considerations . . . . . . . . . . . . . . . . . . . 63 12. Security Considerations . . . . . . . . . . . . . . . . . . . 67
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68
15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 64 15. Change log [RFC Editor: Please remove] . . . . . . . . . . . 68
15.1. Initial version . . . . . . . . . . . . . . . . . . . . 64 15.1. Initial version . . . . . . . . . . . . . . . . . . . . 68
15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 64 15.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 68
15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 64 15.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 68
15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 64 15.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 69
15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 65 15.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 69
15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 65 15.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 69
15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 65 15.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 69
15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 66 15.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 70
15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 66 15.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 70
15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 66 15.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 71
15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 67 15.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 71
15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 67 15.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 72
15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 68 15.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 72
15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 69 15.14. draft-ietf-anima-autonomic-control-plane-08 . . . . . . 74
15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 71 15.15. draft-ietf-anima-autonomic-control-plane-09 . . . . . . 75
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 15.16. draft-ietf-anima-autonomic-control-plane-10 . . . . . . 77
16.1. Normative References . . . . . . . . . . . . . . . . . . 73 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 78
16.2. Informative References . . . . . . . . . . . . . . . . . 74 16.1. Normative References . . . . . . . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 16.2. Informative References . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
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 design across the network.[RFC7575] defines the fundamental ideas and design
goals of Autonomic Networking. A gap analysis of Autonomic 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]
skipping to change at page 5, line 4 skipping to change at page 5, line 8
the network, yet as independent as possible of configuration, the network, yet as independent as possible of configuration,
addressing and routing problems (for details how this achieved, see addressing and routing problems (for details how this achieved, see
Section 6). It therefore remains operational even in the presence of Section 6). It therefore remains operational even in the presence of
configuration errors, addressing or routing issues, or where policy configuration errors, addressing or routing issues, or where policy
could inadvertently affect control plane connectivity. The Autonomic could inadvertently affect control plane connectivity. The Autonomic
Control Plane serves several purposes at the same time: Control Plane serves several purposes at the same time:
o Autonomic functions communicate over the ACP. The ACP therefore o Autonomic functions communicate over the ACP. The ACP therefore
supports directly Autonomic Networking functions, as described in supports directly Autonomic Networking functions, as described in
[I-D.ietf-anima-reference-model]. For example, GRASP [I-D.ietf-anima-reference-model]. For example, GRASP
[I-D.ietf-anima-grasp] runs securely inside the ACP and depends on [I-D.ietf-anima-grasp] runs securely inside the ACP and depends on
the ACP as its "security substrate". the ACP as its "security and transport substrate".
o An operator can use it to log into remote devices, even if the o An operator can use it to log into remote devices, even if the
data plane is misconfigured or unconfigured. data plane is misconfigured or unconfigured.
o A controller or network management system can use it to securely o A controller or network management system can use it to securely
bootstrap network devices in remote locations, even if the network bootstrap network devices in remote locations, even if the network
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]
skipping to change at page 5, line 44 skipping to change at page 5, line 47
This document uses the following terms (sorted alphabetically): This document uses the following terms (sorted alphabetically):
ACP "Autonomic Control Plane". The Autonomic Function defined in ACP "Autonomic Control Plane". The Autonomic Function defined in
this document. It provides secure zero-touch network wide IPv6 this document. It provides secure zero-touch network wide IPv6
connectivity between devices supporting it. The ACP is primarily connectivity between devices supporting it. The ACP is primarily
meant to be used as a component of the ANI to enable Autonomic meant to be used as a component of the ANI to enable Autonomic
Networks but it can equally be used in simple ANI networks (with Networks but it can equally be used in simple ANI networks (with
no other Autonomic Functions) or completely by itself. no other Autonomic Functions) or completely by itself.
ACP address An IPv6 ULA address assigned to the ACP device. It is ACP address An IPv6 ULA address assigned to the ACP device. It is
stored in the ACP information field of an ACP devices LDevID. stored in the ACP information field of an ACP devices certificate
(LDevID).
(Device) ACP address range/set The ACP address may imply a range or
set of addresses that the device can assign for different
purposes. This address range/set is derived by the device from
the format of the ACP address called the "addressing sub-scheme".
ACP connect A physical interface on an ACP device providing access ACP connect A physical interface on an ACP device providing access
to the ACP for non ACP capable devices. See Section 8.1.1. to the ACP for non ACP capable devices. See Section 8.1.1.
ACP device A device supporting the ACP according to this document. ACP device A device supporting the ACP according to this document.
ACP information (field) An rfc822Name information element (eg: ACP information (field) An rfc822Name information element (eg:
field) in the Domain Certificate in which the ACP relevant field) in the Domain Certificate in which the ACP relevant
information is encoded: the AN Domain Name and the ACP address. information is encoded: the AN Domain Name and the ACP address.
skipping to change at page 6, line 29 skipping to change at page 6, line 36
ACP secure channel A virtual subinterface/tunnel established hop-by- ACP secure channel A virtual subinterface/tunnel established hop-by-
hop between adjacent ACP devices to carry traffic of the ACP VRF hop between adjacent ACP devices to carry traffic of the ACP VRF
separated from Data Plane traffic inband over the same links as separated from Data Plane traffic inband over the same links as
the Data Plane. the Data Plane.
ACP secure channel protocol The protocol used to build an ACP secure ACP secure channel protocol The protocol used to build an ACP secure
channel, eg: IKEv2/IPsec or dTLS. channel, eg: IKEv2/IPsec or dTLS.
ACP virtual interface An interface in the ACP VRF mapped to one or ACP virtual interface An interface in the ACP VRF mapped to one or
more ACP secure channels. See Section 6.12.4. more ACP secure channels. See Section 6.12.5.
ACP VRF The ACP is modelled in this document as a "Virtual Routing ACP VRF The ACP is modelled in this document as a "Virtual Routing
and Forwarding" (VRF) component in a network device. and Forwarding" (VRF) component in a network device.
AN "Autonomic Network". A network according to AN "Autonomic Network". A network according to
[I-D.ietf-anima-reference-model]. Its main components are Intent, [I-D.ietf-anima-reference-model]. Its main components are Intent,
Autonomic Functions and ANI. Autonomic Functions and ANI.
AN Domain Name An FQDN (Fully Qualified Domain Name) identifying an AN Domain Name An FQDN (Fully Qualified Domain Name) identifying an
Autonomic Network. It is stored in the ACP information field of Autonomic Network. It is stored in the ACP information field of
skipping to change at page 8, line 4 skipping to change at page 8, line 9
signaling protocol required by the ACP for ACP neighbor discovery. signaling protocol required by the ACP for ACP neighbor discovery.
The ACP also provides the "security and transport substrate" for The ACP also provides the "security and transport substrate" for
the "ACP instance of GRASP" which is run inside the ACP to support the "ACP instance of GRASP" which is run inside the ACP to support
BRSKI and other future Autonomic Functions. See BRSKI and other future Autonomic Functions. See
[I-D.ietf-anima-grasp]. [I-D.ietf-anima-grasp].
IDevID An "Initial Device IDentity" X.509 certificate installed by IDevID An "Initial Device IDentity" X.509 certificate installed by
the vendor on new equipment. Contains information that the vendor on new equipment. Contains information that
establishes the identity of the device in the context of its establishes the identity of the device in the context of its
vendor/manufacturer such as device model/type and serial number. vendor/manufacturer such as device model/type and serial number.
See [AR8021].
LDevID A "Local Device IDentity" X.509 certificate installed during LDevID A "Local Device IDentity" X.509 certificate installed during
an "enrollment". The ACP depends on a Domain Certificate which is an "enrollment". The ACP depends on a Domain Certificate which is
an LDevID. an 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.
RPL "IPv6 Routing Protocol for Low-Power and Lossy Networks". The RPL "IPv6 Routing Protocol for Low-Power and Lossy Networks". The
routing protocol used in the ACP. routing protocol used in the ACP.
MASA (service) "Manufacturer Authorized Signing Authority". A MASA (service) "Manufacturer Authorized Signing Authority". A
vendor/manufacturer or delegated cloud service on the Internet vendor/manufacturer or delegated cloud service on the Internet
used as part of the BRSKI protocol. used as part of the BRSKI protocol.
sUDI "secured Unique Device Identifier". Another term not used in sUDI "secured Unique Device Identifier". Another term not used in
this document to refer to an IDevID. this document to refer to an IDevID.
UDI "Unique Device Identifier". In the context of this document UDI "Unique Device Identifier". In the context of this document
unsecured identity information of a device typically consisting of unsecured identity information of a device 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 "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 ULA A "Unique Local Address" (ULA) is an IPv6 address in the block
addresses. ACP addresses are ULA. fc00::/7, defined in [RFC4193]. It is the approximate IPv6
counterpart of the IPv4 private address ([RFC1918]).
3. Use Cases for an Autonomic Control Plane 3. Use Cases for an Autonomic Control Plane
3.1. An Infrastructure for Autonomic Functions 3.1. An Infrastructure for Autonomic Functions
Autonomic Functions need a stable infrastructure to run on, and all Autonomic Functions need a stable infrastructure to run on, and all
autonomic functions should use the same infrastructure to minimise autonomic functions should use the same infrastructure to minimise
the complexity of the network. This way, there is only need for a the complexity of the network. This way, there is only need for a
single discovery mechanism, a single security mechanism, and other single discovery mechanism, a single security mechanism, and other
processes that distributed functions require. processes that distributed functions require.
3.2. Secure Bootstrap over an Unconfigured Network 3.2. Secure Bootstrap over an Unconfigured Network
Today, bootstrapping a new device typically requires all devices Today, bootstrapping a new device typically requires all devices
between a controlling node (such as an SDN controller) and the new between a controlling node (such as an SDN controller) and the new
device to be completely and correctly addressed, configured and device to be completely and correctly addressed, configured and
secured. Therefore, bootstrapping a network happens in layers around secured. Therefore, bootstrapping a network happens in layers around
the controller. Without console access (for example through an out the controller. Without console access (for example through an out
of band network) it is not possible today to make devices securely of band network) it is not possible today to make devices securely
reachable before having configured the entire network between. reachable before having configured the entire network leading up to
them.
With the ACP, secure bootstrap of new devices can happen without With the ACP, secure bootstrap of new devices can happen without
requiring any configuration on the network. A new device can requiring any configuration on the network. A new device can
automatically be bootstrapped in a secure fashion and be deployed automatically be bootstrapped in a secure fashion and be deployed
with a domain certificate. This does not require any configuration with a domain certificate. This does not require any configuration
on intermediate nodes, because they can communicate through the ACP. on intermediate nodes, because they can communicate securely through
the ACP.
3.3. Data Plane Independent Permanent Reachability 3.3. Data Plane Independent Permanent Reachability
Today, most critical control plane protocols and network management Today, most critical control plane protocols and network management
protocols are running in the data plane (global routing table) of the protocols are running in the data plane (global routing table) of the
network. This leads to undesirable dependencies between control and network. This leads to undesirable dependencies between control and
management plane on one side and the data plane on the other: Only if management plane on one side and the data plane on the other: Only if
the data plane is operational, will the other planes work as the data plane is operational, will the other planes work as
expected. expected.
skipping to change at page 10, line 25 skipping to change at page 10, line 32
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. use ULA addressing for this purpose.
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. It MUST NOT be tied to a
particular protocol. 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 default mode of operation of the ACP is hop-by-hop, because this The default mode of operation of the ACP is hop-by-hop, because this
interaction can be built on IPv6 link local addressing, which is interaction can be built on IPv6 link local addressing, which is
autonomic, and has no dependency on configuration (requirement 1). autonomic, and has no dependency on configuration (requirement 1).
It may be necessary to have ACP connectivity over non-autonomic It may be necessary to have ACP connectivity over non-autonomic
nodes, for example to link autonomic nodes over the general Internet. nodes, for example to link autonomic nodes over the general Internet.
skipping to change at page 10, line 49 skipping to change at page 11, line 10
5. Overview 5. Overview
The Autonomic Control Plane is constructed in the following way (for The Autonomic Control Plane is constructed in the following way (for
details, see Section 6): details, see Section 6):
1. An autonomic node creates a virtual routing and forwarding (VRF) 1. An autonomic node creates a virtual routing and forwarding (VRF)
instance, or a similar virtual context. instance, or a similar virtual context.
2. It determines, following a policy, a candidate peer list. This 2. It determines, following a policy, a candidate peer list. This
is the list of nodes to which it should establish an Autonomic is the list of nodes to which it should establish an Autonomic
Control Plane. Default policy is: To all adjacent nodes in the Control Plane. Default policy is: To all link-layer adjacent
same domain. nodes in the same autonomic domain.
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. It then establishes a secure tunnel of the negotiated channel
type. These tunnels are placed into the previously set up VRF. type. These tunnels are placed into the previously set up VRF.
This creates an overlay network with hop-by-hop tunnels. This creates an overlay network with hop-by-hop tunnels.
5. Inside the ACP VRF, each node sets up a virtual (loopback) 5. Inside the ACP VRF, each node sets up a virtual (loopback)
interface with its ULA IPv6 address. interface with its ULA IPv6 address.
skipping to change at page 12, line 37 skipping to change at page 13, line 10
Section 6.6). The ACP does not mandate specific mechanism by which Section 6.6). The ACP does not mandate specific mechanism by which
this certificate information is provisioned onto the ACP device, it this certificate information is provisioned onto the ACP device, it
only requires the following ACP specific information field in its only requires the following ACP specific information field in its
LDevID as well as the LDevIDs of candidate ACP peers. See LDevID as well as the LDevIDs of candidate ACP peers. See
Section 10.1 for more information about enrollment or provisioning Section 10.1 for more information about enrollment or provisioning
options. options.
6.1.1. ACP information 6.1.1. ACP information
The domain certificate (LDevID) of an autonomic node MUST contain ACP The domain certificate (LDevID) of an autonomic node MUST contain ACP
specific information, specifically the domain name, the address of specific information, specifically the domain name, and the ACP
the device in the ACP with the Zone-ID set to zero ("ACP address"). address of the device. This information MUST be encoded in the
This information MUST be encoded in the LDevID in the subjectAltName LDevID in the subjectAltName / rfc822Name field according to the
/ rfc822Name field in the following way: following ABNF definition ([RFC5234]):
anima.acp+<acp-address>{+<rsub>{+<extensions>}}@<domain> anima.acp+<acp-address>[+<rsub>{+<extensions>}}@<domain>
acp-information = acp-device-info "@" acp-domain
acp-device-info = "ani.acp+" acp-address [ "+" rsub extensions ]
acp-address = 32hex-dig
hex-dig = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
rsub = [ domain-name ] ; empty if not used
acp-domain = domain-name
routing-subdomain = [ rsub " ." ] acp-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: Example:
anima.acp+fda379A6f6ee00000200000064000001+area51.research@acp.exampl acp-information = anima.acp+fda379A6f6ee00000200000064000000+area51
e.com .research@acp.example.com
The acp-address MUST be specified as a string of 32 hex characters routing-subdomain = area51.research.acp.example.com
with only lower letters a-f and numbers 0-9 so that the local part of
the address can matches the simple dot-atom format of [RFC5322] (":"
are not allowed in that format).
<domain> is used to indicate the Autonomic Domain across which all "acp-address" can not use standard IPv6 address formats because it
ACP nodes trust each other and are willing to build ACP channel with must match the simple dot-atom format of [RFC5322]. ":" are not
each other. See Section 6.6. It SHOULD be the FQDN of a domain allowed in that format.
"acp-domain" is used to indicate the Autonomic Domain across which
all ACP nodes trust each other and are willing to build ACP channel
with each other. See Section 6.6. It 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 name is globally unique and method to ensure that the acp-domain is globally unique and collision
collision of ACP addresses would therefore only happen due to ULA of ACP addresses would therefore only happen due to ULA hash
hash collisions. If the operator does not own any FQDN, it should collisions. If the operator does not own any FQDN, it should choose
choose am FQDN format string that intends to be equally unique. a string in FQDN format that intends to be equally unique.
{<rsub>.}<domain> is the autonomic "routing subdomain" that is used "routing-subdomain" is the autonomic "routing subdomain" that is used
used in addressing to calculate the hash used in the creation of the used in addressing to calculate the hash used in the creation of the
ACP address of the device. As the name implies, every routing ACP address of the device. As the name implies, every routing
subdomain is also a separate routing subdomain. <rsub> is optional subdomain is also a separate routing subdomain. "rsub" is optional
and should only used when its impacts are understood. The domain and should only used when its impacts are understood. When "rsub" is
without any leading rsub field is also just another routing not used, "routing-subdomain" is "acp-domain".
subdomain.
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 "acp-information" is 254 characters and
the maximum size of acp-device-info is 64 characters according to
[RFC5280] that is referring to [RFC2821] (superceeded by [RFC5321]).
The subjectAlName / rfc822Name encoding of the ACP domain name and The subjectAlName / rfc822Name encoding of the ACP domain name and
ACP address is used for the following reasons: ACP address is used for the following reasons:
o There are a wide range of pre-existing protocols/services where o There are a wide range of pre-existing protocols/services where
authentication with LDevID is desirable. Enrolling and authentication with LDevID is desirable. Enrolling and
maintaining separate LDevIDs for each of these protocols/services maintaining separate LDevIDs for each of these protocols/services
is often undesirable overhead. Therefore, the information element is often undesirable overhead. Therefore, the information element
required for the ACP in the domain certificate should be encoded required for the ACP in the domain certificate should be encoded
in a way that minimizes the possibility of creating in a way that minimizes the possibility of creating
incompatibilites with such other uses beside the authentication incompatibilites with such other uses beside the authentication
skipping to change at page 14, line 26 skipping to change at page 15, line 23
conflicts would likely be beneficial. conflicts would likely be beneficial.
o rfc822Name encoding is quite flexible. We choose to encode the o rfc822Name encoding is quite flexible. We choose to encode the
full ACP address AND the domain name with sub part into a single full ACP address AND the domain name with sub part into a single
rfc822Name information element it, so that it is easier to rfc822Name information element it, so that it is easier to
examine/use the encoded "ACP information (field)". examine/use the encoded "ACP information (field)".
o The format of the rfc822Name is choosen so that an operator can o The format of the rfc822Name is choosen so that an operator can
set up a mailbox called anima.acp@<domain> that would receive set up a mailbox called anima.acp@<domain> that would receive
emails sent towards the rfc822Name of any AN device inside a emails sent towards the rfc822Name of any AN device inside a
domain. This is possible because components behind a plus symbol domain. This is possible because in many modern mail systems,
are considered part of a single mailbox. In other words, it is components behind a plus symbol are considered part of a single
not necessary to set up a separate mailbox for every autonomic mailbox. In other words, it is not necessary to set up a separate
devices ACP information field, but only one for the whole domain. mailbox for every autonomic devices ACP information field, but
only one for the whole domain.
o In result, if any unexpected use of the ACP addressing information o In result, if any unexpected use of the ACP addressing information
in a certificate happens, it is benign and detectable: it would be in a certificate happens, it is benign and detectable: it would be
mail to that mailbox. mail to that mailbox.
See section 4.2.1.6 of [RFC5280] for details on the subjectAltName See section 4.2.1.6 of [RFC5280] for details on the subjectAltName
field. field.
6.1.2. Maintenance 6.1.2. Maintenance
skipping to change at page 15, line 8 skipping to change at page 16, line 8
renew their domain certificate. The ACP address of at least one such renew their domain certificate. The ACP address of at least one such
EST server SHOULD have been enrolled/provisioned into the ACP device EST server SHOULD have been enrolled/provisioned into the ACP device
during initial installation of the domain certificate. during initial installation of the domain certificate.
EST servers MUST announce their service via GRASP in the ACP through EST servers MUST announce their service via GRASP in the ACP through
M_FLOOD messages: M_FLOOD messages:
Example: Example:
[M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000, [M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000,
["AN_join_registrar", SYNCH-FLAG, 255, "EST-TLS"], ["AN_join_registrar", 4, 255, "EST-TLS"],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fda379a6f6ee0000200000064000001', TCP, 80] h'fda379a6f6ee0000200000064000001', 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 = ["AN_join_registrar", objective-flags, loop-count, objective = ["AN_join_registrar", objective-flags, loop-count,
objective-value] objective-value]
objective-flags = SYNCH-FLAG ; as in GRASP spec objective-flags = sync-only ; as in GRASP spec
loop-count = 255 ; mandatory maximum sync-only = 4 ; M_FLOOD only requires synchronization
objective-value = text ; name of the (list of) of supported loop-count = 255 ; mandatory maximum
; protocols: "EST-TLS" for RFC7030. objective-value = text ; name of the (list of) of supported
; protocols: "EST-TLS" for RFC7030.
The M_FLOOD message MUST be sent periodically. The period is subject The M_FLOOD message MUST be sent periodically. The period is subject
to network administrator policy (EST server configuration). It must to network administrator policy (EST server configuration). It must
be so low that the aggregate amount of periodic M_FLOODs from all EST be so low that the aggregate amount of periodic M_FLOODs from all EST
servers causes negligible traffic across the ACP. servers causes negligible traffic across the ACP.
In the above (recommended) example the period could be 60 seconds and In the above (recommended) example the period could be 60 seconds and
the indicated ttl of 180000 msec means that the objective would the indicated ttl of 180000 msec means that the objective would
continuously be cached by ACP devices even when two out of three continuously be cached by ACP devices even when two out of three
messages are dropped in transit (which is unlikely because GRASP hop- messages are dropped in transit (which is unlikely because GRASP hop-
skipping to change at page 16, line 43 skipping to change at page 17, line 43
CA chain where the assigning CA has enough peformance to manage short CA chain where the assigning CA has enough peformance to manage short
lived certificates. lived certificates.
See Section 10.1 for further optimizationss of certificate See Section 10.1 for further optimizationss of certificate
optimizations when BRSKI can be used. optimizations when BRSKI can be used.
6.2. AN Adjacency Table 6.2. AN Adjacency Table
To know to which nodes to establish an ACP channel, every autonomic To know to which nodes to establish an ACP channel, every autonomic
node maintains an adjacency table. The adjacency table contains node maintains an adjacency table. The adjacency table contains
information about adjacent autonomic nodes, at a minimum: node-ID, IP information about adjacent autonomic nodes, at a minimum: node-ID,
address, domain, certificate. An autonomic device MUST maintain this Link-local IPv6 address (discovered by GRASP as explained below),
domain, certificate. An autonomic device MUST maintain this
adjacency table up to date. This table is used to determine to which adjacency table up to date. This table is used to determine to which
neighbor an ACP connection is established. neighbor an ACP connection is established.
Where the next autonomic device is not directly adjacent, the Where the next autonomic device is not directly adjacent, the
information in the adjacency table can be supplemented by information in the adjacency table can be supplemented by
configuration. For example, the node-ID and IP address could be configuration. For example, the node-ID and IP address could be
configured. 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 autonomic node's certificate. However, trust of the adjacent autonomic node's certificate. However,
subsequent steps MUST always start with authenticating the peer. subsequent steps MUST always start with authenticating the peer.
The adjacency table contains information about adjacent autonomic The adjacency table contains information about adjacent autonomic
nodes in general, independently of their domain and trust status. nodes in general, independently of their domain and trust status.
The next step determines to which of those autonomic nodes an ACP The next step determines to which of those autonomic nodes an ACP
connection should be established. connection should be established.
Interaction between ACP and other autonomic elements like GRASP (see
below) or ASAs should be via an API that allows (appropriately access
controlled) read/write access to the AN Adjacency Table.
Specification of such an API is subject to future work.
6.3. Neighbor Discovery with DULL GRASP 6.3. Neighbor Discovery with DULL GRASP
Because of the the considerations in Section 10.2, the ACP uses DULL Because of the the considerations in Section 10.2, the ACP uses DULL
(Discovery Unsolicited Link-Local) insecure instances of GRASP for (Discovery Unsolicited Link-Local) insecure instances of GRASP for
discovery of ACP neighbors. See section 3.5.2.2 of discovery of ACP neighbors. See section 3.5.2.2 of
[I-D.ietf-anima-grasp] for its formal definition. [I-D.ietf-anima-grasp] for its formal definition.
The ACP uses one instance of DULL GRASP for every physical L2 subnet The ACP uses one instance of DULL GRASP for every physical L2 subnet
of the ACP device to discovery physically adjacent candidate ACP of the ACP device to discovery physically adjacent candidate ACP
neighbors. Ideally, all physical interfaces SHOULD be brought up neighbors. Ideally, all physical interfaces SHOULD be brought up
skipping to change at page 18, line 8 skipping to change at page 19, line 13
the same time. the same time.
An autonomic node announces itself to potential ACP peers by use of An autonomic node announces itself to potential ACP peers by use of
the "AN_ACP" objective. This is a synchronization objective intended the "AN_ACP" objective. This is a synchronization objective intended
to be flooded on a single link using the GRASP Flood Synchronization to 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, 1, [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 180000,
["AN_ACP", SYNCH-FLAG, 1, "IKEv2"], ["AN_ACP", 4, 1, "IKEv2"],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80000000000000c0011001FEEF0000, UDP, 15000] h'fe80000000000000c0011001FEEF0000, UDP, 15000]
] ]
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 = ; as in the GRASP specification objective-flags = sync-only ; as in the GRASP specification
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 = text ; name of the (list of) secure
; channel negotiation protocol(s) ; channel negotiation protocol(s)
The objective-flags field is set to indicate synchronization. The objective-flags field is set to indicate synchronization.
The ttl and loop-count are fixed at 1 since this is a link-local The loop-count is fixed at 1 since this is a link-local operation.
operation.
In the above (recommended) example the period of sending of the
objective could be 60 seconds the indicated ttl of 180000 msec means
that the objective would be cached by ACP devices even when two out
of 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
autonomic node on the sending interface. autonomic node on the sending interface.
The 'objective-value' parameter is (normally) a string indicating the The 'objective-value' parameter is (normally) a string indicating the
skipping to change at page 22, line 33 skipping to change at page 23, line 47
The following sections define the security association protocols that The following sections define the security association protocols that
we consider to be important and feasible to specify in this document: we consider to be important and feasible to specify in this document:
6.7.1. ACP via IKEv2 6.7.1. ACP via IKEv2
An autonomic device announces its ability to support IKEv2 as the ACP An autonomic device announces its ability to support IKEv2 as the ACP
secure channel protcol in GRASP as "IKEv2". secure channel protcol in GRASP as "IKEv2".
6.7.1.1. Native IPsec 6.7.1.1. Native IPsec
To run ACP via IPsec transport mode, no further IANA assignments/ To run ACP via IPsec natively, no further IANA assignments/
definitions are required. All autonomic devices supporting IPsec definitions are required. An ACP devices supporting native IPsec
MUST support IPsec security setup via IKEv2, transport mode MUST use IPsec security setup via IKEv2, tunnel mode, local and peer
encapsulation via the device and peer link-local IPv6 addresses, link-local IPv6 addresses used for encapsuation, ESP with AES256 for
AES256 encryption and SHA256 hash. encryption and SHA256 hash.
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 transport 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
packets received from any other ACP device across the ACP secure
channels, and not only its own generated ACP packets. With IPsec
transport mode, it would only be possible to send packets originated
by the ACP device itself.
ESP is used because ACP mandates the use of encryption for ACP secure
channels.
6.7.1.2. IPsec with GRE encapsulation 6.7.1.2. IPsec with GRE encapsulation
In network devices it is often easier to provide virtual interfaces In network devices it is often more common to implement high
on top of GRE encapsulation than natively on top of a simple IPsec performance virtual interfaces on top of GRE encapsulation than
association. On those devices it may be necessary to run the ACP natively on top of a native IPsec association. On those devices it
secure channel on top of a GRE connection protected by the IPsec may be beneficial to run the ACP secure channel on top of GRE
association. The requirements for the IPsec association are the same protected by the IPsec association.
as in the native IPsec case, but instead of directly carrying the ACP
IPv6 packets, the payload is an ACP IPv6 packet inside GRE/IPv6. The To run ACP via GRE/IPsec, no further IANA assignments/definitions are
mandatory security profile is the same as for native IPsec: peer required. The ACP device MUST support IPsec security setup via
link-local IPv6 addresses, AES256 encryption, SHA256 hash. IKEv2, IPsec transport mode, local and peer link-local IPv6 addresses
used for encapsuation, ESP with AES256 encryption and SHA256 hash.
When GRE is used, transport mode is sufficient because the routed ACP
packets are not "tunneled" by IPsec but rather by GRE: IPsec only has
to deal with the GRE/IP packet which always uses the local and peer
link-local IPv6 addresses and is therefore applicable to transport
mode.
ESP is used because ACP mandates the use of encryption for ACP secure
channels.
In terms of IKEv2 negotiation, this means the initiator must offer to In terms of IKEv2 negotiation, this means the initiator must offer to
support IPsec transport mode with next protocol equal to GRE (47), support IPsec transport mode with next protocol equal to GRE (47)
followed by 41 (IPv6) (because native IPsec is required to be followed by the offer for native IPsec as described above (because
supported, see below). that option is mandatory to support).
If IKEv2 initiator and responder support GRE, it will be selected. If IKEv2 initiator and responder support GRE, it will be selected.
The version of GRE to be used must the according to [RFC7676]. The version of GRE to be used must the according to [RFC7676].
6.7.2. ACP via dTLS 6.7.2. ACP via dTLS
We define the use of ACP via dTLS in the assumption that it is likely We define the use of ACP via dTLS in the assumption that it is likely
the first transport encryption code basis supported in some classes the first transport encryption code basis supported in some classes
of constrained devices. of constrained devices.
skipping to change at page 24, line 13 skipping to change at page 25, line 43
these protocols. these protocols.
6.8. GRASP in the ACP 6.8. GRASP in the ACP
6.8.1. GRASP as a core service of the ACP 6.8.1. GRASP as a core service of the ACP
The ACP MUST run an instance of GRASP inside of it. It is a key part The ACP MUST run an instance of GRASP inside of it. It is a key part
of the ACP services. 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 it was designs such distributed discovery does not exist at all or was added
added as an afterthought and relied upon inconsistently resulting in as an afterthought and relied upon inconsistently.
diminished self configuration capabilities. of prior solutions.
The ACP does not provide generic IP multicast services, but only IP The ACP does not use IP multicast routing nor does it provide generic
unicast which is realized via the RPL routing protocol (described IP multicast services, but only IP unicast which is realized via the
below) and objective discovery and negotiation realized via the ACP RPL routing protocol (described below). Instead of IP multicast
instance of GRASP. We consider this to be a more lightweight, routing, the ACP provides objective discovery and negotiation
modular and easier to extend approach than trying to put service realized via the ACP instance of GRASP. We consider this to be a
announcement and discovery onto some autoconfigured network wide IP more lightweight, modular and easier to extend approach than trying
multicast layer (for which so far there is no good definition) or to put service announcement and discovery onto some autoconfigured
embed it into some IGP flooding mechanism (which makes it less network wide IP multicast layer (for which so far there is no good
modular and agile to improve upon). definition) or embed it into some IGP flooding mechanism (which makes
it less modular and agile to improve upon).
6.8.2. ACP as the Security and Transport substrate for GRASP 6.8.2. ACP as the Security and Transport substrate for GRASP
In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the
security and transport substrate for the GRASP instance run inside security and transport substrate for the GRASP instance run inside
the ACP. 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 using the ACP virtual interfaces. Whenever the ACP of GRASP is only using the virtual interfaces created by the ACP for
adds or deletes such an interface (because of new ACP secure channels ACP GRASP. Whenever the ACP adds or deletes such an interface
or loss thereof), the ACP needs to indicate this to the ACP instance (because of new ACP secure channels or loss thereof), the ACP needs
of GRASP. The ACP exists also in the absence of any active ACP to indicate this to the ACP instance of GRASP. The ACP exists also
neighbors. It is created when the device has a domain certificate. in the absence of any active ACP neighbors. It is created when the
In this case ASAs using GRASP running on the same device would still device has a domain certificate. In this case ASAs using GRASP
need to be able to discover each others objectives. When the ACP running on the same device would still need to be able to discover
does not exist ASAs leveraging the ACP instance of GRASP via APIs each others objectives. When the ACP does not exist, ASAs leveraging
MUST still be able to operate, and MUST be able to understand that the ACP instance of GRASP via APIs MUST still be able to operate, and
there is no ACP and that therefore the ACP instance of GRASP can not MUST be able to understand that there is no ACP and that therefore
provide services. the ACP instance of GRASP can not provide services.
GRASP inside the ACP uses link-local UDP IPv6 multicast across the GRASP unicast messages inside the ACP to a non-link-local ACP peer
ACP virtual interfaces for GRASP neighbor discovery and IPv6 over TLS address use TLS 1.2 ([RFC5246]) connections with AES256 encryption
across the ACP virtual interfaces for any of its unicast messages. and SHA256. Mutual authentication is via the domain certificates
TLS is TLS 1.2 ([RFC5246]) with AES256 encryption and SHA256. using the same rules as for secure channels (Section 6.6). GRASP
Authentication is via the the domain certificates on both sides. unicast messages inside the ACP to link-local ACP neighbor addresses
use TCP.
TLS is mandated for GRASP because the ACP secure channel mandatory GRASP link-local multicast messages are targeted for a specific ACP
authentication and encryption protects only against attacks from the virtual interface (as defined Section 6.12.5) but are sent by the ACP
outside but not against attacks from the inside - compromised ACP into an equally built ACP GRASP virtual interface constructed from
members that have (not yet) been detected and removed (eg: via domain the TCP connection(s) to the IPv6 link-local neighbor address(es) on
certificate revocation / expiry). the underlying ACP virtual interface. If the ACP GRASP virtual
interface has two or more neighbors, the GRASP link-local multicast
messages are replicated to all neighbor TCP connections.
Eavesdropping/spoofing by a compromised ACP device is possible TLS and TLS connections for GRASP in the ACP use the IANA assigned
because the provider and consumer of an objective have no unique TCP port for GRASP (7107). Effectively the transport stack is
information about the other side that would allow them to distinguish expected to be TLS for connections from/to the ULA address and TCP
a benevolent from a compromised peer. The compromised ACP device for connections from/to link-local addreses on the ACP virtual
would simply announce the objective as well, potentially filter the interfaces.
original objective in GRASP when it is a Man In The Middle (MITM) and
act as an application level proxy. This of course requires that the 6.8.2.1. Discussion
compromised ACP node understand the semantic of the GRASP negotiation
to an extend that allows it to proxy it without being detected. TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local
messages is used because these messages are flooded across
potentially many hops to all ACP devices and a single link with even
temporary packet loss issues (eg: WiFi/Powerline link) can reduce the
probability for loss free transmission so much that applications
would want to increase the frequency with which they send these
messages. This would result in more traffic flooding than hop-by-hop
reliable retransmission as provided for by TCP.
TLS is mandated for GRASP non-link-local unicast because the ACP
secure channel mandatory authentication and encryption protects only
against attacks from the outside but not against attacks from the
inside: Compromised ACP members that have (not yet) been detected and
removed (eg: via domain certificate revocation / expiry).
If GRASP peer connections would just use TCP, compromised ACP members
could simply eavesdrop passively on GRASP peer connections for whom
they are onpath (man in the middle). Or intercept and modify them.
With TLS, it is not possible to completely eliminate problems with
compromised ACP members, but it is a lot more complex for them.
With TLS, eavesdropping/spoofing by a compromised ACP device is still
possible because the provider and consumer of an objective have no
unique information about the other side that would allow them to
distinguish a benevolent from a compromised peer. The compromised
ACP device would simply announce the objective as well, potentially
filter the original objective in GRASP when it is a Man In The Middle
(MITM) and act as an application level proxy. This of course
requires that the compromised ACP node understand the semantic of the
GRASP negotiation to an extend that allows it to proxy it without
being detected, but in an AN environment this is quite likely.
The GRASP TLS connections are run like any other ACP traffic through
the ACP secure channels. This leads to double authentication/
encryption. Future work optimizations can minimize could run GRASP
beside the secure channel to avoid this but it is unclear how
beneficial/feasible this is:
o The security considerations for GRASP change against attacks from
non-ACP (eg: "outside") nodes: TLS is subject to reset attacks
while secure channel protocols may be not (eg: IPsec is not).
o The secure channel method may leverage hardware acceleration and
there may be little or no gain in eliminating it.
o The GRASP TLS connections need to implement any additional
security options that are required for secure channels. For
example the closing of connections when the peers certificate has
expired.
6.9. Context Separation 6.9. Context Separation
The ACP is in a separate context from the normal data plane of the The ACP is in a separate context from the normal data plane of the
device. This context includes the ACP channels IPv6 forwarding and device. This context includes the ACP channels IPv6 forwarding and
routing as well as any required higher layer ACP functions. routing as well as any required higher layer ACP functions.
In classical network device platforms, a dedicated so called "Virtual In classical network device platforms, a dedicated so called "Virtual
routing and forwarding instance" (VRF) is one logical implementation routing and forwarding instance" (VRF) is one logical implementation
option for the ACP. If possible by the platform SW architecture, option for the ACP. If possible by the platform SW architecture,
skipping to change at page 27, line 28 skipping to change at page 30, line 17
|FD| hash(subdomain) | Type | (sub-scheme) | |FD| hash(subdomain) | Type | (sub-scheme) |
+--+-----------------+------+--------------------------------------+ +--+-----------------+------+--------------------------------------+
Figure 2: ACP Addressing Base Scheme Figure 2: ACP Addressing Base Scheme
The first 48 bits follow the ULA scheme, as defined in [RFC4193], to The first 48 bits follow the ULA scheme, as defined in [RFC4193], to
which a type field is added: which a type field is added:
o "FD" identifies a locally defined ULA address. o "FD" identifies a locally defined ULA address.
o The ULA "global ID" is set here to be a hash of the subdomain o The ULA "global ID" (term from [RFC4193]) is set here to be a hash
name, which results in a pseudo-random 40 bit value. It is of the subdomain name, which results in a pseudo-random 40 bit
calculated as the first 40 bits of the SHA256 hash of the value. It is calculated as the first 40 bits of the SHA256 hash
subdomain name, in the example of Section 6.1.1 of the subdomain name, in the example of Section 6.1.1
"area51.research.acp.example.com". "area51.research.acp.example.com".
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 subdomain name SHOULD NOT be assumed by any autonomic hash of the subdomain name SHOULD NOT be assumed by any autonomic
device during normal operations. The hash function is only device during normal operations. The hash function is only
executed during the creation of the certificate. If BRSKI is used executed during the creation of the certificate. If BRSKI is used
then the registrar will create the ACP information field in then the registrar will create the ACP information field in
response to the CSR Attribute Request by the pledge. response to the CSR Attribute Request by the pledge.
o Type: This field allows different address sub-schemes in the o Type: This field allows different address sub-schemes. This
future. The goal is to start with a single sub-schemes, but to addresses the "upgradability" requirement. Assignment of types
allow for extensions later if and when required. This addresses for this field should be maintained by IANA.
the "upgradability" requirement. Assignment of types for this
field should be maintained by IANA. The sub-scheme may imply a range or set of addresses assigned to the
device, this is called the ACP address range/set and explained in
each sub-scheme.
6.10.3. ACP Zone Addressing Sub-Scheme 6.10.3. ACP Zone Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 00b (zero) The sub-scheme defined here is defined by the Type value 00b (zero)
in the base scheme. in the base scheme.
64 64 64 64
+-----------------+---------+---++-----------------------------+---+ +-----------------+---------+---++-----------------------------+---+
| (base scheme) | Zone-ID | Z || Device-ID | | (base scheme) | Zone-ID | Z || Device-ID |
| | | || Registrar-ID | Device-Number| V | | | | || Registrar-ID | Device-Number| V |
skipping to change at page 28, line 41 skipping to change at page 31, line 32
purpose. purpose.
o Device-Number (Device-Number): A number which is unique for a o Device-Number (Device-Number): A number which is unique for a
given registrar, to identify the device. This can be a given registrar, to identify the device. This can be a
sequentially assigned number. sequentially assigned number.
o V (1 bit): Virtualization bit: 0: Indicates the ACP itself o V (1 bit): Virtualization bit: 0: Indicates the ACP itself
("autonomic node base system); 1: Indicates the optional "host" ("autonomic node base system); 1: Indicates the optional "host"
context on the ACP device (see below). context on the ACP device (see below).
When referring to the Device-ID of an ACP device overall, the V In the Zone addressing sub-scheme, the ACP address in the certificate
bit(s) is/are always "0". This is also the address used in the ACP has Zone and V fields as all zero bits. The ACP address set includes
information in the domain certificate. The V bit(s) identify the addresses with any Zone value and any V value.
bits the device can assign itself. The Device knows how many bits
those are from the addressing sub-scheme (see below for a Sub-Scheme
with more than one V-bit).
The "Device-ID" itself is unique in a domain (i.e., the Zone-ID is The "Device-ID" itself is unique in a domain (i.e., the Zone-ID is
not required for uniqueness). Therefore, a device can be addressed not required for uniqueness). Therefore, a device can be addressed
either as part of a flat hierarchy (zone ID = 0), or with an either as part of a flat hierarchy (zone ID = 0), or with an
aggregation scheme (any other zone ID). A address with zone-ID = 0 aggregation scheme (any other zone ID). A address with zone-ID = 0
is an identifier, with another zone-ID as a locator. See is an identifier, with another zone-ID as a locator. See
Section 6.10.3.1 for a description of the zone bits. Section 6.10.3.1 for a description of the zone bits.
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
skipping to change at page 31, line 5 skipping to change at page 33, line 40
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 aggregateable routing approach across them. Z=0 use an integrated aggregateable routing approach across them. Z=0
(Zone sub-scheme) would then be used for network wide unique, (Zone sub-scheme) would then be used for network wide unique,
registrar assigned (and certificate protected) Device-IDs primarily registrar assigned (and certificate protected) Device-IDs primarily
for ACP devices while Z=1 would be used for device-level assigned for ACP devices while Z=1 would be used for device-level assigned
Interface Identifiers primarily for non-ACP-devices. Interface Identifiers primarily for non-ACP-devices.
Manual addressing sub-scheme addresses are not assumed to be used the
ACP information field in certificates. If they are used, then value
of the Interface Identifier is left for future definitions.
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) || Device-ID | | (base scheme) || Device-ID |
| || Registrar-ID | Device-Number| V | | || Registrar-ID | Device-Number| V |
+---------------------++--------------+--------------+----------+ +---------------------++--------------+--------------+----------+
skipping to change at page 32, line 5 skipping to change at page 34, line 44
the Device-Number is 33 bit long and the V field is 8 bit long. the Device-Number is 33 bit long and the V field is 8 bit long.
"0" bit Device-Numbers are intended to be used for "general "0" bit Device-Numbers are intended to be used for "general
purpose" ACP devices that would potentially have a limited number purpose" ACP devices that would potentially have a limited number
(< 256) of internal users of the ACP that require separate (< 256) of internal users of the ACP that require separate
V(irtual) addresses. "1" bit Device-Numbers are intended for ACP V(irtual) addresses. "1" bit Device-Numbers are intended for ACP
devices that are ACP edge devices (see Section 8.1.1) or that have devices that are ACP edge devices (see Section 8.1.1) or that have
a large number of internal ACP users requiring separate V(irtual) a large number of internal ACP users requiring separate V(irtual)
addresses. For example large SDN controllers with container addresses. For example large SDN controllers with container
modular software architecture (see Section 8.1.2). modular software architecture (see Section 8.1.2).
In the Vlong addressing sub-scheme, the ACP address in the
certificate has all V field bits as zero. The ACP address set
includes address for the device includes any V value.
6.10.6. Other ACP Addressing Sub-Schemes 6.10.6. Other ACP Addressing Sub-Schemes
Other ACP addressing sub-schemes can be defined if and when required. Other ACP addressing sub-schemes can be defined if and when required.
IANA would need to assign a new "type" for each new addressing sub- IANA would need to assign a new "type" for each new addressing sub-
scheme. With the current allocations, 5 more schemes are possible scheme. With the current allocations, 5 more schemes are possible
without further reducing the number of bits in a future scheme. without further reducing the number of bits in a future scheme.
6.11. Routing in the ACP 6.11. Routing in the ACP
Once ULA address are set up all autonomic entities should run a Once ULA address are set up all autonomic entities should run a
skipping to change at page 36, line 21 skipping to change at page 39, line 15
SHOULD have attach safe mechanisms to operationally discover and log SHOULD have attach safe mechanisms to operationally discover and log
such packets. such packets.
6.12. General ACP Considerations 6.12. General ACP Considerations
Since channels are by default established between adjacent neighbors, Since channels are by default established between adjacent neighbors,
the resulting overlay network does hop by hop encryption. Each node the resulting overlay network does hop by hop encryption. Each node
decrypts incoming traffic from the ACP, and encrypts outgoing traffic decrypts incoming traffic from the ACP, and encrypts outgoing traffic
to its neighbors in the ACP. Routing is discussed in Section 6.11. to its neighbors in the ACP. Routing is discussed in Section 6.11.
6.12.1. Addressing of Secure Channels in the data plane 6.12.1. Performance
There are no performance requirements against ACP implementations
defined in this document because the performance requirements depend
on the intended use case. It is expected that full autonomic devices
with a wide range of ASA can require high forwarding plane
performance in the ACP, for example for telemetry, but that
determination is for future work. Implementations of ACP to solely
support traditional/SDN style use cases can benefit from ACP at lower
performance, especially if the ACP is used only for critical
operations, eg: when the data plane is not available. See
[I-D.ietf-anima-stable-connectivity] for more details.
6.12.2. Addressing of Secure Channels in the data plane
In order to be independent of the Data Plane configuration of global In order to be independent of the Data Plane configuration of global
IPv6 subnet addresses (that may not exist when the ACP is brought IPv6 subnet addresses (that may not exist when the ACP is brought
up), Link-local secure channels MUST use IPv6 link local addresses up), Link-local secure channels MUST use IPv6 link local addresses
between adjacent neighbors. The fully autonomic mechanisms in this between adjacent neighbors. The fully autonomic mechanisms in this
document only specify these link-local secure channels.Section 8.2 document only specify these link-local secure channels. Section 8.2
specify extensions in which secure channels are tunnels, then this specifies extensions in which secure channels are tunnels. For
requirement does not apply. those, this requirement does not apply.
The Link-local secure channels specified in this document therefore The Link-local secure channels specified in this document therefore
depend on basic IPv6 link-local functionality to be auto-enabled by depend on basic IPv6 link-local functionality to be auto-enabled by
the ACP and prohibiting the Data Plane from disabling it. The ACP the ACP and prohibiting the Data Plane from disabling it. The ACP
also depends on being able to operate the secure channel protocol also depends on being able to operate the secure channel protocol
(eg: IPsec / dTLS) across IPv6 link-local addresses, something that (eg: IPsec / dTLS) across IPv6 link-local addresses, something that
may be an uncommon profile. Functionaly, these are the only may be an uncommon profile. Functionaly, these are the only
interactions with the Data Plane that the ACP needs to have. interactions with the Data Plane that the ACP needs to have.
To mitigate these interactions with the Data Plane, extensions to To mitigate these interactions with the Data Plane, extensions to
this document may specify additional layer 2 or layer encapsulations this document may specify additional layer 2 or layer encapsulations
for ACP secure channels as well as other protocols to auto-discover for ACP secure channels as well as other protocols to auto-discover
peer endpoints for such encapsulations (eg: tunneling across L3 or peer endpoints for such encapsulations (eg: tunneling across L3 or
use of L2 only encapsulations). use of L2 only encapsulations).
6.12.2. MTU 6.12.3. MTU
The MTU for ACP secure channels must be derived locally from the The MTU for ACP secure channels must be derived locally from the
underlying link MTU minus the secure channel encapsulation overhead. underlying link MTU minus the secure channel encapsulation overhead.
ACP secure Channel protocols do not need to perform MTU discovery ACP secure Channel protocols do not need to perform MTU discovery
because they are built across L2 adjacencies - the MTU on both sides because they are built across L2 adjacencies - the MTU on both sides
connecting to the L2 connection are assumed to be consistent. connecting to the L2 connection are assumed to be consistent.
Extensions to ACP where the ACP is for example tunneled need to Extensions to ACP where the ACP is for example tunneled need to
consider how to guarantee MTU consistency. This is a standard issue consider how to guarantee MTU consistency. This is a standard issue
with tunneling, not specific to running the ACP across it. Transport with tunneling, not specific to running the ACP across it. Transport
stacks running across ACP can perform normal PMTUD (Path MTU stacks running across ACP can perform normal PMTUD (Path MTU
Discovery). Because the ACP is meant to be prioritize reliability Discovery). Because the ACP is meant to be prioritize reliability
over performance, they MAY opt to only expect IPv6 minimum MTU (1280) over performance, they MAY opt to only expect IPv6 minimum MTU (1280)
to avoid running into PMTUD implementation bugs or underlying link to avoid running into PMTUD implementation bugs or underlying link
MTU mismatch problems. MTU mismatch problems.
6.12.3. Multiple links between nodes 6.12.4. Multiple links between nodes
If two nodes are connected via several links, the ACP SHOULD be If two nodes are connected via several links, the ACP SHOULD be
established across every link, but it is possible to establish the established across every link, but it is possible to establish the
ACP only on a sub-set of links. Having an ACP channel on every link ACP only on a sub-set of links. Having an ACP channel on every link
has a number of advantages, for example it allows for a faster has a number of advantages, for example it allows for a faster
failover in case of link failure, and it reflects the physical failover in case of link failure, and it reflects the physical
topology more closely. Using a subset of links (for example, a topology more closely. Using a subset of links (for example, a
single link), reduces resource consumption on the devices, because single link), reduces resource consumption on the devices, because
state needs to be kept per ACP channel. The negotiation scheme state needs to be kept per ACP channel. The negotiation scheme
explained in Section 6.5 allows Alice (the node with the higher ACP explained in Section 6.5 allows Alice (the node with the higher ACP
address) to drop all but the desired ACP channels to Bob - and Bob address) to drop all but the desired ACP channels to Bob - and Bob
will not re-try to build these secure channels from his side unless will not re-try to build these secure channels from his side unless
Alice shows up with a previously unknown GRASP announcement (eg: on a Alice shows up with a previously unknown GRASP announcement (eg: on a
different link or with a different address announced in GRASP). different link or with a different address announced in GRASP).
6.12.4. ACP interfaces 6.12.5. ACP interfaces
The ACP VRF has conceptually two type of interfaces: The ACP loopback The ACP VRF has conceptually two type of interfaces: The ACP loopback
interface(s) to which the ACP ULA address(es) are assigned and the interface(s) to which the ACP ULA address(es) are assigned and the
"ACP virtual interfaces" that are mapped to the ACP secure channels. "ACP virtual interfaces" that are mapped to the ACP secure channels.
The term loopback interface is commonly referred to internal pseudo The term "loopback interface" is commonly used to refer to internal
interfaces through which the device can only reach itself. In pseudo interfaces through which the device can only reach itself. In
network devices these interfaces are used to hold addresses used by network devices these interfaces are used to hold addresses used by
the transport stack of the system when an address should be reliable the transport stack of the system when an address should be reliable
reachable in the presence of arbitrary link failures. As long as reachable in the presence of arbitrary link failures. As long as
addresses on a loopback interface are routeable in the routing addresses on a loopback interface are routeable in the routing
protocol used, they will be reachable as long as there is at least protocol used, they will be reachable as long as there is at least
one working network path. This is opposed to routeable address one working network path. This is opposed to routeable address
assigned to an externally connected interface. That address will assigned to an externally connected interface. That address will
become unreachable when that interface goes down. For this reason, become unreachable when that interface goes down. For this reason,
the ACP (ULA) address(es) are assigned to loopback type interface. the ACP (ULA) address(es) are assigned to loopback type interface(s).
ACP secure channels, eg: IPsec, dTLS or other future security ACP secure channels, eg: IPsec, dTLS or other future security
associations with neighboring ACP devices can be mapped to ACP associations with neighboring ACP devices can be mapped to ACP
virtual interfaces in different ways: In one case, every ACP secure virtual interfaces in different ways:
channel is mapped into a separate point-to-point ACP virtual
interface. If a physical subnet has more than two ACP capable nodes
(in the same domain), this implementation approach will lead to a
full mesh of ACP virtual interfaces between them. In a more advanced
implementation approach, the ACP will construct a single multi-access
ACP virtual interface for all ACP secure channels to ACP capable
nodes reachable across the same physical subnet. The multi-access
ACP virtual interace needs to replicate link-local IPv6 multicast
packets sent into the interface towards all ACP secure channels
mapped into it. There is no need for all ACP capable nodes on the
same physical multi-access subnet to agree on a common implementation
approach. This is purely a node local decision.
Multi-access ACP virtual interfaces are preferrable because they do ACP point-to-point virtual interface:
reflect the presence of a multi-access physical networks into the
virtual interfaces of the ACP. This makes it for example simpler to Each ACP secure channel is mapped into a separate point-to-point ACP
build services with topology awareness inside the ACP VRF in the same virtual interface. If a physical subnet has more than two ACP
way as they could habe been built running natively on the multi- capable nodes (in the same domain), this implementation approach will
access interfaces. One example is the efficiency of flooding of lead to a full mesh of ACP virtual interfaces between them.
GRASP messages. Assume such a LAN with three ACP neighbors, Alice
Bob and Carol. Alice sends a GRASP link-local multicast message to ACP multi-access virtual interface:
Bob and Carol. If Alices ACP emulates the LAN as one point-to-point
interface to Bob and one to Carol, GRASP itself will send two copies, In a more advanced implementation approach, the ACP will construct a
if Alices ACP emulates a LAN, GRASP will send one packet and the ACP single multi-access ACP virtual interface for all ACP secure channels
will replicate it. The result is the same. The difference happens to ACP capable nodes reachable across the same underlying (physical)
when Bob and Carol receive their packet. If they use point-to-point subnet. IPv6 link-local multicast packets sent into an ACP multi-
ACP virtual interfaces, their GRASP instance would forward the packet access virtual interface are replicated to every ACP secure channel
from Alice to each other as part of the GRASP flooding procedure. mapped into the ACP multicast-access virtual interface. IPv6 unicast
These packets are of course redundant (unnecessary) and would be packets sent into an ACP multi-access virtual interface are sent to
the ACP secure channel that belongs to the ACP neighbor that is the
next-hop in the ACP forwarding table entry used to reach the packets
destination address.
There is no requirement for all ACP devices on the same physical
multi-access subnet to use the same type of ACP virtual interface.
This is purely a node local decision.
ACP devices MUST perform standard IPv6 operations across ACP virtual
interfaces including SLAAC (Stateless Address AutoConfiguration -
[RFC4862]) to assign their IPv6 link local address on the ACP virtual
interface and ND (Neighbor Discovery - [RFC4861]) to discover which
IPv6 link-local neighbor address belongs to which ACP secure channel
mapped to the ACP virtual interface. This is independent of whether
the ACP virtual interface is point-to-point or multi-access.
ACP devices MAY reduce the amount of link-local IPv6 multicast
packets from ND by learning the IPv6 link-local neighbor address to
ACP secure channel mapping from other messages such as the source
address of IPv6 link-local multicast RPL messages - and therefore
forego the need to send Neighbor Solication messages.
ACP devices MUST NOT derive their ACP virtual interface IPv6 link
local address from their IPv6 link-local address used on the
underlying interface (e.g.: the address that is used as the
encapsulation address in the ACP secure channel protocols defined in
this document). This ensures that the ACP virtual interface
operations will not depend on the specifics of the encapsulation used
by the ACP secure channel and that attacks against SLAAC on the
physical interface will not impact the operations of the ACP virtal
interface.
The link-layer address of an ACP virtual interface is the address
used for the underlying interface across which the secure tunnels are
built, typically Ethernet addresses. Because unicast IPv6 packets
sent to an ACP virtual interface are not sent to a link-layer
destination address but rather the correct ACP secure channel, the
link-layer address fields SHOULD be ignored on reception and instead
the ACP secure channel remembered from which the message was
received.
Multi-access ACP virtual interfaces are preferrable implementations
when the underlying interface is a (broadcast) multi-access subnet
because they do reflect the presence of the underlying multi-access
subnet into the virtual interfaces of the ACP. This makes it for
example simpler to build services with topology awareness inside the
ACP VRF in the same way as they could have been built running
natively on the multi-access interfaces.
Consider also the impact of point-to-point vs. multicaccess virtual
interface on the efficiency of flooding via link local multicasted
messages:
Assume a LAN with three ACP neighbors, Alice, Bob and Carol. Alices
ACP GRASP wants to send a link-local GRASP multicast message to Bob
and Carol. If Alices ACP emulates the LAN as one point-to-point
interface to Bob and one to Carol, The sending applications itself
will send two copies, if Alices ACP emulates a LAN, GRASP will send
one packet and the ACP will replicate it. The result is the same.
The difference happens when Bob and Carol receive their packet. If
they use point-to-point ACP virtual interfaces, their GRASP instance
would forward the packet from Alice to each other as part of the
GRASP flooding procedure. These packets are unnecessary and would be
discarded by GRASP on receipt as duplicates. If Bob and Charlies ACP discarded by GRASP on receipt as duplicates. If Bob and Charlies ACP
would emulate a LAN, then this would not happen, because GRASPs would emulate a multi-acccess virtual interface, then this would not
flooding procedure does not send bac packets to the interface they happen, because GRASPs flooding procedure does not replicate back
where received from. packets to the interface that they where received from.
For this reason, the ACP SHOULD map ACP secure channels on multi- Note that link-local GRASP multicast messages are not sent directly
access LANs into multi-access ACP virtual interfaces. as IPv6 link-local multicast UDP messages into ACP virtual
interfaces, but instead into ACP GRASP virtual interfaces, that are
layered on top of ACP virtual interfaces to add TCP reliability to
link-local multicast GRASP messages. Nevertheless, these ACP GRASP
virtual interfaces perform the same replication of message and
therefore result in the same impact on flooding. See Section 6.8.2
for more details.
Care must be taken when creating multi-access ACP virtual interfaces RPL does support operations and correct routing table construction
across ACP secure channels between ACP devices in different domains across non-broadcast multi-access (NBMA) subnets. This is common
or routing subdomains. The policies to be negotiated may be when using many radio technologies. When such NBMA subnets are used,
described as peer-to-peer policies in which case it is easier to they MUST NOT be represented as ACP multi-access virtual interfaces
create point-to-point ACP virtual interfaces for these secure because the replication of IPv6 link-local multicast multicast
channels. messages will not reach all NBMA subnet neighbors. In result, GRASP
message flooding would fail. Instead, each ACP secure channel across
such an interface MUST be represented as a ACP point-to-point virtual
interface. These requirements can be avoided by coupling the ACP
flooding mechanism for GRASP messages directly to RPL (flood GRASP
across DODAG), but such an enhancement is subjet for future work.
Care must also be taken when creating multi-access ACP virtual
interfaces across ACP secure channels between ACP devices in
different domains or routing subdomains. The policies to be
negotiated may be described as peer-to-peer policies in which case it
is easier to create ACP point-to-point virtual interfaces for these
secure channels.
7. ACP support on L2 switches/ports (Normative) 7. ACP support on L2 switches/ports (Normative)
7.1. Why 7.1. Why
ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2
.../ \ \ ... .../ \ \ ...
ANrtrM ------ \ ------- ANrtrN ANrtrM ------ \ ------- ANrtrN
ANswitchM ... ANswitchM ...
Figure 6 Figure 6
Consider a large L2 LAN with ANrtr1...ANrtrN connected via some Consider a large L2 LAN with ANrtr1...ANrtrN connected via some
skipping to change at page 40, line 32 skipping to change at page 45, line 9
where L3 interfaces are assigned to VLANs and each VLAN has where L3 interfaces are assigned to VLANs and each VLAN has
potentially multiple ports. DULL GRASP is run as described potentially multiple ports. DULL GRASP is run as described
individually on each L2 port. When it discovers a candidate ACP individually on each L2 port. When it discovers a candidate ACP
neighbor, it passes its IPv6 link-local address and supported secure neighbor, it passes its IPv6 link-local address and supported secure
channel protocols to the ACP secure channel negotiation that can be channel protocols to the ACP secure channel negotiation that can be
bound to the L3 (VLAN) interface. It will simply use link-local IPv6 bound to the L3 (VLAN) interface. It will simply use link-local IPv6
multicast packets to the candidate ACP neighbor. Once a secure multicast packets to the candidate ACP neighbor. Once a secure
channel is established to such a neighbor, the virtual interface to channel is established to such a neighbor, the virtual interface to
which this secure channel is mapped should then actually be the L2 which this secure channel is mapped should then actually be the L2
port and not the L3 interface to best map the actual physical port and not the L3 interface to best map the actual physical
topology into the ACP virtual interfaces. See Section 6.12.4 for topology into the ACP virtual interfaces. See Section 6.12.5 for
more details about how to map secure channels into ACP virtual more details about how to map secure channels into ACP virtual
interfaces. Note that a single L2 port can still have multiple ACP interfaces. Note that a single L2 port can still have multiple ACP
neighbors if it connect for example to multiple ACP neighbors via a neighbors if it connect for example to multiple ACP neighbors via a
non-ACP enabled switch. The per L2 port ACP virtual interface can non-ACP enabled switch. The per L2 port ACP virtual interface can
threfore still be a multi-access virtual LAN. threfore still be a multi-access virtual LAN.
For example, in the above picture, ANswitch1 would run separate DULL For example, in the above picture, ANswitch1 would run separate DULL
GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even GRASP instances on its ports to ANrtr1, ANswitch2 and ANswitchI, even
though all those three ports may be in the data plane in the same though all those three ports may be in the data plane in the same
(V)LAN and perfom L2 switching between these ports, ANswitch1 would (V)LAN and perfom L2 switching between these ports, ANswitch1 would
skipping to change at page 71, line 31 skipping to change at page 75, line 44
possible need to have maybe as much as 2^12 local addresses for possible need to have maybe as much as 2^12 local addresses for
future encaps in BRSKI like IPinIP. It also would allow fully future encaps in BRSKI like IPinIP. It also would allow fully
autonomic address assignment for ACP connect interfaces from this autonomic address assignment for ACP connect interfaces from this
local address space (on an ACP edge device), subject to approval of local address space (on an ACP edge device), subject to approval of
the implied update to rfc4291/rfc4193 (IID length). Changed name to the implied update to rfc4291/rfc4193 (IID length). Changed name to
Vlong addressing sub-scheme. Vlong addressing sub-scheme.
Added text in response to Brian Carpenters review of draft-ietf- Added text in response to Brian Carpenters review of draft-ietf-
anima-stable-connectivity-04. The stable connectivity draft was anima-stable-connectivity-04. The stable connectivity draft was
vaguely describing ACP connect behavior that is better standardized vaguely describing ACP connect behavior that is better standardized
in this ACP draft: in this ACP draft.
o Added new ACP "Manual" addressing sub-scheme with /64 subnets for o Added new ACP "Manual" addressing sub-scheme with /64 subnets for
use with ACP connect interfaces. Being covered by the ACP ULA use with ACP connect interfaces. Being covered by the ACP ULA
prefix, these subnets do not require additional routing entries prefix, these subnets do not require additional routing entries
for NMS hosts. They also are fully 64-bit IID length compliant for NMS hosts. They also are fully 64-bit IID length compliant
and therefore not subject to 4191bis considerations. And they and therefore not subject to 4191bis considerations. And they
avoid that operators manually assign prefixes from the ACP ULA avoid that operators manually assign prefixes from the ACP ULA
prefixes that might later be assigned autonomiously. prefixes that might later be assigned autonomiously.
o ACP connect auto-configuration: Defined that ACP edge devices, NMS o ACP connect auto-configuration: Defined that ACP edge devices, NMS
skipping to change at page 73, line 11 skipping to change at page 77, line 24
revocation. revocation.
Added fixes from 08-mcr-review-reply.txt (on github): Added fixes from 08-mcr-review-reply.txt (on github):
o AN Domain Names are FQDNs. o AN Domain Names are FQDNs.
o Fixed bit length of schemes, numerical writing of bits (00b/01b). o Fixed bit length of schemes, numerical writing of bits (00b/01b).
o Lets use US american english. o Lets use US american english.
15.16. draft-ietf-anima-autonomic-control-plane-10
6.7.1.* Changed native IPsec encapsulation to tunnel mode
(necessary), explaned why. Added notion that ESP is used, added
explanations why tunnel/transport mode in native vs. GRE cases.
6.10.3/6.10.5 Added term "ACP address range/set" to be able to better
explain how the address in the ACP certificate is actually the base
address (lowest address) of a range/set that is available to the
device.
6.10.4 Added note that manual address sub-scheme addresses must not
be used within domain certificates (only for explicit configuration).
6.12.5 Refined explanation of how ACP virtual interfaces work (p2p
and multipoint). Did seek for pre-existing RFCs that explain how to
built a multi-access interface on top of a full mesh of p2p
connections (6man WG, anima WG mailing lists), but could not find any
prior work that had a succinct explanation. So wrote up an
explanation here. Added hopefully all necessary and sufficient
details how to map ACP unicast packets to ACP secure channel, how to
deal with ND packet details. Added verbage for ACP not to assign the
virtual interface link-local address from the underlying interface.
Addd note that GRAP link-local messages are treated specially but
logically the same. Added paragraph about NBMA interfaces.
From Brian Carpenters review:
Added multiple new RFC references for terms/technologies used.
Fixed verbage in several places.
2. (terminology) Added 802.1AR as reference.
2. Fixed up definition of ULA.
6.1.1 Changed definition of ACP information in cert into ABNF format.
Added warning about maximum size of ACP address field due to domain-
name limitations.
6.2 Mentioned API requirement between ACP and clients leveraging
adjacency table.
6.3 Fixed TTL in GRASP example: msec, not hop-count!.
6.8.2 MAYOR: expanded security/transport substrate text:
Introduced term ACP GRASP virtual interface to explain how GRASP
link-local multicast messages are encapsulated and replicated to
neighbors. Explain how ACP knows when to use TLS vs. TCP (TCP only
for link-local address (sockets).
6.8.2.1 Expanded discussion/explanation of security model. TLS for
GRASP unicsast connections across ACP is double encryption (plus
underlying ACP secure channel), but highly necessary to avoid very
simple man-in-the-middle attacks by compromised ACP members on-path.
Ultimately, this is done to ensure that any apps using GRASP can get
full end-to-end secrecy for information sent across GRASP. But for
publically known ASA services, even this will not provide 100%
security (this is discussed). Also why double encryption is the
better/easier solution than trying to optimize this.
6.12.2 New performance requirements section added.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>. <https://www.rfc-editor.org/info/rfc5322>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)", Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012, RFC 6552, DOI 10.17487/RFC6552, March 2012,
<http://www.rfc-editor.org/info/rfc6552>. <https://www.rfc-editor.org/info/rfc6552>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676, for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015, DOI 10.17487/RFC7676, October 2015,
<http://www.rfc-editor.org/info/rfc7676>. <https://www.rfc-editor.org/info/rfc7676>.
16.2. Informative References 16.2. Informative References
[AR8021] IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/
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-07 (work in progress), July 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-04 (work in progress), July 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-04 (work in progress), July anima-stable-connectivity-05 (work in progress), August
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-14 (work in progress), June draft-ietf-netconf-zerotouch-17 (work in progress),
2017. September 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-16 (work in progress), July 2017.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<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,
<http://www.rfc-editor.org/info/rfc2315>. <https://www.rfc-editor.org/info/rfc2315>.
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, DOI 10.17487/RFC2821, April 2001,
<https://www.rfc-editor.org/info/rfc2821>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<http://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://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,
<http://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,
<http://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[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,
<http://www.rfc-editor.org/info/rfc7404>. <https://www.rfc-editor.org/info/rfc7404>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<http://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap
Analysis for Autonomic Networking", RFC 7576, Analysis for Autonomic Networking", RFC 7576,
DOI 10.17487/RFC7576, June 2015, DOI 10.17487/RFC7576, June 2015,
<http://www.rfc-editor.org/info/rfc7576>. <https://www.rfc-editor.org/info/rfc7576>.
Authors' Addresses Authors' Addresses
Michael H. Behringer (editor) Michael H. Behringer (editor)
Email: michael.h.behringer@gmail.com Email: michael.h.behringer@gmail.com
Toerless Eckert (editor) Toerless Eckert (editor)
Futurewei Technologies Inc. Futurewei Technologies Inc.
2330 Central Expy 2330 Central Expy
 End of changes. 101 change blocks. 
302 lines changed or deleted 607 lines changed or added

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