draft-ietf-anima-autonomic-control-plane-06.txt   draft-ietf-anima-autonomic-control-plane-07.txt 
ANIMA WG M. Behringer, Ed. ANIMA WG M. Behringer, Ed.
Internet-Draft Cisco Systems Internet-Draft
Intended status: Standards Track T. Eckert Intended status: Standards Track T. Eckert, Ed.
Expires: September 28, 2017 Huawei Expires: January 4, 2018 Huawei
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
March 27, 2017 July 3, 2017
An Autonomic Control Plane An Autonomic Control Plane
draft-ietf-anima-autonomic-control-plane-06 draft-ietf-anima-autonomic-control-plane-07
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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 http://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 September 28, 2017. This Internet-Draft will expire on January 4, 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases for an Autonomic Control Plane . . . . . . . . . . 4 2. Use Cases for an Autonomic Control Plane . . . . . . . . . . 4
2.1. An Infrastructure for Autonomic Functions . . . . . . . . 4 2.1. An Infrastructure for Autonomic Functions . . . . . . . . 5
2.2. Secure Bootstrap over an Unconfigured Network . . . . . . 5 2.2. Secure Bootstrap over an Unconfigured Network . . . . . . 5
2.3. Data Plane Independent Permanent Reachability . . . . . . 5 2.3. Data Plane Independent Permanent Reachability . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Self-Creation of an Autonomic Control Plane . . . . . . . . . 8 5. Self-Creation of an Autonomic Control Plane . . . . . . . . . 8
5.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Domain Certificate with ANIMA information . . . . . . 8 5.1.1. Domain Certificate with ACP information . . . . . . . 8
5.1.2. AN Adjacency Table . . . . . . . . . . . . . . . . . 10 5.1.2. AN Adjacency Table . . . . . . . . . . . . . . . . . 10
5.2. Neighbor discovery . . . . . . . . . . . . . . . . . . . 11 5.2. Neighbor discovery . . . . . . . . . . . . . . . . . . . 11
5.2.1. L2 topology considerations . . . . . . . . . . . . . 11 5.2.1. L2 topology considerations . . . . . . . . . . . . . 11
5.2.2. CDP/LLDP/mDNS considerations . . . . . . . . . . . . 12 5.2.2. CDP/LLDP/mDNS considerations . . . . . . . . . . . . 12
5.2.3. Discovery with GRASP . . . . . . . . . . . . . . . . 12 5.2.3. Discovery with GRASP . . . . . . . . . . . . . . . . 12
5.2.4. Discovery and BRSKY . . . . . . . . . . . . . . . . . 13 5.3. Candidate ACP Neighbor Selection . . . . . . . . . . . . 15
5.3. Candidate ACP Neighbor Selection . . . . . . . . . . . . 13 5.4. Channel Selection . . . . . . . . . . . . . . . . . . . . 15
5.4. Channel Selection . . . . . . . . . . . . . . . . . . . . 14 5.5. Candidate ACP Neighbor certificate verification . . . . . 17
5.5. Security Association protocols . . . . . . . . . . . . . 15 5.6. Security Association protocols . . . . . . . . . . . . . 17
5.5.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 15 5.6.1. ACP via IKEv2 . . . . . . . . . . . . . . . . . . . . 17
5.5.2. ACP via GRE/IPsec . . . . . . . . . . . . . . . . . . 16 5.6.2. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 18
5.5.3. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 16 5.6.3. ACP Security Profiles . . . . . . . . . . . . . . . . 19
5.5.4. GRASP/TLS negotiation . . . . . . . . . . . . . . . . 16 5.7. GRASP instance details . . . . . . . . . . . . . . . . . 19
5.5.5. ACP Security Profiles . . . . . . . . . . . . . . . . 17 5.8. Context Separation . . . . . . . . . . . . . . . . . . . 19
5.6. GRASP instance details . . . . . . . . . . . . . . . . . 17 5.9. Addressing inside the ACP . . . . . . . . . . . . . . . . 20
5.7. Context Separation . . . . . . . . . . . . . . . . . . . 18 5.9.1. Fundamental Concepts of Autonomic Addressing . . . . 20
5.8. Addressing inside the ACP . . . . . . . . . . . . . . . . 18 5.9.2. The ACP Addressing Base Scheme . . . . . . . . . . . 21
5.8.1. Fundamental Concepts of Autonomic Addressing . . . . 18 5.9.3. ACP Addressing Sub-Scheme . . . . . . . . . . . . . . 22
5.8.2. The ACP Addressing Base Scheme . . . . . . . . . . . 19 5.9.4. Usage of the Zone Field . . . . . . . . . . . . . . . 23
5.8.3. ACP Addressing Sub-Scheme . . . . . . . . . . . . . . 20 5.9.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 24
5.8.4. Usage of the Zone Field . . . . . . . . . . . . . . . 21 5.10. Routing in the ACP . . . . . . . . . . . . . . . . . . . 24
5.8.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 22 5.10.1. RPL Profile for the ACP . . . . . . . . . . . . . . 25
5.9. Routing in the ACP . . . . . . . . . . . . . . . . . . . 22 5.11. General ACP Considerations . . . . . . . . . . . . . . . 25
5.9.1. RPL Profile for the ACP . . . . . . . . . . . . . . . 23 6. Workarounds for Non-Autonomic Nodes . . . . . . . . . . . . . 26
5.10. General ACP Considerations . . . . . . . . . . . . . . . 24 6.1. Non-Autonomic Controller / NMS system (ACP connect) . . . 26
6. Workarounds for Non-Autonomic Nodes . . . . . . . . . . . . . 24 6.2. ACP through Non-Autonomic L3 Clouds . . . . . . . . . . . 28
6.1. Connecting a Non-Autonomic Controller / NMS system . . . 24 7. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 28
6.2. ACP through Non-Autonomic L3 Clouds . . . . . . . . . . . 25 8. Self-Protection Properties . . . . . . . . . . . . . . . . . 29
7. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 25 9. The Administrator View . . . . . . . . . . . . . . . . . . . 30
8. Self-Protection Properties . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. The Administrator View . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 31
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 13.1. Initial version . . . . . . . . . . . . . . . . . . . . 31
13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 29 13.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 31
13.1. Initial version . . . . . . . . . . . . . . . . . . . . 29 13.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 32
13.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 29 13.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 32
13.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 29 13.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 32
13.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 30 13.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 32
13.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 30 13.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 33
13.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 30 13.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 33
13.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 30 13.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 34
13.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 31 13.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 34
13.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 31 13.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 34
13.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 32 13.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 35
13.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 32 13.13. draft-ietf-anima-autonomic-control-plane-07 . . . . . . 35
13.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 33 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Background on the choice of routing protocol . . . . 39
Appendix A. Background on the choice of routing protocol . . . . 36 Appendix B. Extending ACP channel negotiation (via GRASP) . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
Autonomic Networking is a concept of self-management: Autonomic Autonomic Networking is a concept of self-management: Autonomic
functions self-configure, and negotiate parameters and settings functions self-configure, and negotiate parameters and settings
across the network. [RFC7575] defines the fundamental ideas and across the network. [RFC7575] defines the fundamental ideas and
design goals of Autonomic Networking. A gap analysis of Autonomic design goals of Autonomic Networking. A gap analysis of Autonomic
Networking is given in [RFC7576]. The reference architecture for Networking is given in [RFC7576]. The reference architecture for
Autonomic Networking in the IETF is currently being defined in the Autonomic Networking in the IETF is currently being defined in the
document [I-D.ietf-anima-reference-model] document [I-D.ietf-anima-reference-model]
skipping to change at page 4, line 19 skipping to change at page 4, line 19
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 5). It therefore remains operational even in the presence of Section 5). 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] can run securely inside the ACP. [I-D.ietf-anima-grasp] can run securely inside the ACP and depends
on the ACP as its "security 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]
This document describes some use cases for the ACP in Section 2, it This document describes some use cases for the ACP in Section 2, it
defines the requirements in Section 3, Section 4 gives an overview defines the requirements in Section 3, Section 4 gives an overview
how an Autonomic Control Plane is constructed, and in Section 5 the how an Autonomic Control Plane is constructed, and in Section 5 the
detailed process is explained. Section 6 explains how non-autonomic detailed process is explained. Section 6 explains how non-autonomic
nodes and networks can be integrated, and Section 5.5 the first nodes and networks can be integrated, and Section 5.6 the first
channel types for the ACP. channel types for the ACP.
The document "Autonomic Network Stable Connectivity" The document "Autonomic Network Stable Connectivity"
[I-D.ietf-anima-stable-connectivity] describes how the ACP can be [I-D.ietf-anima-stable-connectivity] describes how the ACP can be
used to provide stable connectivity for OAM applications. It also used to provide stable connectivity for OAM applications. It also
explains on how existing management solutions can leverage the ACP in explains on how existing management solutions can leverage the ACP in
parallel with traditional management models, when to use the ACP parallel with traditional management models, when to use the ACP
versus the data plane, how to integrate IPv4 based management, etc. versus the data plane, how to integrate IPv4 based management, etc.
2. Use Cases for an Autonomic Control Plane 2. Use Cases for an Autonomic Control Plane
skipping to change at page 8, line 42 skipping to change at page 8, line 42
Plane, and highlights the key properties which make it Plane, and highlights the key properties which make it
"indestructible" against many inadvert changes to the data plane, for "indestructible" against many inadvert changes to the data plane, for
example caused by misconfigurations. example caused by misconfigurations.
5.1. Preconditions 5.1. Preconditions
An autonomic node can be a router, switch, controller, NMS host, or An autonomic node can be a router, switch, controller, NMS host, or
any other IP device. We assume an autonomic node has a globally any other IP device. We assume an autonomic node has a globally
unique domain certificate (LDevID), as well as an adjacency table. unique domain certificate (LDevID), as well as an adjacency table.
5.1.1. Domain Certificate with ANIMA information 5.1.1. Domain Certificate with ACP information
To establish an ACP securely, an Autnomic Node MUST have a globally To establish an ACP securely, an Autnomic Node MUST have a globally
unique domain certificate (LDevID), with which it can unique domain certificate (LDevID), with which it can
cryptographically assert its membership of the domain. The document cryptographically assert its membership in the domain. The document
[I-D.ietf-anima-bootstrapping-keyinfra] describes how a domain [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) describes how a
certificate can be automatically and securely derived from a vendor domain certificate can automatically and securely be derived from a
specific Unique Device Identifier (UDI) or IDevID certificate. vendor specific Unique Device Identifier (UDI) or IDevID certificate.
The domain certificate (LDevID) of an autonomic node MUST contain The domain certificate (LDevID) of an autonomic node MUST contain
ANIMA specific information, specifically the domain name, and its ACP ANIMA specific information, specifically the domain name, the address
address with the zone-ID set to zero. This information MUST be of the device in the ACP with the Zone-ID set to zero ("ACP
encoded in the LDevID in the subjectAltName / rfc822Name field in the address"). This information MUST be encoded in the LDevID in the
following way: subjectAltName / rfc822Name field in the following way:
anima.acp+<ACP address>@<domain> anima.acp+<ACP address>{+<extensions>}@<domain>
Example: Example:
anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.com anima.acp+FDA3:79A6:F6EE:0:200:0:6400:1@example.com
The ACP address MUST be specified in its canonical form, as specified The ACP address MUST be specified in its canonical form, as specified
in [RFC5952], to allow for easy textual comparisons. in [RFC5952], to allow for easy textual comparisons.
The particular subjectAlName / rfc822Name encoding is choosen for The optional <extensions> field is used for future extensions to this
several reasons: specification. It MUST be ignored unless otherwise specified.
o We want to permit the reuse of the ANIMA LDevID in other uses The subjectAlName / rfc822Name encoding of the ACP domain name and
beside the ACP as appropriate, eg: there are a wide number of pre- ACP address is used for the following reasons:
existing data-plane security mechanisms where re-using the ACP
certificate could help to further automate security.
o We therefore want to make sure that ACP elements in the LDevID o The LDevID assigned by BRSKI should be reuseable for other
will not cause incompatibilities with any pre-existing ASN.1 code purposed beside authentication for ACP.
o There are a wide range of pre-existing protocols/services where
authentication with LDevID is desirable. Enrolling and
maintaining separate LDevIDs for each of these protocols/services
is often undesirable overhead. Therefore it is beneficial if the
BRSKI enrolled LDevID can also be used for other protocols/
services beside the ACP.
o The elements in the LDevID required for the ACP should therefore
not cause incompatibilities with any pre-existing ASN.1 code
potentially in use in those other pre-existing SW systems. potentially in use in those other pre-existing SW systems.
o subjectAltname / rfc822Name is a pre-existing element that must be o subjectAltname / rfc822Name is a pre-existing element that must be
supported by all existing ASN.1 parsers for LDevID. supported by all existing ASN.1 parsers for LDevID.
o We also want to make sure that the ACP information will not be o The elements in the LDevID required for the ACP should also not be
misinterpreted by any such pre-existing code interpreting the misinterpreted by any pre-existing protocol/service that might use
LDevID, or if it is misinterpreted, that the impact is benign. the LDevID. If the elements used for the ACP are interpreted by
other protocols/services, then the impact should be benign.
o Using an IP address format encoding could result in non-benign o Using an IP address format encoding could result in non-benign
misinterpretation of the ACP information. misinterpretation of the ACP information, for example other
protocol/services unaware of the ACP could try to do something
with the ACP address that would fail to work correctly (because it
is in a different VRF than what they expect), or that could cause
security issues.
o At minimum, we need to encode both the AN domain name and the non- o At minimum, both the AN domain name and the non-domain name
domain name derived part of the ACP, so there are not many derived part of the ACP address need to be encoded in one or more
alternatives with pre-existing fields where those two elements appropriate fields of the certificate, so there are not many
could be encoded. alternatives with pre-existing fields where the only possible
conflicts would likely be beneficial.
o rfc822Name encoding allows to be quite flexible. We choose to o rfc822Name encoding is quite flexible. We choose to encode the
encode the full ACP address AND the domain name, so that it is full ACP address AND the domain name, so that it is easier to
easier to examine/use. examine/use the encoded "ACP information".
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 components behind a plus symbol
are considered part of a single mailbox. are considered part of a single mailbox. In other words, it is
not necessary to set up a separate mailbox for every autonomic
devices ACP information, 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.
The bootstrap process defined in In the BRSKI bootstrap process in an ANIMA network, the registrar
[I-D.ietf-anima-bootstrapping-keyinfra] MUST in an ANIMA network pass (acting as an EST server) MUST include the subjectAltName /
on ACP address and domain to a new node, such that the new node can rfc822Name encoded ACP address and domain name to the enrolling
add this to its enrolment request. device (called pledge) via its response to the pledges EST CSR
Attribute request that is mandatory in BRSKI.
The Certificate Authority in an ANIMA network MUST honor these The Certificate Authority in an ANIMA network MUST not change this,
parameters, and create the respective subjectAltName / rfc822Name in and create the respective subjectAltName / rfc822Name in the
the certificate. certificate.
ANIMA nodes can therefore find ACP address and domain using this ANIMA nodes can therefore find ACP address and domain using this
field in the domain certificate, both for themselves, as well as for field in the domain certificate, both for themselves, as well as for
other nodes. other nodes.
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.
5.1.2. AN Adjacency Table 5.1.2. AN Adjacency Table
skipping to change at page 12, line 29 skipping to change at page 12, line 43
capable L2 switch, then this would be necessary to implement. It is capable L2 switch, then this would be necessary to implement. It is
likely that termination of mDNS messages could only be applied to all likely that termination of mDNS messages could only be applied to all
mDNS messages from a port, which would then make it necessary to mDNS messages from a port, which would then make it necessary to
software forward any non-ACP related mDNS messages to maintain prior software forward any non-ACP related mDNS messages to maintain prior
non-ACP mDNS functionality. With low performance of software non-ACP mDNS functionality. With low performance of software
forwarding in many L2 switches, this could easily make the ACP forwarding in many L2 switches, this could easily make the ACP
unsupportable on such L2 switches. unsupportable on such L2 switches.
5.2.3. Discovery with GRASP 5.2.3. Discovery with GRASP
In conclusion for the above described considerations, the ACP uses Because of the above considerations, the ACP uses DULL (Discovery
"insecure" instances of GRASP for discovery of ACP neighbors because Unsolicited Link-Local) insecure instances of GRASP for discovery of
it can easily be set up to match the requiremetns without affecting ACP neighbors. See section 3.5.2.2 of [I-D.ietf-anima-grasp] These
other uses of the protocol. can easily be set up to match the aforementioned requirements without
affecting other uses of GRASP. Note that each such DULL instance of
GRASP is also used for the discovery of a bootstrap proxy when the
device is not yet enrolled into the autonomic domain. Because the
discover of ACP neighbors only happens after the device is enrolled
into the autonomic domain, it never needs to discover a bootstrap
proxy and ACP neighbor at the same time.
The name of the GRASP objective to announce/discover the capability An autonomic node announces itself to potential ACP peers by use of
of a neighbor to run the ACP is "ACP". Section 3.5.2.2 of the "AN_ACP" objective. This is a synchronization objective intended
[I-D.ietf-anima-grasp] describes the instance of GRASP to be used for to be flooded on a single link using the GRASP Flood Synchronization
this purpose: "DULL" (Discovery Unsolicited Link Local). The precise (M_FLOOD) message. In accordance with the design of the Flood
GRASP objective to be used is specified in Section 3 of message, a locator consisting of a specific link-local IP address, IP
[I-D.carpenter-anima-ani-objectives]. protocol number and port number will be distributed with the flooded
objective. An example of the message is informally:
As explained above, in an ACP enabled L2 switch, each of these [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 1,
["AN_ACP", SYNCH-FLAG, 1, "IKEv2"],
[O_IPv6_LOCATOR,
h'fe80000000000000c0011001FEEF0000, UDP, 15000]
]
The formal CDDL definition is:
flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]]
objective = ["AN_ACP", objective-flags, loop-count,
objective-value]
objective-flags = ; as in the GRASP specification
loop-count = 1 ; limit to link-local operation
objective-value = text ; name of the (list of) secure
; channel negotiation protocol(s)
The objective-flags field is set to indicate synchronization.
The ttl and loop-count are fixed at 1 since this is a link-local
operation.
The session-id is a random number used for loop prevention
(distinguishing a message from a prior instance of the same message).
In DULL this field is irrelevant but must still be set according to
the GRASP specification.
The originator MUST be the IPv6 link local address of the originating
autonomic node on the sending interface.
The 'objective-value' parameter is (normally) a string indicating the
secure channel protocol available at the specified or implied
locator.
The locator is optional and only required when the secure channel
protocol is not offered at a well-defined port number, or if there is
no well defined port number. For example, "IKEv2" has a well defined
port number 500, but in the above example, the candidate ACP neighbor
is offering ACP secure channel negotiation via IKEv2 on port 15000
(for the sake of creating the example).
If a locator is included, it MUST be an O_IPv6_LOCATOR, and the IPv6
address MUST be the same as the initiator address (these are DULL
requirements to minimize third party DoS attacks).
The secure channel methods defined in this document use the objective
values of "IKEv2" and "dTLS". There is no disstinction between IKEv2
native and GRE-IKEv2 because this is purely negotiated via IKEv2.
A node that supports more than one secure channel protocol needs to
flood multiple versions of the "AN_ACP" objective, each accompanied
by its own locator. This can be in a single GRASP M_FLOOD packet.
If multiple secure channel protocols are supported that all are run
on well-defined ports, then they can be announced via a single AN_ACP
objective using a list of string names as the objective value without
a following locator-option.
Note that a node serving both as an ACP node and BRSKI Join Proxy may
choose to distribute the "AN_ACP" objective and "AN_join_proxy"
objective in the same flood message, since GRASP allows multiple
objectives in one Flood message. This may be impractical though if
ACP and BRSKI operations are implemented via separate software
modules / ASAs though.
As explained above, in an ACP enabled L2 switch, each of these GRASP
instances would actually need to be per-L2-port. The result of the instances would actually need to be per-L2-port. The result of the
discovery is the IPv6 link-local address of the neighbor. It is discovery is the IPv6 link-local address of the neighbor as well as
stored in the AN Adjacency Table, see Section 5.1.2 which then drives its supported secure channel protocols (and non-standard port they
the further building of the ACP to that neighbor. are running on). It is stored in the AN Adjacency Table, see
Section 5.1.2 which then drives the further building of the ACP to
that neighbor.
For example, ANswitch1 would run separate DULL GRASP instances on its For example, ANswitch1 would run separate DULL GRASP instances on its
ports to ANrtr1, ANswitch2 and ANswitchI, even though all those three ports to ANrtr1, ANswitch2 and ANswitchI, even though all those three
ports may be in the data plane in the same (V)LAN. This is easily ports may be in the data plane in the same (V)LAN. This is easily
achieved by extracting native GRASP multicast messages by their MAC achieved by extracting native GRASP multicast messages by their MAC
multicast destination address. None of the other type of GRASP multicast destination address. None of the other type of GRASP
instances (eg: as used inside the ACP) use GRASP messages that would instances (eg: as used inside the ACP) use GRASP messages that would
be affected by such extraction, because all other GRASP messages have be affected by such extraction, because all other GRASP messages have
encrypted encapsulations. encrypted encapsulations.
5.2.4. Discovery and BRSKY
Before a node has a domain certificate, it can not participate in the
ACP and therefore does also not try to discover an ACP neighbor.
Instead, it uses the discovery mechanism described in
[I-D.ietf-anima-grasp] to discover a bootstrap proxy. Currently,
that document describes mDNS as the protocol of choice for that
discovery. In the context of above topology example, ANrtr1 might
therefore discover and choose any ANrtr or ANswitch on the LAN that
is already part of the autonomic domain - instead of the closest one
which is ANswitch1. This choice of bootstrap proxy does not impact
in the later building of the ACP on ANrtr1 and is therefore not a
concern for the ACP.
Once a device has its domain certificate, it will start announcing
itself via GRASP as ACP capable.
When an autonomic device is a registrar, it will announce the
registrar function via GRASP in the ACP as the "6JOIN" objective. An
AN device that is a registrar or learns about one or more reachable
registrars via this GRASP/ACP announcements will announce itself as a
boostrap proxy via mDNS. See [I-D.richardson-anima-6join-discovery]
for more details.
5.3. Candidate ACP Neighbor Selection 5.3. Candidate ACP Neighbor Selection
An autonomic node must determine to which other autonomic nodes in An autonomic node must determine to which other autonomic nodes in
the adjacency table it should build an ACP connection. This is based the adjacency table it should build an ACP connection. This is based
on the information in the AN Adjacency table. on the information in the AN Adjacency table.
The ACP is by default established exclusively between nodes in the The ACP is by default established exclusively between nodes in the
same domain. same domain.
Intent can change this default behaviour. Since Intent is Intent can change this default behaviour. Since Intent is
skipping to change at page 14, line 28 skipping to change at page 15, line 48
To avoid attacks, initial discovery of candidate ACP peers can not To avoid attacks, initial discovery of candidate ACP peers can not
include any non-protected negotiation. To avoid re-inventing and include any non-protected negotiation. To avoid re-inventing and
validating security association mechanisms, the next step after validating security association mechanisms, the next step after
discoving the address of a candidate neighbor can only be to try discoving the address of a candidate neighbor can only be to try
first to establish a security association with that neighbor using a first to establish a security association with that neighbor using a
well-known security association method. well-known security association method.
At this time in the lifecycle of autonomic devices, it is unclear At this time in the lifecycle of autonomic devices, it is unclear
whether it is feasible to even decide on a single MTI (mandatory to whether it is feasible to even decide on a single MTI (mandatory to
implement) security association protocol across all autonomic implement) security association protocol across all autonomic
devices. devices:
From the use-cases it is clear that not all type of autonomic devices From the use-cases it seems clear that not all type of autonomic
can or need to connect directly to each other or are able to support devices can or need to connect directly to each other or are able to
or prefer all possible mechanisms. For example, code space limited support or prefer all possible mechanisms. For example, code space
IoT devices may only support dTLS (because that code exists already limited IoT devices may only support dTLS (because that code exists
on them for end-to-end security use-cases), but low-end in-ceiling L2 already on them for end-to-end security use-cases), but low-end in-
switches may only want to support MacSec because that is also ceiling L2 switches may only want to support MacSec because that is
supported in HW, and only a more flexible garteway device may need to also supported in HW, and only a more flexible gateway device may
support both of these mechanisms and potentially more. need to support both of these mechanisms and potentially more.
To support these requirements, and make ACP channel negotiation also To support extensible secure channel protocol selection without a
easily extensible, the secure channel selection between Alice and Bob single common MTI protocol, autonomic devices must try all the ACP
is a potentially two stage process. In the first stage, Alice and secure channel protocols it supports and that are feasible because
Bob directly try to establish a secure channel using the security- the candidate ACP neighbor also announced them via its AN_ACP GRASP
association and channel protocols they support. One or more of these parameters (these are called the "feasible" ACP secure channel
protocols may simply be protocols not directly resulting in an ACP protocols).
channel, but instead establishing a secure negotiation channel
through which the final secure channel protocol is decided. If both
Alice and Bob support such a negotiation step, then this secured
negotiation channel is the first step, and the secure channel
protocol is the second step.
If Alice supports multiple security association protocols in the To ensure that the selection of the secure channel protocols always
first step, it is a matter of Alices local policy to determine the succeeds in a predictable fashion without blocking, the following
order in which she will try to build the connection to Bob. To rules apply:
support multiple security association protocols, Alice must be able
to simultaneously act as a responder in parallel for all of them - so
that she can respond to any order in which Bob wants to prefer
building the security association.
When ACP setup between Alice and Bob results in the first secure An autonomic device may choose to attempt initiate the different
association to be established, the peer with the higher Device-ID in feasible ACP secure channel protocol it supports according to its
the certificate will stop building new security associations. The local policies sequentially or in parallel, but it MUST support
peer with the lower certificate Device-ID is now responsible to acting as a responder to all of them in parallel.
continue building its most preferred security association and to tear
down all but that most preferred one - unless the secure association Once the first secure channel protocol succeeds, the two peers know
is one of a negotation protocols whose rules superceed this. each others certificates (because that must be used by all secure
channel protocols for mutual authentication. The device with the
lower Device-ID in the ACP address becomes Bob, the one with the
higher Device-ID in the certificate Alice.
Bob becomes passive, he does not attempt to further initiate ACP
secure channel protocols with Alice and does not consider it to be an
error when Alice closes secure channels. Alice becomes the active
party, continues to attempt setting up secure channel protocols with
Bob until she arrives at the best one (from her view) that also works
with Bob.
For example, originally Bob could have been the initiator of one ACP
secure channel protocol that Bob preferred and the security
association succeeded. The roles of Bob abd Alice are then assigned.
At this stage, the protocol may not even have completed negotiationg
a common security profile. The protocol could for example have been
IPsec. It is not up to Alice to devide how to proceed. Even if the
IPsec connecting determined a working profile with Bob, Alice might
prefer some other secure protocol (eg: dTLS) and try to set that up
with Bob. If that succeeds, she would close the IPsec connection. If
no better protocol attempt succeeds, she would keep the IPsec
connection.
All this negotiation is in the context of an "L2 interface". Alice All this negotiation is in the context of an "L2 interface". Alice
and Bob will build ACP connections to each other on every "L2 and Bob will build ACP connections to each other on every "L2
interface" that they both connect to. interface" that they both connect to. An autonomic device must not
assume that neighbors with the same L2 or link-local IPv6 addresses
on different L2 interfaces are the ame devices. This can only be
determined after examining the certificate after a successful
security association attempt.
5.5. Security Association protocols 5.5. Candidate ACP Neighbor certificate verification
The following sections define the security association protocols that Independent of the security association protocol choosen, candidate
we consider to be important and feasible to specify in this document. ACP neighbors need to be authenticated based on their autonomic
In all cases, the mutual authentication is done via the autonomic domain certificate. This implies that any security association
domain certificate of the peer as follows - unless superceeded by protocol MUST support certificate based authentication that can
Intent: support the following verification steps:
o The certificate is valid as proven by the security associations o The certificate is valid as proven by the security associations
protocol exchanges. protocol exchanges.
o If the certificate is included in a Certificate Revocation List
(CRL), the connection attempt is aborted and an error logged.
[EDNOTE: Do we want OCSP instead of CRL?] [EDNOTE: Distribution
of the CRL, and handling of CRL timeouts during network partition
needs to be discussed in more detail.]
o The peers certificate is signed by the same CA as the devices o The peers certificate is signed by the same CA as the devices
domain certificate. domain certificate.
o The peers OU (Organizational Unit) field in the certificates o The peers certificate has a valid ACP information field
Subject is the same as in the devices certificate. (subjectAltName / rfc822Name) and the domain name in that peers
ACP information field is the same as in the devices certificate.
5.5.1. ACP via IPsec o The peers certificate is valid according to the CRL or OCSP method
indicated in the devices certificate. If the peers certificate
fails any of these checks, the connection attempt is aborted and
an error logged (with throttling).
This document does not mandate specific support for CRL or OCSP
options. If CRL or OCSP URLs are specified in the devices
certificate then the device SHOULD connect to the URL via the ACP if
it has an IPv6 address that is reachable via the ACP. Better
mechanisms to locate CRL or OCSP server(s), for example via GRASP are
subject to future documents.
5.6. Security Association protocols
The following sections define the security association protocols that
we consider to be important and feasible to specify in this document:
5.6.1. ACP via IKEv2
An autonomic device announces its ability to support IKEv2 as the ACP
secure channel protcol in GRASP as "IKEv2".
5.6.1.1. Native IPsec
To run ACP via IPsec transport mode, no further IANA assignments/ To run ACP via IPsec transport mode, no further IANA assignments/
definitions are required. All autonomic devices suppoting IPsec MUST definitions are required. All autonomic devices supporting IPsec
support IPsec security setup via IKEv2, transport mode encapsulation MUST support IPsec security setup via IKEv2, transport mode
via the device and peer link-local IPv6 addresses and AES256 encapsulation via the device and peer link-local IPv6 addresses,
encryption. AES256 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 transport mode with next protocol equal 41 (IPv6).
5.5.2. ACP via GRE/IPsec 5.6.1.2. IPsec with GRE encapsulation
In network devices it is often easier to provide virtual interfaces In network devices it is often easier to provide virtual interfaces
on top of GRE encapsulation than natively on top of a simple IPsec on top of GRE encapsulation than natively on top of a simple IPsec
association. On those devices it may be necessary to run the ACP association. On those devices it may be necessary to run the ACP
secure channel on top of a GRE connection protected by the IPsec secure channel on top of a GRE connection protected by the IPsec
association. The requirements for the IPsec association are the same association. The requirements for the IPsec association are the same
as described above, but instead of directly carrying the ACP IPv6 as in the native IPsec case, but instead of directly carrying the ACP
packets, the payload is an ACP IPv6 packet inside GRE/IPv6. IPv6 packets, the payload is an ACP IPv6 packet inside GRE/IPv6. The
mandatory security profile is the same as for native IPsec: peer
link-local IPv6 addresses, AES256 encryption, SHA256 hash.
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 41 (IPv6) (because native IPsec is required to be
supported, see below). supported, see below).
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].
5.5.3. ACP via dTLS 5.6.2. ACP via dTLS
We define the use of ACP via dTLS in the assumption that it is likely We define the use of ACP via dTLS in the assumption that it is likely
the first transport encryption code basis supported in some classes the first transport encryption code basis supported in some classes
of constrained devices. of constrained devices.
To run ACP via UDP and dTLS v1.2 [RFC6347] an IANA assigned port To run ACP via UDP and dTLS v1.2 [RFC6347] a locally assigned UDP
[TBD] is used. All autonomic devices supporting ACP via dTLS must port is used that is announced as a parameter in the GRASP AN_ACP
use AES256 encryption. objective to candidate neighbors. All autonomic devices supporting
ACP via dTLS must use AES256 encryption.
There is no additional session setup or other security association There is no additional session setup or other security association
other than dTLS. As soon as the dTLS session is functional, the ACP besides this simple dTLS setup. As soon as the dTLS session is
peers will exchange ACP IPv6 packets as the payload of the dTLS functional, the ACP peers will exchange ACP IPv6 packets as the
transport connecetion. Any dTLS defined security association payload of the dTLS transport connection. Any dTLS defined security
mechanisms such as re-keying are used as they would be for any association mechanisms such as re-keying are used as they would be
transport application relying solely on dTLS. for any transport application relying solely on dTLS.
5.5.4. GRASP/TLS negotiation
To explicitly allow negotiation of the ACP channel protocol, GRASP
over a TLS connection using the GRASP_LISTEN_PORT and the devices and
peers link-local IPv6 address is used. When Alice and Bob support
GRASP negotiation, they do prefer it over any other non-explicitly
negotiated security association protocol and should wait trying any
non-negotiated ACP channel protocol until after it is clear that
GRASP/TLS will not work to the peer.
When Alice and Bob successfully establish the GRASP/TSL session, they
will initially negotiate the channel mechanism to use. Bob and Alice
each have a list of channel mehanisms they support, sorted by
preference. They negotiate the best mechansm supported by both of
them. In the absence of Intent, the mechanism choosen is the best
one for the device with the lower Device-ID.
After agreeing on a channel mechanism, Alice and Bob start the
selected Channel protocol. The GRASP/TLS connection can be kept
alive or timed out as long as the seelected channel protocol has a
secure association between Alice and Bob. When it terminates, it
needs to be re-negotiated via GRASP/TLS.
Negotiation of a channel type may require IANA assignments of code
points. See IANA Considerations (Section 11) for the formal
definition of those code points.
The exact negotiation steps in GRASP to achieve this outcome.
5.5.5. ACP Security Profiles 5.6.3. ACP Security Profiles
A baseline autonomic device MUST support IPsec and SHOULD support A baseline autonomic device MUST support IPsec. A constrained
GRASP/TLS and dTLS. A constrained autonomic device MUST support autonomic device MUST support dTLS. Autonomic edge device connecting
dTLS. constrained areas with baseline areas MUST therefore support IPsec
and dTLS.
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 security encapsulation overhead. Given underlying link MTU minus the security encapsulation overhead. Given
how ACP channels are built across layer2 connections only, the how ACP channels are built across layer2 connections only, the
probability for MTU mismatch is low. For additional reliability, probability for MTU mismatch is low. For additional reliability,
applications to be runa cross the ACP should only assume to have applications to be runa cross the ACP should only assume to have
minimum MTU available (1280). minimum MTU available (1280).
Autonomic devices need to specify in documentation the set of secure Autonomic devices need to specify in documentation the set of secure
ACP mechanisms they suppport. ACP mechanisms they suppport.
5.6. GRASP instance details 5.7. GRASP instance details
Received GRASP packets are assigned to an instance of GRASP by the Received GRASP packets are assigned to an instance of GRASP by the
context they are received on: context they are received on:
o GRASP packets received on an ACP (virtual) interfaces are assigned o GRASP packets received on an ACP (virtual) interfaces are assigned
to the ACP instance of GRASP to the ACP instance of GRASP
o GRASP/UDP packets received on L2 interfaces/ports where the device o GRASP/UDP packets received on L2 interfaces/ports where the device
is willing to run ACP are assigned to a DULL instance of GRASP for is willing to run ACP are assigned to a DULL instance of GRASP for
that interface/port. that interface/port.
o GRASP packets received inside a TLS connection established for 5.8. Context Separation
GRASP/TLS ACP negotiation are assigned to a separate instance of
GRASP for that negotiation.
5.7. 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,
separation options that minimize shared components are preferred, separation options that minimize shared components are preferred,
such as a logical container or virtual machine instance. The context such as a logical container or virtual machine instance. The context
for the ACP needs to be established automatically during bootstrap of for the ACP needs to be established automatically during bootstrap of
a device. As much as possible it should be protected from being a device. As much as possible it should be protected from being
modified unintentionally by data plane configuration. modified unintentionally by data plane configuration.
Context separation improves security, because the ACP is not Context separation improves security, because the ACP is not
reachable from the global routing table. Also, configuration errors reachable from the global routing table. Also, configuration errors
from the data plane setup do not affect the ACP. from the data plane setup do not affect the ACP.
5.8. Addressing inside the ACP 5.9. Addressing inside the ACP
The channels explained above typically only establish communication The channels explained above typically only establish communication
between two adjacent nodes. In order for communication to happen between two adjacent nodes. In order for communication to happen
across multiple hops, the autonomic control plane requires internal across multiple hops, the autonomic control plane requires internal
network wide valid addresses and routing. Each autonomic node must network wide valid addresses and routing. Each autonomic node must
create a virtual interface with a network wide unique address inside create a virtual interface with a network wide unique address inside
the ACP context mentioned in Section 5.7. This address may be used the ACP context mentioned in Section 5.8. This address may be used
also in other virtual contexts. also in other virtual contexts.
With the algorithm introduced here, all autonomic devices in the same With the algorithm introduced here, all autonomic devices in the same
domain have the same /48 prefix. Conversely, global IDs from domain have the same /48 prefix. Conversely, global IDs from
different domains are unlikely to clash, such that two networks can different domains are unlikely to clash, such that two networks can
be merged, as long as the policy allows that merge. See also be merged, as long as the policy allows that merge. See also
Section 7 for a discussion on merging domains. Section 7 for a discussion on merging domains.
Links inside the ACP only use link-local IPv6 addressing, such that Links inside the ACP only use link-local IPv6 addressing, such that
each node only requires one routable virtual address. each node only requires one routable virtual address.
5.8.1. Fundamental Concepts of Autonomic Addressing 5.9.1. Fundamental Concepts of Autonomic Addressing
o Usage: Autonomic addresses are exclusively used for self- o Usage: Autonomic addresses are exclusively used for self-
management functions inside a trusted domain. They are not used management functions inside a trusted domain. They are not used
for user traffic. Communications with entities outside the for user traffic. Communications with entities outside the
trusted domain use another address space, for example normally trusted domain use another address space, for example normally
managed routable address space. managed routable address space.
o Separation: Autonomic address space is used separately from user o Separation: Autonomic address space is used separately from user
address space and other address realms. This supports the address space and other address realms. This supports the
robustness requirement. robustness requirement.
skipping to change at page 19, line 46 skipping to change at page 21, line 24
o Autonomic functions do not require IPv4: Autonomic functions and o Autonomic functions do not require IPv4: Autonomic functions and
autonomic service agents are new concepts. They can be autonomic service agents are new concepts. They can be
exclusively built on IPv6 from day one. There is no need for exclusively built on IPv6 from day one. There is no need for
backward compatibility. backward compatibility.
o OAM protocols no not require IPv4: The ACP may carry OAM o OAM protocols no not require IPv4: The ACP may carry OAM
protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius, protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, Radius,
Diameter, ...) are available in IPv6. Diameter, ...) are available in IPv6.
5.8.2. The ACP Addressing Base Scheme 5.9.2. The ACP Addressing Base Scheme
The Base ULA addressing scheme for autonomic nodes has the following The Base ULA addressing scheme for autonomic nodes has the following
format: format:
8 40 3 77 8 40 3 77
+--+--------------+------+------------------------------------------+ +--+--------------+------+------------------------------------------+
|FD| hash(domain) | Type | (sub-scheme) | |FD| hash(domain) | Type | (sub-scheme) |
+--+--------------+------+------------------------------------------+ +--+--------------+------+------------------------------------------+
Figure 3: ACP Addressing Base Scheme Figure 3: ACP Addressing Base Scheme
skipping to change at page 20, line 22 skipping to change at page 21, line 46
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 domain name, o The ULA "global ID" is set here to be a hash of the domain name,
which results in a pseudo-random 40 bit value. It is calculated which results in a pseudo-random 40 bit value. It is calculated
as the first 40 bits of the SHA256 hash of the domain name, in the as the first 40 bits of the SHA256 hash of the domain name, in the
example "example.com". example "example.com".
o To allow for extensibility, the fact that the ULA "global ID" is
such a hash MUST NOT be assumed by any autonomic device during
normal operations but only by registrars during the creation of a
response to the CSR Attribute request, eg: when the certificate is
created in which the address is inserted via the ACP information
attribute.
o Type: This field allows different address sub-schemes in the o Type: This field allows different address sub-schemes in the
future. The goal is to start with a single sub-schemes, but to future. The goal is to start with a single sub-schemes, but to
allow for extensions later if and when required. This addresses allow for extensions later if and when required. This addresses
the "upgradability" requirement. Assignment of types for this the "upgradability" requirement. Assignment of types for this
field should be maintained by IANA. field should be maintained by IANA.
5.8.3. ACP Addressing Sub-Scheme 5.9.3. ACP Addressing Sub-Scheme
The sub-scheme defined here is defined by the Type value 0 (zero) in The sub-scheme defined here is defined by the Type value 0 (zero) in
the base scheme. the base scheme.
51 13 63 1 51 13 63 1
+------------------------+---------+----------------------------+---+ +------------------------+---------+----------------------------+---+
| (base scheme) | Zone ID | Device ID | V | | (base scheme) | Zone-ID | Device-ID | V |
+------------------------+---------+----------------------------+---+ +------------------------+---------+----------------------------+---+
Figure 4: ACP Addressing Sub-Scheme Figure 4: ACP Addressing Sub-Scheme
The fields are defined as follows: [Editor's note: The lengths of the The fields are defined as follows: [Editor's note: The lengths of the
fields is for discussion.] fields is for discussion.]
o Zone ID: If set to all zero bits: The device ID bits are used as o Zone-ID: If set to all zero bits: The Device-ID bits are used as
an identifier (as opposed to a locator). This results in a non- an identifier (as opposed to a locator). This results in a non-
hierarchical, flat addressing scheme. Any other value indicates a hierarchical, flat addressing scheme. Any other value indicates a
zone. See section Section 5.8.4 on how this field is used in zone. See section Section 5.9.4 on how this field is used in
detail. detail.
o Device ID: A unique value for each device. o Device-ID: A unique value for each device.
o V: Virtualization bit: 0: autonomic node base system; 1: a virtual o V: Virtualization bit: 0: autonomic node base system; 1: a virtual
context on an autonomic node. context on an autonomic node.
The device ID is derived as follows: In an Autonomic Network, a The Device-ID is derived as follows: In an Autonomic Network, a
registrar is enrolling new devices. As part of the enrolment process registrar is enrolling new devices. As part of the enrolment process
the registrar assigns a number to the device, which is unique for the registrar assigns a number to the device, which is unique for
this registrar, but not necessarily unique in the domain. The 64 bit this registrar, but not necessarily unique in the domain. The 64 bit
device ID is then composed as: Device-ID is then composed as:
o 48 bit: Registrar ID, a number unique inside the domain that o 48 bit: Registrar ID, a number unique inside the domain that
identifies the registrar which assigned the name to the device. A identifies the registrar which assigned the name to the device. A
MAC address of the registrar can be used for this purpose. MAC address of the registrar can be used for this purpose.
o 15 bit: Device number, a number which is unique for a given o 15 bit: Device number, a number which is unique for a given
registrar, to identify the device. This can be a sequentially registrar, to identify the device. This can be a sequentially
assigned number. assigned number.
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 5.8.4 for a description of the zone bits. Section 5.9.4 for a description of the zone bits.
This addressing sub-scheme allows the direct addressing of specific This addressing sub-scheme allows the direct addressing of specific
virtual containers / VMs on an autonomic node. An increasing number virtual containers / VMs on an autonomic node. An increasing number
of hardware platforms have a distributed architecture, with a base OS of hardware platforms have a distributed architecture, with a base OS
for the node itself, and the support for hardware blades with for the node itself, and the support for hardware blades with
potentially different OSs. The VMs on the blades could be considered potentially different OSs. The VMs on the blades could be considered
as separate autonomic nodes, in which case it would make sense to be as separate autonomic nodes, in which case it would make sense to be
able to address them directly. Autonomic Service Agents (ASAs) could able to address them directly. Autonomic Service Agents (ASAs) could
be instantiated in either the base OS, or one of the VMs on a blade. be instantiated in either the base OS, or one of the VMs on a blade.
This addressing scheme allows for the easy separation of the hardware This addressing scheme allows for the easy separation of the hardware
context. context.
The location of the V bit(s) at the end of the address allows to The location of the V bit(s) at the end of the address allows to
announce a single prefix for each autonomic node, while having announce a single prefix for each autonomic node, while having
separate virtual contexts addressable directly. separate virtual contexts addressable directly.
[EDNOTE: various suggestions from mcr in his mail from 30 Nov 2016 to [EDNOTE: various suggestions from mcr in his mail from 30 Nov 2016 to
be considered (https://mailarchive.ietf.org/arch/msg/anima/ be considered (https://mailarchive.ietf.org/arch/msg/anima/
nZpEphrTqDCBdzsKMpaIn2gsIzI).] nZpEphrTqDCBdzsKMpaIn2gsIzI).]
5.8.4. Usage of the Zone Field 5.9.4. Usage of the Zone Field
The "zone ID" allows for the introduction of structure in the The "Zone-ID" allows for the introduction of structure in the
addressing scheme. addressing scheme.
Zone = zero is the default addressing scheme in an autonomic domain. Zone = zero is the default addressing scheme in an autonomic domain.
Every autonomic node MUST respond to its ACP address with zone=0. Every autonomic node MUST respond to its ACP address with zone=0.
Used on its own this leads to a non-hierarchical address scheme, Used on its own this leads to a non-hierarchical address scheme,
which is suitable for networks up to a certain size. In this case, which is suitable for networks up to a certain size. In this case,
the addresses primarily act as identifiers for the nodes, and the addresses primarily act as identifiers for the nodes, and
aggregation is not possible. aggregation is not possible.
If aggregation is required, the 13 bit value allows for up to 8191 If aggregation is required, the 13 bit value allows for up to 8191
skipping to change at page 22, line 20 skipping to change at page 24, line 5
automatically through a to-be-defined algorithm; or it could be automatically through a to-be-defined algorithm; or it could be
configured and maintained manually. configured and maintained manually.
If a device learns through an autonomic method or through If a device learns through an autonomic method or through
configuration that it is part of a zone, it MUST also respond to its configuration that it is part of a zone, it MUST also respond to its
ACP address with that zone number. In this case the ACP loopback is ACP address with that zone number. In this case the ACP loopback is
configured with two ACP addresses: One for zone 0 and one for the configured with two ACP addresses: One for zone 0 and one for the
assigned zone. This method allows for a smooth transition between a assigned zone. This method allows for a smooth transition between a
flat addressing scheme and an hierarchical one. flat addressing scheme and an hierarchical one.
(Theoretically, the 13 bits for the zone ID would allow also for two (Theoretically, the 13 bits for the Zone-ID would allow also for two
levels of zones, introducing a sub-hierarchy. We do not think this levels of zones, introducing a sub-hierarchy. We do not think this
is required at this point, but a new type could be used in the future is required at this point, but a new type could be used in the future
to support such a scheme.) to support such a scheme.)
Note: Another way to introduce hierarchy is to use sub-domains in the Note: Another way to introduce hierarchy is to use sub-domains in the
naming scheme. The node names "node17.subdomainA.example.com" and naming scheme. The node names "node17.subdomainA.example.com" and
"node4.subdomainB.example.com" would automatically lead to different "node4.subdomainB.example.com" would automatically lead to different
ULA prefixes, which can be used to introduce a routing hierarchy in ULA prefixes, which can be used to introduce a routing hierarchy in
the network, assuming that the subdomains are aligned with routing the network, assuming that the subdomains are aligned with routing
areas. areas. Because the domain name in the ACP information field of the
certificate is used to authenticate an ACP peers certificate, care
must be taken when using such an approach though: To allow for
devices in separate subdomains to have mutually permitted
certificates, the domain part of the ACP information can not carry
the subdomain. Instead it shuold be carried as an extension to the
address part. This part will be ignored and instead only the address
field using the different subdomain hash based ULA prefix will be
used. Example:
anima.acp+FDA3:79A6:F6EE:0:200:0:6400:1+sub:subdomainA@example.com
5.8.5. Other ACP Addressing Sub-Schemes 5.9.5. 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 will assign a new "type" for each new addressing sub-scheme. IANA would need to assign a new "type" for each new addressing sub-
scheme.
5.9. Routing in the ACP 5.10. Routing in the ACP
Once ULA address are set up all autonomic entities should run a Once ULA address are set up all autonomic entities should run a
routing protocol within the autonomic control plane context. This routing protocol within the autonomic control plane context. This
routing protocol distributes the ULA created in the previous section routing protocol distributes the ULA created in the previous section
for reachability. The use of the autonomic control plane specific for reachability. The use of the autonomic control plane specific
context eliminates the probable clash with the global routing table context eliminates the probable clash with the global routing table
and also secures the ACP from interference from the configuration and also secures the ACP from interference from the configuration
mismatch or incorrect routing updates. mismatch or incorrect routing updates.
The establishment of the routing plane and its parameters are The establishment of the routing plane and its parameters are
skipping to change at page 23, line 13 skipping to change at page 25, line 5
plane. Therefore, no manual configuration is required. plane. Therefore, no manual configuration is required.
All routing updates are automatically secured in transit as the All routing updates are automatically secured in transit as the
channels of the autonomic control plane are by default secured, and channels of the autonomic control plane are by default secured, and
this routing runs only inside the ACP. this routing runs only inside the ACP.
The routing protocol inside the ACP is RPL ([RFC6550]) with the The routing protocol inside the ACP is RPL ([RFC6550]) with the
following profile. See Appendix A for more details on the choice of following profile. See Appendix A for more details on the choice of
RPL. RPL.
5.9.1. RPL Profile for the ACP 5.10.1. RPL Profile for the ACP
o RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations o RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations
with multicast support". Implementations should support also with multicast support". Implementations should support also
other modes. Note: Root indicates mode in DIO flow. other modes. Note: Root indicates mode in DIO flow.
o Objective Function (OF): Use OF0 [RFC6552]. No use of metric o Objective Function (OF): Use OF0 [RFC6552]. No use of metric
containers, Default RPLInstanceID = 0. containers, Default RPLInstanceID = 0.
* stretch_rank: none provided ("not stretched"). * stretch_rank: none provided ("not stretched").
skipping to change at page 24, line 5 skipping to change at page 25, line 43
* Registrar (Default): 0b011 * Registrar (Default): 0b011
* AN-connect (non registrar): 0b010 * AN-connect (non registrar): 0b010
* Default: 0b001. * Default: 0b001.
The RPL root can create additional RPL instances with other OF and The RPL root can create additional RPL instances with other OF and
metrics as desired, eg: via intent. metrics as desired, eg: via intent.
5.10. General ACP Considerations 5.11. General ACP Considerations
In order to be independent of configured link addresses, channels In order to be independent of configured link addresses, channels
SHOULD use IPv6 link local addresses between adjacent neighbors SHOULD use IPv6 link local addresses between adjacent neighbors
wherever possible. This way, the ACP tunnels are independent of wherever possible. This way, the ACP tunnels are independent of
correct network wide routing. correct network wide routing.
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 5.9. to its neighbors in the ACP. Routing is discussed in Section 5.10.
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 on every link, but it is possible to establish the ACP established on every link, but it is possible to establish the ACP
only on a sub-set of links. Having an ACP channel on every link has 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 failover a number of advantages, for example it allows for a faster failover
in case of link failure, and it reflects the physical topology more in case of link failure, and it reflects the physical topology more
closely. Using a subset of links (for example, a single link), closely. Using a subset of links (for example, a single link),
reduces resource consumption on the devices, because state needs to reduces resource consumption on the devices, because state needs to
be kept per ACP channel. be kept per ACP channel.
6. Workarounds for Non-Autonomic Nodes 6. Workarounds for Non-Autonomic Nodes
6.1. Connecting a Non-Autonomic Controller / NMS system 6.1. Non-Autonomic Controller / NMS system (ACP connect)
The Autonomic Control Plane can be used by management systems, such The Autonomic Control Plane can be used by management systems, such
as controllers or network management system (NMS) hosts (henceforth as controllers or network management system (NMS) hosts (henceforth
called simply "NMS hosts"), to connect to devices through it. For called simply "NMS hosts"), to connect to devices through it. For
this, an NMS host must have access to the ACP. The ACP is a self- this, an NMS host must have access to the ACP. The ACP is a self-
protecting overlay network, which allows by default access only to protecting overlay network, which allows by default access only to
trusted, autonomic systems. Therefore, a traditional, non-autonomic trusted, autonomic systems. Therefore, a traditional, non-autonomic
NMS system does not have access to the ACP by default, just like any NMS system does not have access to the ACP by default, just like any
other external device. other external device.
If the NMS host is not autonomic, i.e., it does not support autonomic If the NMS host is not autonomic, i.e., it does not support autonomic
negotiation of the ACP, then it can be brought into the ACP by negotiation of the ACP, then it can be brought into the ACP by
explicit configuration. On an adjacent autonomic node with ACP, the explicit configuration. To support connections to adjacent non-
interface with the NMS host can be configured as "ACP Connect". In autonomic nodes, an autonomic node with ACP must support "ACP
this case, all devices on this port, including the NMS host, is connect" (sometimes also connect "autonomic connect"):
entirely and exclusively inside the ACP. It would likely require a
second interface outside the ACP for connections between the NMS host
and administrators, or Internet based services. This mode of
connecting an NMS host has security consequences: All systems and
processes connected to this implicitly trusted "ACP Connect"
interface have access to all autonomic nodes on the entire ACP,
without further authentication. Thus, this connection must be
physically controlled.
The non-autonomic NMS host must be routed in the ACP. This involves "ACP connect" is a function on an autonomic device that we call an
two parts: 1) the NMS host must point default to the AN device for "ACP edge device". With "ACP connect", interfaces on the device can
the ULA prefix used inside the ACP, and 2) the prefix used between AN be configured to be put into the ACP VRF. The ACP is then accessible
node and NMS host must be announced into the ACP, and distributed to other (NOC) systems on such an interface without those systems
there. having to support any ACP discovery or ACP channel setup. This is
also called "native" access to the ACP because to those (NOC) systems
the interface looks like a normal network interface (without any
encryption/novel-signaling).
The document "Autonomic Network Stable Connectivity" data-plane "native" (no ACP)
[I-D.ietf-anima-stable-connectivity] explains in more detail how the .
ACP can be integrated in a mixed NOC environment. +-----------+ +-----------+ . +-------------+
| | | Autonomic | v | |+
| | | Device |-----------------| |+
| Autonomic |-----------|"ACP edge | | NOC Device ||
| Device | ^ | device" O-----------------| "NMS hosts" ||
| | . | | . ^ | ||
+-----------+ . +-----------+ . . +-------------+|
. . . +-------------+
data-plane "native" . ACP "native" (unencrypted)
+ ACP auto-negotiated .
and encrypted ACP connect interface
eg: "vrf ACP native" (config)
If an NMS host is autonomic itself, it negotiates access to the ACP Figure 5: ACP connect
with its neighbor, like any other autonomic node.
ACP connect has security consequences: All systems and processes
connected via ACP connect have access to all autonomic nodes on the
entire ACP, without further authentication. Thus, the ACP connect
interface and (NOC) systems connected to it must be physically
controlled/secured.
The ACP connect interface must be configured with some IPv6 address
prefix. This prefix could use the ACP address prefix or could be
different. It must be distributed into the ACP routing protocol
unless the ACP device is the root of the ACP routing protocol (eg:
when all other autonomic devices have a default route in the ACP
towards it). The NOC hosts must route the ACP address prefix to the
ACP edge devices address on the ACP connect interface.
An ACP connect interface provides exclusively access to only the ACP.
This is likely insufficient for many NOC hosts. Instead, they would
likely require a second interface outside the ACP for connections
between the NMS host and administrators, or Internet based services,
or even for direct access to the data plane. The document "Autonomic
Network Stable Connectivity" [I-D.ietf-anima-stable-connectivity]
explains in more detail how the ACP can be integrated in a mixed NOC
environment.
Note: If an NMS host is autonomic itself, it negotiates access to the
ACP with its neighbor, like any other autonomic node and then runs a
normal (encrypted) ACP connection to the neighbor.
6.2. ACP through Non-Autonomic L3 Clouds 6.2. ACP through Non-Autonomic L3 Clouds
Not all devices in a network may be autonomic. If non-autonomic Not all devices in a network may be autonomic. If non-autonomic
Layer-2 devices are between autonomic nodes, the communications Layer-2 devices are between autonomic nodes, the communications
described in this document should work, since it is IP based. described in this document should work, since it is IP based.
However, non-autonomic Layer-3 devices do not forward link local However, non-autonomic Layer-3 devices do not forward link local
autonomic messages, and thus break the Autonomic Control Plane. autonomic messages, and thus break the Autonomic Control Plane.
One workaround is to manually configure IP tunnels between autonomic One workaround is to manually configure IP tunnels between autonomic
skipping to change at page 26, line 36 skipping to change at page 29, line 23
prevent the enrolment of new devices during the partition. prevent the enrolment of new devices during the partition.
After a network partition, a re-merge will just establish the After a network partition, a re-merge will just establish the
previous status, certificates can be renewed, the CRL is available, previous status, certificates can be renewed, the CRL is available,
and new devices can be enrolled everywhere. Since all devices use and new devices can be enrolled everywhere. Since all devices use
the same trust anchor, a re-merge will be smooth. the same trust anchor, a re-merge will be smooth.
Merging two networks with different trust anchors requires the trust Merging two networks with different trust anchors requires the trust
anchors to mutually trust each other (for example, by cross-signing). anchors to mutually trust each other (for example, by cross-signing).
As long as the domain names are different, the addressing will not As long as the domain names are different, the addressing will not
overlap (see Section 5.8). overlap (see Section 5.9).
It is also highly desirable for implementation of the ACP to be able It is also highly desirable for implementation of the ACP to be able
to run it over interfaces that are administratively down. If this is to run it over interfaces that are administratively down. If this is
not feasible, then it might instead be possible to request explicit not feasible, then it might instead be possible to request explicit
operator override upon administrative actions that would operator override upon administrative actions that would
administratively bring down an interface across whicht the ACP is administratively bring down an interface across whicht the ACP is
running. Especially if bringing down the ACP is known to disconnect running. Especially if bringing down the ACP is known to disconnect
the operator from the device. For example any such down the operator from the device. For example any such down
administrative action could perform a dependency check to see if the administrative action could perform a dependency check to see if the
transport connection across which this action is performed is transport connection across which this action is performed is
skipping to change at page 28, line 37 skipping to change at page 31, line 23
device. device.
Fundamentally, security depends on correct operation, implementation Fundamentally, security depends on correct operation, implementation
and architecture. Autonomic approaches such as the ACP largely and architecture. Autonomic approaches such as the ACP largely
eliminate the dependency on correct operation; implementation and eliminate the dependency on correct operation; implementation and
architectural mistakes are still possible, as in all networking architectural mistakes are still possible, as in all networking
technologies. technologies.
11. IANA Considerations 11. IANA Considerations
Section 5.5.3 describes ACP over dTLS, which requires a well-known
UDP port. We request IANA to assign this UDP port for 'ACP over
dTLS'.
Section 5.5.4 describes an option for the channel negotiation, the
'ACP channel type'. We request IANA to create a registry for 'ACP
channel type'.
The ACP channel type is a 8-bit unsigned integer. This document only
assigns the first value.
Number | Channel Type | RFC
---------+-----------------------------------+------------
0 | GRE tunnel protected with | this document
| IPsec transport mode |
1-255 | reserved for future channel types |
Section 5.8.2 describes a 'type' field in the base addressing scheme.
We request IANA to create a registry for the 'ACP addressing scheme
type', with the following initial values:
Number | Address Type (sub-scheme) | RFC
---------+-----------------------------------+------------
0 | Default address sub-scheme | this document
7 | Reserved for private use |
| sub-scheme |
12. Acknowledgements 12. Acknowledgements
This work originated from an Autonomic Networking project at Cisco This work originated from an Autonomic Networking project at Cisco
Systems, which started in early 2010. Many people contributed to Systems, which started in early 2010. Many people contributed to
this project and the idea of the Autonomic Control Plane, amongst this project and the idea of the Autonomic Control Plane, amongst
which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji which (in alphabetical order): Ignas Bagdonas, Parag Bhide, Balaji
BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Ravi BL, Alex Clemm, Yves Hertoghs, Bruno Klauser, Max Pritikin, Ravi
Kumar Vadapalli. Kumar Vadapalli.
Special thanks to Pascal Thubert to provide the details for the Special thanks to Pascal Thubert to provide the details for the
skipping to change at page 32, line 39 skipping to change at page 35, line 5
to BRSKY (bootstrap) discovery and pointed to Michael Richardsons to BRSKY (bootstrap) discovery and pointed to Michael Richardsons
draft detailing it. Removed appendix section that contained the draft detailing it. Removed appendix section that contained the
original explanations why GRASP would be useful (current text is original explanations why GRASP would be useful (current text is
meant to be better). meant to be better).
13.11. draft-ietf-anima-autonomic-control-plane-05 13.11. draft-ietf-anima-autonomic-control-plane-05
o Section 5.3 (candidate ACP neighbor selection): Add that Intent o Section 5.3 (candidate ACP neighbor selection): Add that Intent
can override only AFTER an initial default ACP establishment. can override only AFTER an initial default ACP establishment.
o Section 5.8.1 (addressing): State that addresses in the ACP are o Section 5.9.1 (addressing): State that addresses in the ACP are
permanent, and do not support temporary addresses as defined in permanent, and do not support temporary addresses as defined in
RFC4941. RFC4941.
o Modified Section 5.2.3 to point to the GRASP objective defined in o Modified Section 5.2.3 to point to the GRASP objective defined in
[I-D.carpenter-anima-ani-objectives]. (and added that reference) [I-D.carpenter-anima-ani-objectives]. (and added that reference)
o Section 5.8.2: changed from MD5 for calculating the first 40 bits o Section 5.9.2: changed from MD5 for calculating the first 40 bits
to SHA256; reason is MD5 should not be used any more. to SHA256; reason is MD5 should not be used any more.
o Added address sub-scheme to the IANA section. o Added address sub-scheme to the IANA section.
o Made the routing section more prescriptive. o Made the routing section more prescriptive.
o Clarified in Section 6.1 the ACP Connect port, and defined that o Clarified in Section 6.1 the ACP Connect port, and defined that
term "ACP Connect". term "ACP Connect".
o Section 6.2: Added some thoughts (from mcr) on how traversing a L3 o Section 6.2: Added some thoughts (from mcr) on how traversing a L3
cloud could be automated. cloud could be automated.
o Added a CRL check in Section 5.5. o Added a CRL check in Section 5.6.
o Added a note on the possibility of source-address spoofing into o Added a note on the possibility of source-address spoofing into
the security considerations section. the security considerations section.
o Other editoral changes, including those proposed by Michael o Other editoral changes, including those proposed by Michael
Richardson on 30 Nov 2016 (see ANIMA list). Richardson on 30 Nov 2016 (see ANIMA list).
13.12. draft-ietf-anima-autonomic-control-plane-06 13.12. draft-ietf-anima-autonomic-control-plane-06
o Added proposed RPL profile. o Added proposed RPL profile.
o detailed dTLS profile - dTLS with any additional negotiation/ o detailed dTLS profile - dTLS with any additional negotiation/
signaling channel. signaling channel.
o Fixed up text for ACP/GRE encap. Removed text claiming its o Fixed up text for ACP/GRE encap. Removed text claiming its
incompatible with non-GRE IPsec and detailled it. incompatible with non-GRE IPsec and detailled it.
o Added text to suggest admin down interfaces should still run ACP. o Added text to suggest admin down interfaces should still run ACP.
13.13. draft-ietf-anima-autonomic-control-plane-07
o Changed author association.
o Improved ACP connect setion (after confusion about term came up in
the stable connectivity draft review). Added picture, defined
complete terminology.
o Moved ACP channel negotiation from normative section to appendix
because it can in the timeline of this document not be fully
specified to be implementable. Aka: work for future document.
That work would also need to include analysing IKEv2 and describin
the difference of a proposed GRASP/TLS solution to it.
o Removed IANA request to allocate registry for GRASP/TLS. This
would come with future draft (see above).
o Gave the name "ACP information" to the field in the certificate
carrying the ACP address and domain name.
o Changed the rules for mutual authentication of certificates to
rely on the domain in the ACP information of the certificate
instead of the OU in the certificate. Also renewed the text
pointing out that the ACP information in the certificate is meant
to be in a form that it does not disturb other uses of the
certificate. As long as the ACP expected to rely on a common OU
across all certificates in a domain, this was not really true:
Other uses of the certificates might require different OUs for
different areas/type of devices. With the rules in this draft
version, the ACP authentication does not rely on any other fields
in the certificate.
o Added an extension field to the ACP information so that in the
future additional fields like a subdomain could be inserted. An
example using such a subdomain field was added to the pre-existing
text suggesting sub-domains. This approach is necessary so that
there can be a single (main) domain in the ACP information,
because that is used for mutual authentication of the certificate.
Also clarified that only the register(s) SHOULD/MUST use that the
ACP address was generated from the domain name - so that we can
easier extend change this in extensions.
o Took the text for the GRASP discovery of ACP neighbors from Brians
grasp-ani-objectives draft. Alas, that draft was behind the
latest GRASP draft, so i had to overhaul. The mayor change is to
describe in the ACP draft the whole format of the M_FLOOD message
(and not only the actual objective). This should make it a lot
easier to read (without having to go back and forth to the GRASP
RFC/draft). It was also necessary because the locator in the
M_FLOOD messages has an important role and its not coded inside
the objective. The specification of how to format the M_FLOOD
message shuold now be complete, the text may be some duplicate
with the DULL specificateion in GRASP, but no contradiction.
o One of the main outcomes of reworking the GRASP section was the
notion that GRASP announces both the candidate peers IPv6 link
local address but also the support ACP security protocol including
the port it is running on. In the past we shied away from using
this information because it is not secured, but i think the
additional attack vectors possible by using this information are
negligible: If an attacker on an L2 subnet can fake another
devices GRASP message then it can already provide a similar amount
of attack by purely faking the link-local address.
o Removed the section on discovery and BRSKI. This can be revived
in the BRSKI document, but it seems mood given how we did remove
mDNS from the latest BRSKI document (aka: this section discussed
discrepancies between GRASP and mDNS discovery which should not
exist anymore with latest BRSKI.
o Tried to resolve the EDNOTE about CRL vs. OCSP by pointing out we
do not specify which one is to be used but that the ACP should be
used to reach the URL included in the certificate to get to the
CRL storage or OCSP server.
o Changed ACP via IPsec to ACP via IKEv2 and restructured the
sections to make IPsec native and IPsec via GRE subsections.
o No need for any assigned dTLS port if ACP is run across dTLS
because it is signalled via GRASP.
14. References 14. References
[I-D.carpenter-anima-ani-objectives] [I-D.carpenter-anima-ani-objectives]
Carpenter, B. and B. Liu, "Technical Objective Formats for Carpenter, B. and B. Liu, "Technical Objective Formats for
the Autonomic Network Infrastructure", draft-carpenter- the Autonomic Network Infrastructure", draft-carpenter-
anima-ani-objectives-01 (work in progress), February 2017. anima-ani-objectives-02 (work in progress), June 2017.
[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-05 (work in progress), March 2017. keyinfra-06 (work in progress), May 2017.
[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-10 (work in progress), March 2017. grasp-14 (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-03 (work in progress), March 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-02 (work in progress), February anima-stable-connectivity-02 (work in progress), February
2017. 2017.
[I-D.richardson-anima-6join-discovery] [I-D.richardson-anima-6join-discovery]
Richardson, M., "GRASP discovery of Registrar by Join Richardson, M., "GRASP discovery of Registrar by Join
Assistant", draft-richardson-anima-6join-discovery-00 Assistant", draft-richardson-anima-6join-discovery-00
skipping to change at page 37, line 26 skipping to change at page 41, line 18
several parallel DODAGs, should this be required. This could be several parallel DODAGs, should this be required. This could be
used to create different topologies to reach different roots. used to create different topologies to reach different roots.
o No need for path optimisation: RPL does not necessarily compute o No need for path optimisation: RPL does not necessarily compute
the optimal path between any two nodes. However, the ACP does not the optimal path between any two nodes. However, the ACP does not
require this today, since it carries mainly non-delay-sensitive require this today, since it carries mainly non-delay-sensitive
feedback loops. It is possible that different optimisation feedback loops. It is possible that different optimisation
schemes become necessary in the future, but RPL can be expanded schemes become necessary in the future, but RPL can be expanded
(see point "Extensibility" above). (see point "Extensibility" above).
Appendix B. Extending ACP channel negotiation (via GRASP)
The mechanism described in the normative part of this document to
support multiple different ACP secure channel protocols without a
single network wide MTI protocol is important to allow extending
secure ACP channel protocols beyond what is specified in this
document, but it will run into problem if it would be used for
multiple protocols:
The need to potentially have multiple of these security associations
even temporarily run in parallel to determine which of them works
best does not support the most lightweight implementation options.
The simple policy of letting one side (Alice) decide what is best may
not lead to the mutual best result.
The two limitations can easier be solved if the solution was more
modular and as few as possible initial secure channel negotiation
protocols would be used, and these protocols would then take on the
responsibility to support more flexible objectives to negotiate the
mutually preferred ACP security channel protocol.
IKEv2 is the IETF standard protocol to negotiate network security
associations. It is meant to be extensible, but it is unclear
whether it would be feasible to extend IKEv2 to support possible
future requirements for ACP secure channel negotiation:
Consider the simple case where the use of native IPsec vs. IPsec via
GRE is to be negotiated and the objective is the maximum throughput.
Both sides would indicate some agreed upon performance metric and the
preferred encapsulation is the one with the higher performance of the
slower side. IKEv2 does not support negotiation with this objective.
Consider dTLS and some form of 802.1AE (MacSEC) are to be added as
negotiation options - and the performance objective should work
across all IPsec, dDTLS and 802.1AE options. In the case of MacSEC,
the negotiation would also need to determine a key for the peering.
It is unclear if it would be even appropriate to consider extending
the scope of negotiation in IKEv2 to those cases. Even if feasible
to define, it is unclear if implementations of IKEv2 would be eager
to adopt those type of extension given the long cycles of security
testing that necessarily goes along with core security protocols such
as IKEv2 implementations.
A more modular alternative to extending IKEv2 could be to layer a
modular negotiation mechanism on top of the multitide of existing or
possible future secure channel protocols. For this, GRASP over TLS
could be considered as a first ACP secure channel negotiation
protocol. The following are initial considerations for such an
approach. A full specification is subject to a separate document:
To explicitly allow negotiation of the ACP channel protocol, GRASP
over a TLS connection using the GRASP_LISTEN_PORT and the devices and
peers link-local IPv6 address is used. When Alice and Bob support
GRASP negotiation, they do prefer it over any other non-explicitly
negotiated security association protocol and should wait trying any
non-negotiated ACP channel protocol until after it is clear that
GRASP/TLS will not work to the peer.
When Alice and Bob successfully establish the GRASP/TSL session, they
will negotiate the channel mechanism to use using objectives such as
performance and perceived quality of the security. After agreeing on
a channel mechanism, Alice and Bob start the selected Channel
protocol. Once the secure channel protocol is successfully running,
the GRASP/TLS connection can be kept alive or timed out as long as
the selected channel protocol has a secure association between Alice
and Bob. When it terminates, it needs to be re-negotiated via GRASP/
TLS.
Notes:
o Negotiation of a channel type may require IANA assignments of code
points.
o TLS is subject to reset attacks, which IKEv2 is not. Normally,
ACP connections (as specified in this document) will be over link-
local addresses so the attack surface for this one issue in TCP is
highly reduced.
o GRASP packets received inside a TLS connection established for
GRASP/TLS ACP negotiation are assigned to a separate GRASP domain
unique to that TLS connection.
Authors' Addresses Authors' Addresses
Michael H. Behringer (editor) Michael H. Behringer (editor)
Cisco Systems
Building D, 45 Allee des Ormes
Mougins 06250
France
Email: mbehring@cisco.com Email: mchael.h.behringer@gmail.com
Toerless Eckert Toerless Eckert (editor)
Futurewei Technologies Inc. Futurewei Technologies Inc.
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara 95050
USA USA
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
Steinthor Bjarnason Steinthor Bjarnason
Arbor Networks Arbor Networks
2727 South State Street, Suite 200 2727 South State Street, Suite 200
Ann Arbor MI 48104 Ann Arbor MI 48104
United States United States
Email: sbjarnason@arbor.net Email: sbjarnason@arbor.net
 End of changes. 94 change blocks. 
322 lines changed or deleted 580 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/