draft-ietf-anima-autonomic-control-plane-04.txt   draft-ietf-anima-autonomic-control-plane-05.txt 
ANIMA WG M. Behringer, Ed. ANIMA WG M. Behringer, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track T. Eckert Intended status: Standards Track T. Eckert
Expires: May 4, 2017 Expires: July 15, 2017
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
October 31, 2016 January 11, 2017
An Autonomic Control Plane An Autonomic Control Plane
draft-ietf-anima-autonomic-control-plane-04 draft-ietf-anima-autonomic-control-plane-05
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 May 4, 2017. This Internet-Draft will expire on July 15, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
5.1.1. Domain Certificate with ANIMA information . . . . . . 8 5.1.1. Domain Certificate with ANIMA information . . . . . . 8
5.1.2. AN Adjacency Table . . . . . . . . . . . . . . . . . 9 5.1.2. AN Adjacency Table . . . . . . . . . . . . . . . . . 9
5.2. Neighbor discovery . . . . . . . . . . . . . . . . . . . 10 5.2. Neighbor discovery . . . . . . . . . . . . . . . . . . . 10
5.2.1. L2 topology considerations . . . . . . . . . . . . . 10 5.2.1. L2 topology considerations . . . . . . . . . . . . . 10
5.2.2. CDP/LLDP/mDNS considerations . . . . . . . . . . . . 11 5.2.2. CDP/LLDP/mDNS considerations . . . . . . . . . . . . 11
5.2.3. Discovery with GRASP . . . . . . . . . . . . . . . . 11 5.2.3. Discovery with GRASP . . . . . . . . . . . . . . . . 11
5.2.4. Discovery and BRSKY . . . . . . . . . . . . . . . . . 12 5.2.4. Discovery and BRSKY . . . . . . . . . . . . . . . . . 12
5.3. Candidate ACP Neighbor Selection . . . . . . . . . . . . 12 5.3. Candidate ACP Neighbor Selection . . . . . . . . . . . . 12
5.4. Channel Selection . . . . . . . . . . . . . . . . . . . . 13 5.4. Channel Selection . . . . . . . . . . . . . . . . . . . . 13
5.5. Security Association protocols . . . . . . . . . . . . . 14 5.5. Security Association protocols . . . . . . . . . . . . . 14
5.5.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 14 5.5.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 15
5.5.2. ACP via GRE/IPsec . . . . . . . . . . . . . . . . . . 15 5.5.2. ACP via GRE/IPsec . . . . . . . . . . . . . . . . . . 15
5.5.3. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 15 5.5.3. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 15
5.5.4. GRASP/TLS negotiation . . . . . . . . . . . . . . . . 15 5.5.4. GRASP/TLS negotiation . . . . . . . . . . . . . . . . 15
5.5.5. ACP Security Profiles . . . . . . . . . . . . . . . . 16 5.5.5. ACP Security Profiles . . . . . . . . . . . . . . . . 16
5.6. GRASP instance details . . . . . . . . . . . . . . . . . 16 5.6. GRASP instance details . . . . . . . . . . . . . . . . . 16
5.7. Context Separation . . . . . . . . . . . . . . . . . . . 16 5.7. Context Separation . . . . . . . . . . . . . . . . . . . 16
5.8. Addressing inside the ACP . . . . . . . . . . . . . . . . 16 5.8. Addressing inside the ACP . . . . . . . . . . . . . . . . 17
5.8.1. Fundamental Concepts of Autonomic Addressing . . . . 17 5.8.1. Fundamental Concepts of Autonomic Addressing . . . . 17
5.8.2. The ACP Addressing Base Scheme . . . . . . . . . . . 18 5.8.2. The ACP Addressing Base Scheme . . . . . . . . . . . 18
5.8.3. ACP Addressing Sub-Scheme . . . . . . . . . . . . . . 18 5.8.3. ACP Addressing Sub-Scheme . . . . . . . . . . . . . . 19
5.8.4. Usage of the Zone Field . . . . . . . . . . . . . . . 20 5.8.4. Usage of the Zone Field . . . . . . . . . . . . . . . 20
5.8.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 20 5.8.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 21
5.9. Routing in the ACP . . . . . . . . . . . . . . . . . . . 21 5.9. Routing in the ACP . . . . . . . . . . . . . . . . . . . 21
5.10. General ACP Considerations . . . . . . . . . . . . . . . 21 5.10. General ACP Considerations . . . . . . . . . . . . . . . 21
6. Workarounds for Non-Autonomic Nodes . . . . . . . . . . . . . 22 6. Workarounds for Non-Autonomic Nodes . . . . . . . . . . . . . 22
6.1. Connecting a Non-Autonomic Controller / NMS system . . . 22 6.1. Connecting a Non-Autonomic Controller / NMS system . . . 22
6.2. ACP through Non-Autonomic L3 Clouds . . . . . . . . . . . 22 6.2. ACP through Non-Autonomic L3 Clouds . . . . . . . . . . . 23
7. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 23 7. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 23
8. Self-Protection Properties . . . . . . . . . . . . . . . . . 24 8. Self-Protection Properties . . . . . . . . . . . . . . . . . 24
9. The Administrator View . . . . . . . . . . . . . . . . . . . 24 9. The Administrator View . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 26 13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 27
13.1. Initial version . . . . . . . . . . . . . . . . . . . . 26 13.1. Initial version . . . . . . . . . . . . . . . . . . . . 27
13.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 26 13.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 27
13.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 26 13.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 27
13.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 27 13.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 27
13.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 27 13.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 27
13.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 27 13.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 28
13.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 27 13.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 28
13.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 28 13.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 29
13.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 28 13.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 29
13.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 29 13.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 13.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 30
Appendix A. Background on the choice of routing protocol . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix A. Background on the choice of routing protocol . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 3, line 43 skipping to change at page 3, line 44
communicate on. This infrastructure should be as robust as possible, communicate on. This infrastructure should be as robust as possible,
and it should be re-usable by all autonomic functions. [RFC7575] and it should be re-usable by all autonomic functions. [RFC7575]
calls it the "Autonomic Control Plane". This document defines the calls it the "Autonomic Control Plane". This document defines the
Autonomic Control Plane. Autonomic Control Plane.
Today, the management and control plane of networks typically runs in Today, the management and control plane of networks typically runs in
the global routing table, which is dependent on correct configuration the global routing table, which is dependent on correct configuration
and routing. Misconfigurations or routing problems can therefore and routing. Misconfigurations or routing problems can therefore
disrupt management and control channels. Traditionally, an out of disrupt management and control channels. Traditionally, an out of
band network has been used to recover from such problems, or band network has been used to recover from such problems, or
personnel is sent on site to access devices through console ports. personnel is sent on site to access devices through console ports
However, both options are operationally expensive. (craft ports). However, both options are operationally expensive.
In increasingly automated networks either controllers or distributed In increasingly automated networks either controllers or distributed
autonomic service agents in the network require a control plane which autonomic service agents in the network require a control plane which
is independent of the network they manage, to avoid impacting their is independent of the network they manage, to avoid impacting their
own operations. own operations.
This document describes options for a self-forming, self-managing and This document describes options for a self-forming, self-managing and
self-protecting "Autonomic Control Plane" (ACP) which is inband on self-protecting "Autonomic Control Plane" (ACP) which is inband on
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 inside the ACP. [I-D.ietf-anima-grasp] can run securely inside the ACP.
o An operator can use it to log into remote devices, even if the o An operator can use it to log into remote devices, even if the
data plane is misconfigured or unconfigured. data plane is misconfigured or unconfigured.
o A controller or network management system can use it to securely o A controller or network management system can use it to securely
bootstrap network devices in remote locations, even if the network bootstrap network devices in remote locations, even if the network
in between is not yet configured; no data-plane dependent in between is not yet configured; no data-plane dependent
bootstrap configuration is required. An example of such a secure bootstrap configuration is required. An example of such a secure
bootstrap process is described in bootstrap process is described in
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
skipping to change at page 6, line 21 skipping to change at page 6, line 21
The document "Autonomic Network Stable Connectivity" The document "Autonomic Network Stable Connectivity"
[I-D.ietf-anima-stable-connectivity] explains the use cases for the [I-D.ietf-anima-stable-connectivity] explains the use cases for the
ACP in significantly more detail and explains how the ACP can be used ACP in significantly more detail and explains how the ACP can be used
in practical network operations. in practical network operations.
3. Requirements 3. Requirements
The Autonomic Control Plane has the following requirements: The Autonomic Control Plane has the following requirements:
1. The ACP SHOULD provide robust connectivity: As far as possible, ACP1: The ACP SHOULD provide robust connectivity: As far as
it should be independent of configured addressing, configuration possible, it should be independent of configured addressing,
and routing. Requirements 2 and 3 build on this requirement, but configuration and routing. Requirements 2 and 3 build on this
also have value on their own. requirement, but also have value on their own.
2. The ACP MUST have a separate address space from the data plane. ACP2: The ACP MUST have a separate address space from the data
Reason: traceability, debug-ability, separation from data plane, plane. Reason: traceability, debug-ability, separation from
security (can block easily at edge). data plane, security (can block easily at edge).
3. The ACP MUST use autonomically managed address space. Reason: ACP3: The ACP MUST use autonomically managed address space. Reason:
easy bootstrap and setup ("autonomic"); robustness (admin can't easy bootstrap and setup ("autonomic"); robustness (admin
mess things up so easily). This document suggests to use ULA can't mess things up so easily). This document suggests to
addressing for this purpose. use ULA addressing for this purpose.
4. The ACP MUST be generic. Usable by all the functions and ACP4: The ACP MUST be generic. Usable by all the functions and
protocols of the AN infrastructure. It MUST NOT be tied to a protocols of the AN infrastructure. It MUST NOT be tied to a
particular protocol. particular protocol.
5. The ACP MUST provide security: Messages coming through the ACP ACP5: The ACP MUST provide security: Messages coming through the ACP
MUST be authenticated to be from a trusted node, and SHOULD (very MUST be authenticated to be from a trusted node, and SHOULD
strong SHOULD) be encrypted. (very strong SHOULD) be encrypted.
The default mode of operation of the ACP is hop-by-hop, because this The default mode of operation of the ACP is hop-by-hop, because this
interaction can be built on IPv6 link local addressing, which is interaction can be built on IPv6 link local addressing, which is
autonomic, and has no dependency on configuration (requirement 1). autonomic, and has no dependency on configuration (requirement 1).
It may be necessary to have end-to-end connectivity in some cases, It may be necessary to have ACP connectivity over non-autonomic
for example to provide an end-to-end security association for some nodes, for example to link autonomic nodes over the general Internet.
protocols. This is possible, but then has a dependency on routable This is possible, but then has a dependency on routing over the non-
address space. autonomic hops.
4. Overview 4. Overview
The Autonomic Control Plane is constructed in the following way (for The Autonomic Control Plane is constructed in the following way (for
details, see Section 5): details, see Section 5):
o An autonomic node creates a virtual routing and forwarding (VRF) 1. An autonomic node creates a virtual routing and forwarding (VRF)
instance, or a similar virtual context. instance, or a similar virtual context.
o It determines, following a policy, a candidate peer list. This is 2. It determines, following a policy, a candidate peer list. This
the list of nodes to which it should establish an autonomic is the list of nodes to which it should establish an Autonomic
control plane. Default policy is: To all adjacent nodes in the Control Plane. Default policy is: To all adjacent nodes in the
same domain. Intent can override this default policy. same domain.
o For each node in the candidate peer list, it authenticates that 3. For each node in the candidate peer list, it authenticates that
node and negotiates a mutually acceptable channel type. node and negotiates a mutually acceptable channel type.
o It then establishes a secure tunnel of the negotiated channel 4. It then establishes a secure tunnel of the negotiated channel
type. These tunnels are placed into the previously set up VRF. type. These tunnels are placed into the previously set up VRF.
This creates an overlay network with hop-by-hop tunnels. This creates an overlay network with hop-by-hop tunnels.
o Inside the ACP VRF, each node sets up a virtual interface with its 5. Inside the ACP VRF, each node sets up a virtual interface with
ULA IPv6 address. its ULA IPv6 address.
o Each node runs a lightweight routing protocol, to announce 6. Each node runs a lightweight routing protocol, to announce
reachability of the virtual addresses inside the ACP. reachability of the virtual addresses inside the ACP.
Note:
o Non-autonomic NMS systems or controllers have to be manually o Non-autonomic NMS systems or controllers have to be manually
connected into the ACP. connected into the ACP.
o Connecting over non-autonomic Layer-3 clouds initially requires a o Connecting over non-autonomic Layer-3 clouds initially requires a
tunnel between autonomic nodes. tunnel between autonomic nodes.
o None of the above operations (except manual ones) is reflected in o None of the above operations (except manual ones) is reflected in
the configuration of the device. the configuration of the device.
skipping to change at page 8, line 50 skipping to change at page 8, line 50
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 ANIMA 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 of the domain. The document
[I-D.ietf-anima-bootstrapping-keyinfra] describes how a domain [I-D.ietf-anima-bootstrapping-keyinfra] describes how a domain
certificate can be automatically and securely derived from a vendor certificate can be automatically and securely derived from a vendor
specific Unique Device Identifier (UDI) or IDevID certificate. specific Unique Device Identifier (UDI) or IDevID certificate.
(Note: the UDI used in this document is NOT the UUID specified in
[RFC4122].)
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, and its ACP
address with the zone-ID set to zero. This information MUST be address with the zone-ID set to zero. This information MUST be
encoded in the LDevID in the subjectAltName / rfc822Name field in the encoded in the LDevID in the subjectAltName / rfc822Name field in the
following way: following way:
anima.acp+<ACP address>@<domain> anima.acp+<ACP address>@<domain>
An example: An example:
skipping to change at page 10, line 16 skipping to change at page 10, line 16
nodes in general, independently of their domain and trust status. nodes in general, independently of their domain and trust status.
The next step determines to which of those autonomic nodes an ACP The next step determines to which of those autonomic nodes an ACP
connection should be established. connection should be established.
5.2. Neighbor discovery 5.2. Neighbor discovery
5.2.1. L2 topology considerations 5.2.1. L2 topology considerations
ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2
.../ \ \ ... .../ \ \ ...
ANrtrI ------ \ ------- ANrtrN ANrtrM ------ \ ------- ANrtrN
ANswitchI ... ANswitchM ...
Figure 2 Figure 2
Consider a large L2 LAN with ANrtr1...ANrtrN connected via some Consider a large L2 LAN with ANrtr1...ANrtrN connected via some
topology of L2 switches (eg: in a large enterprise campus or IoT topology of L2 switches (eg: in a large enterprise campus or IoT
environment using large L2 LANs). If the discovery protocol used for environment using large L2 LANs). If the discovery protocol used for
the ACP is operating at the subnet level, every AN router will see the ACP is operating at the subnet level, every AN router will see
all other AN routers on the LAN as neighbors and a full mesh of ACP all other AN routers on the LAN as neighbors and a full mesh of ACP
channels will be built. If some or all of the AN switches are channels will be built. If some or all of the AN switches are
autonomic with the same discovery protocol, then the full mesh would autonomic with the same discovery protocol, then the full mesh would
skipping to change at page 11, line 5 skipping to change at page 11, line 5
achieved if in topologies like these, AN capable L2 switches can achieved if in topologies like these, AN capable L2 switches can
ensure that discovery messages terminate on them so that neighboring ensure that discovery messages terminate on them so that neighboring
AN routers and switches will only find the physcially connected AN L2 AN routers and switches will only find the physcially connected AN L2
switches as their candidate ACP neighbors. With such a discovery switches as their candidate ACP neighbors. With such a discovery
mechanism in place, the ACP and its security associations will only mechanism in place, the ACP and its security associations will only
need to scale to the number of physcial interfaces instead of a need to scale to the number of physcial interfaces instead of a
potentially much larger number of "LAN-connected" neighbors. And the potentially much larger number of "LAN-connected" neighbors. And the
ACP topology will follow directly the physical topology, something ACP topology will follow directly the physical topology, something
which can then also be leveraged in management operations or by ASAs. which can then also be leveraged in management operations or by ASAs.
In the example above, consider ANswitch1 and ANswitchI are AN In the example above, consider ANswitch1 and ANswitchM are AN
capable, and ANswitch2 is not AN capable. The desired ACP topology capable, and ANswitch2 is not AN capable. The desired ACP topology
is therefore that ANrtr1 and ANrtrI only have an ACP connetion to is therefore that ANrtr1 and ANrtrM only have an ACP connetion to
ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP ANswitch1, and that ANswitch1, ANrtr2, ANrtrN have a full mesh of ACP
connection amongst each other. ANswitch1 also has an ACP connection connection amongst each other. ANswitch1 also has an ACP connection
with ANswitchI and ANswitchI has ACP connections to anything else with ANswitchM and ANswitchM has ACP connections to anything else
behind it. behind it.
5.2.2. CDP/LLDP/mDNS considerations 5.2.2. CDP/LLDP/mDNS considerations
LLDP (and Ciscos CDP) are example of L2 discovery protocols that do LLDP (and Cisco's CDP) are example of L2 discovery protocols that
terminate their messages on L2 ports. Unfortunately, they will also terminate their messages on L2 ports. If those protocols would be
terminate their messages if they do not support the ACP and would chosen for ACP neighbor discovery, ACP neighbor discovery would
then inhibit ACP neighbor discovery therefore also terminate on L2 ports. This would prevent ACP
construction over non-ANIMA switches.
mDNS operates at the subnet level, and is also used on L2 switches. mDNS operates at the subnet level, and is also used on L2 switches.
The authors of this document are not aware of mDNS implementation The authors of this document are not aware of mDNS implementation
that terminate their messages on L2 ports instead of the subnet that terminate their messages on L2 ports instead of the subnet
level. If mDNS was used as the ACP discovery mechanism on an ACP level. If mDNS was used as the ACP discovery mechanism on an ACP
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
skipping to change at page 11, line 40 skipping to change at page 11, line 41
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 In conclusion for the above described considerations, the ACP uses
"insecure" instances of GRASP for discovery of ACP neighbors because "insecure" instances of GRASP for discovery of ACP neighbors because
it can easily be set up to match the requiremetns without affecting it can easily be set up to match the requiremetns without affecting
other uses of the protocol. other uses of the protocol.
The name of the GRASP objective to announce/discover the capability The name of the GRASP objective to announce/discover the capability
of a neighbor to run the ACP is "ACP". All other parameters are of a neighbor to run the ACP is "ACP". Section 3.5.2.2 of
defined in section [I-D.ietf-anima-grasp] where these instances of [I-D.ietf-anima-grasp] describes the instance of GRASP to be used for
GRASP are called "DULL" (Discovery Unsolicited Link Local). As this purpose: "DULL" (Discovery Unsolicited Link Local). The precise
explained above, in an ACP enabled L2 switch, each of these instances GRASP objective to be used is specified in Section 3 of
would actually need to be per-L2-port. The result of the discovery [I-D.carpenter-anima-ani-objectives].
is the IPv6 link-local address of the neighbor. It is stored in the
AN Adjacency Table, see Section 5.1.2 which then drives the further As explained above, in an ACP enabled L2 switch, each of these
building of the ACP to that neighbor. 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
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.
skipping to change at page 12, line 42 skipping to change at page 12, line 47
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. The precise format for Intent can change this default behaviour. Since Intent is
transported over the ACP, the first ACP connection a node establishes
is always following the default behaviour. The precise format for
this Intent needs to be defined outside this document. Example this Intent needs to be defined outside this document. Example
Intent policies are: Intent policies which need to be supported include:
o The ACP should be built between all sub-domains for a given parent o The ACP should be built between all sub-domains for a given parent
domain. For example: For domain "example.com", nodes of domain. For example: For domain "example.com", nodes of
"example.com", "access.example.com", "core.example.com" and "example.com", "access.example.com", "core.example.com" and
"city.core.example.com" should all establish one single ACP. "city.core.example.com" should all establish one single ACP.
o Two domains should build one single ACP between themselves, for o Two domains should build one single ACP between themselves, for
example "example1.com" should establish the ACP also with nodes example "example1.com" should establish the ACP also with nodes
from "example2.com". For this case, the two domains must be able from "example2.com". For this case, the two domains must be able
to validate their trust, typically by cross-signing their to validate their trust, typically by cross-signing their
skipping to change at page 14, line 28 skipping to change at page 14, line 33
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.
5.5. Security Association protocols 5.5. Security Association protocols
The following sections define the security association protocols that The following sections define the security association protocols that
we consider to be important and feasible to specify in this document. we consider to be important and feasible to specify in this document.
In all cases, the mutual authentication is done via the autonomic In all cases, the mutual authentication is done via the autonomic
domain certificate of the peer as follows - unless superceeded by domain certificate of the peer as follows - unless superceeded by
intent: Intent:
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 OU (Organizational Unit) field in the certificates
Subject is the same as in the devices certificate. Subject is the same as in the devices certificate.
5.5.1. ACP via IPsec 5.5.1. ACP via 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 suppoting IPsec MUST
support IPsec security setup via IKEv2, transport mode encapsulation support IPsec security setup via IKEv2, transport mode encapsulation
via the device and peer link-local IPv6 addresses and AES256 via the device and peer link-local IPv6 addresses and AES256
encryption. Further parameter options can be negotiated via IKEv2 or encryption.
via GRASP/TLS.
5.5.2. ACP via GRE/IPsec 5.5.2. ACP via GRE/IPsec
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 described above, but instead of directly carrying the ACP IPv6
packets, the payload is an ACP IPv6 packet inside GRE/IPv6. packets, the payload is an ACP IPv6 packet inside GRE/IPv6.
Note that without explicit negotiation (eg: via GRASP/TLS), this Note that without explicit negotiation (eg: via GRASP/TLS), this
method is incompatible to direct ACP via IPsec, so it must only be method is incompatible to direct ACP via IPsec, so it must only be
used as an option during GRASP/TLS negotiation. used as an option during negotiation.
5.5.3. ACP via dTLS 5.5.3. ACP via dTLS
To run ACP via UDP and dTLS v1.2 [RFC6347] an IANA assigned port To run ACP via UDP and dTLS v1.2 [RFC6347] an IANA assigned port
[TBD] is used. All autonomic devices supporting ACP via dTLS must [TBD] is used. All autonomic devices supporting ACP via dTLS must
support AES256 encryption. support AES256 encryption.
5.5.4. GRASP/TLS negotiation 5.5.4. GRASP/TLS negotiation
To explicitly allow negotiation of the ACP channel protocol, GRASP To explicitly allow negotiation of the ACP channel protocol, GRASP
skipping to change at page 16, line 39 skipping to change at page 16, line 47
5.7. Context Separation 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,
The context for the ACP needs to be established automatically during such as a logical container or virtual machine instance. The context
bootstrap of a device. As much as possible it should be protected for the ACP needs to be established automatically during bootstrap of
from being modified unintentionally by data plane configuration. a device. As much as possible it should be protected from being
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.8. 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
skipping to change at page 17, line 38 skipping to change at page 17, line 48
robustness requirement. robustness requirement.
o Loopback-only: Only loopback interfaces of autonomic nodes carry a o Loopback-only: Only loopback interfaces of autonomic nodes carry a
routable address; all other interfaces exclusively use IPv6 link routable address; all other interfaces exclusively use IPv6 link
local for autonomic functions. The usage of IPv6 link local local for autonomic functions. The usage of IPv6 link local
addressing is discussed in [RFC7404]. addressing is discussed in [RFC7404].
o Use-ULA: For loopback interfaces of autonomic nodes, we use Unique o Use-ULA: For loopback interfaces of autonomic nodes, we use Unique
Local Addresses (ULA), as specified in [RFC4193]. An alternative Local Addresses (ULA), as specified in [RFC4193]. An alternative
scheme was discussed, using assigned ULA addressing. The scheme was discussed, using assigned ULA addressing. The
consensus was to use standard ULA, because it was deemed to be consensus was to use ULA-random [[RFC4193] with L=1], because it
sufficient. was deemed to be sufficient.
o No external connectivity: They do not provide access to the o No external connectivity: They do not provide access to the
Internet. If a node requires further reaching connectivity, it Internet. If a node requires further reaching connectivity, it
should use another, traditionally managed address scheme in should use another, traditionally managed address scheme in
parallel. parallel.
o Addresses in the ACP are permanent, and do not support temporary
addresses as defined in [RFC4941].
The ACP is based exclusively on IPv6 addressing, for a variety of The ACP is based exclusively on IPv6 addressing, for a variety of
reasons: reasons:
o Simplicity, reliability and scale: If other network layer o Simplicity, reliability and scale: If other network layer
protocols were supported, each would have to have its own set of protocols were supported, each would have to have its own set of
security associations, routing table and process, etc. security associations, routing table and process, etc.
o Autonomic functions do not require IPv4: Autonomic functions and o Autonomic functions do not require IPv4: Autonomic functions and
autonomic service agents are new concepts. They can be autonomic service agents are new concepts. They can be
exclusively built on IPv6 from day one. There is no need for exclusively built on IPv6 from day one. There is no need for
skipping to change at page 18, line 33 skipping to change at page 18, line 45
Figure 3: ACP Addressing Base Scheme Figure 3: ACP Addressing Base Scheme
The first 48 bits follow the ULA scheme, as defined in [RFC4193], to The first 48 bits follow the ULA scheme, as defined in [RFC4193], to
which a type field is added: which a type field is added:
o "FD" identifies a locally defined ULA address. o "FD" identifies a locally defined ULA address.
o The ULA "global ID" is set here to be a hash of the 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 MD5 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 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.8.3. ACP Addressing Sub-Scheme
skipping to change at page 20, line 9 skipping to change at page 20, line 22
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
be considered (https://mailarchive.ietf.org/arch/msg/anima/
nZpEphrTqDCBdzsKMpaIn2gsIzI).]
5.8.4. Usage of the Zone Field 5.8.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
zones. The allocation of zone numbers may either happen zones. The allocation of zone numbers may either happen
automatically through a to-be-defined algorithm; or it could be automatically through a to-be-defined algorithm; or it could be
configured and maintained manually. [We could divide the zone space configured and maintained manually.
into manual and automatic space - to be discussed.]
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
skipping to change at page 21, line 20 skipping to change at page 21, line 34
for reachability. The use of the autonomic control plane specific for reachability. The use of the autonomic control plane specific
context eliminates the probable clash with the global routing table context eliminates the probable clash with the global routing table
and also secures the ACP from interference from the configuration and also secures the ACP from interference from the configuration
mismatch or incorrect routing updates. mismatch or incorrect routing updates.
The establishment of the routing plane and its parameters are The establishment of the routing plane and its parameters are
automatic and strictly within the confines of the autonomic control automatic and strictly within the confines of the autonomic control
plane. Therefore, no manual configuration is required. plane. Therefore, no 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. channels of the autonomic control plane are by default secured, and
this routing runs only inside the ACP.
The routing protocol inside the ACP should be light weight and highly The routing protocol inside the ACP is RPL [RFC6550]. See Appendix A
scalable to ensure that the ACP does not become a limiting factor in for more details on the choice of RPL.
network scalability. We suggest the use of RPL [RFC6550] as one such
protocol which is light weight and scales well for the control plane [EDNOTE: Need to decide: storing / non-storing mode; mcr suggests
traffic. See Appendix A for more details on the choice of RPL. storing mode. Need to define more parameters in detail.]
5.10. General ACP Considerations 5.10. 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
skipping to change at page 22, line 12 skipping to change at page 22, line 23
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. Connecting a Non-Autonomic Controller / NMS system
The Autonomic Control Plane can be used by management systems, such The Autonomic Control Plane can be used by management systems, such
as controllers or network management system (NMS) hosts (henceforth as controllers or network management system (NMS) hosts (henceforth
called simply "NMS hosts"), to connect to devices through it. For called simply "NMS hosts"), to connect to devices through it. For
this, an NMS host must have access to the ACP. By default, the ACP this, an NMS host must have access to the ACP. The ACP is a self-
is a self-protecting overlay network, which only allows access to protecting overlay network, which allows by default access only to
trusted systems. Therefore, a traditional, non-autonomic NMS system trusted, autonomic systems. Therefore, a traditional, non-autonomic
does not have access to the ACP by default, just like any other NMS system does not have access to the ACP by default, just like any
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. On an adjacent autonomic node with ACP, the
interface with the NMS host can be configured to be part of the ACP. interface with the NMS host can be configured as "ACP Connect". In
In this case, the NMS host is with this interface entirely and this case, all devices on this port, including the NMS host, is
exclusively inside the ACP. It would likely require a second entirely and exclusively inside the ACP. It would likely require a
interface for connections between the NMS host and administrators, or second interface outside the ACP for connections between the NMS host
Internet based services. This mode of connecting an NMS host has and administrators, or Internet based services. This mode of
security consequences: All systems and processes connected to this connecting an NMS host has security consequences: All systems and
implicitly trusted interface have access to all autonomic nodes on processes connected to this implicitly trusted "ACP Connect"
the entire ACP, without further authentication. Thus, this interface have access to all autonomic nodes on the entire ACP,
connection must be physically controlled. without further authentication. Thus, this connection must be
physically controlled.
The non-autonomic NMS host must be routed in the ACP. This involves The non-autonomic NMS host must be routed in the ACP. This involves
two parts: 1) the NMS host must point default to the AN device for two parts: 1) the NMS host must point default to the AN device for
the ULA prefix used inside the ACP, and 2) the prefix used between AN the ULA prefix used inside the ACP, and 2) the prefix used between AN
node and NMS host must be announced into the ACP, and distributed node and NMS host must be announced into the ACP, and distributed
there. there.
The document "Autonomic Network Stable Connectivity" The document "Autonomic Network Stable Connectivity"
[I-D.ietf-anima-stable-connectivity] explains in more detail how the [I-D.ietf-anima-stable-connectivity] explains in more detail how the
ACP can be integrated in a mixed NOC environment. ACP can be integrated in a mixed NOC environment.
If an NMS host is autonomic itself, it negotiates access to the ACP
with its neighbor, like any other autonomic node.
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
nodes across a non-autonomic Layer-3 cloud. The tunnels are nodes across a non-autonomic Layer-3 cloud. The tunnels are
represented on each autonomic node as virtual interfaces, and all represented on each autonomic node as virtual interfaces, and all
autonomic transactions work across such tunnels. autonomic transactions work across such tunnels.
Such manually configured tunnels are less "indestructible" than an Such manually configured tunnels are less "indestructible" than an
automatically created ACP based on link local addressing, since they automatically created ACP based on link local addressing, since they
depend on correct data plane operations, such as routing and depend on correct data plane operations, such as routing and
addressing. addressing.
Future work should envisage an option where the edge device of the L3
cloud is configured to automatically forward ACP discovery messages
to the right exit point. This optimisation is not considered in this
document.
7. Self-Healing Properties 7. Self-Healing Properties
The ACP is self-healing: The ACP is self-healing:
o New neighbors will automatically join the ACP after successful o New neighbors will automatically join the ACP after successful
validation and will become reachable using their unique ULA validation and will become reachable using their unique ULA
address across the ACP. address across the ACP.
o When any changes happen in the topology, the routing protocol used o When any changes happen in the topology, the routing protocol used
in the ACP will automatically adapt to the changes and will in the ACP will automatically adapt to the changes and will
skipping to change at page 25, line 28 skipping to change at page 25, line 49
factors: factors:
o The usage of domain certificates depends on a valid supporting PKI o The usage of domain certificates depends on a valid supporting PKI
infrastructure. If the chain of trust of this PKI infrastructure infrastructure. If the chain of trust of this PKI infrastructure
is compromised, the security of the ACP is also compromised. This is compromised, the security of the ACP is also compromised. This
is typically under the control of the network administrator. is typically under the control of the network administrator.
o Security can be compromised by implementation errors (bugs), as in o Security can be compromised by implementation errors (bugs), as in
all products. all products.
There is no prevention of source-address spoofing inside the ACP.
This implies that if an attacker gains access to the ACP, (s)he can
spoof all addresses inside the ACP and fake messages from any other
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 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 UDP port. We request IANA to assign this UDP port for 'ACP over
skipping to change at page 26, line 7 skipping to change at page 26, line 32
assigns the first value. assigns the first value.
Number | Channel Type | RFC Number | Channel Type | RFC
---------+-----------------------------------+------------ ---------+-----------------------------------+------------
0 | GRE tunnel protected with | this document 0 | GRE tunnel protected with | this document
| IPsec transport mode | | IPsec transport mode |
1-255 | reserved for future channel types | 1-255 | reserved for future channel types |
Section 5.8.2 describes a 'type' field in the base addressing scheme. 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 We request IANA to create a registry for the 'ACP addressing scheme
type'. The initial value and definition will be determined in a type', with the following initial values:
later version of this document.
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.
skipping to change at page 29, line 20 skipping to change at page 29, line 51
o Editorial changes, updated draft references, etc. o Editorial changes, updated draft references, etc.
13.10. draft-ietf-anima-autonomic-control-plane-04 13.10. draft-ietf-anima-autonomic-control-plane-04
Changed discovery of ACP neighbor back from mDNS to GRASP after Changed discovery of ACP neighbor back from mDNS to GRASP after
revisiting the L2 problem. Described problem in discovery section revisiting the L2 problem. Described problem in discovery section
itself to justify. Added text to explain how ACP discovery relates itself to justify. Added text to explain how ACP discovery relates
to BRSKY (bootstrap) discovery and pointed to Michael Richardsons to BRSKY (bootstrap) discovery and pointed to Michael Richardsons
draft detailing it. Removed appendix section that contained the draft detailing it. Removed appendix section that contained the
original explanations why GRASP would be usedul (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
o Section 5.3 (candidate ACP neighbor selection): Add that Intent
can override only AFTER an initial default ACP establishment.
o Section 5.8.1 (addressing): State that addresses in the ACP are
permanent, and do not support temporary addresses as defined in
RFC4941.
o Modified Section 5.2.3 to point to the GRASP objective defined in
[I-D.carpenter-anima-ani-objectives]. (and added that reference)
o Section 5.8.2: changed from MD5 for calculating the first 40 bits
to SHA256; reason is MD5 should not be used any more.
o Added address sub-scheme to the IANA section.
o Made the routing section more prescriptive.
o Clarified in Section 6.1 the ACP Connect port, and defined that
term "ACP Connect".
o Section 6.2: Added some thoughts (from mcr) on how traversing a L3
cloud could be automated.
o Added a CRL check in Section 5.5.
o Added a note on the possibility of source-address spoofing into
the security considerations section.
o Other editoral changes, including those proposed by Michael
Richardson on 30 Nov 2016 (see ANIMA list).
14. References 14. References
[I-D.carpenter-anima-ani-objectives]
Carpenter, B. and B. Liu, "Technical Objectives for the
Autonomic Network Infrastructure", draft-carpenter-anima-
ani-objectives-00 (work in progress), November 2016.
[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-04 (work in progress), October 2016. keyinfra-04 (work in progress), October 2016.
[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-08 (work in progress), October 2016. grasp-09 (work in progress), December 2016.
[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-02 (work in progress), July 2016. anima-reference-model-02 (work in progress), July 2016.
[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-
skipping to change at page 30, line 14 skipping to change at page 31, line 36
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>. <http://www.rfc-editor.org/info/rfc4122>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <http://www.rfc-editor.org/info/rfc4193>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<http://www.rfc-editor.org/info/rfc5082>. <http://www.rfc-editor.org/info/rfc5082>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
 End of changes. 61 change blocks. 
120 lines changed or deleted 203 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/