draft-ietf-anima-autonomic-control-plane-05.txt   draft-ietf-anima-autonomic-control-plane-06.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: July 15, 2017 Expires: September 28, 2017 Huawei
S. Bjarnason S. Bjarnason
Arbor Networks Arbor Networks
January 11, 2017 March 27, 2017
An Autonomic Control Plane An Autonomic Control Plane
draft-ietf-anima-autonomic-control-plane-05 draft-ietf-anima-autonomic-control-plane-06
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 July 15, 2017. This Internet-Draft will expire on September 28, 2017.
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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 . . . . . . . . 4
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 ANIMA information . . . . . . 8
5.1.2. AN Adjacency Table . . . . . . . . . . . . . . . . . 9 5.1.2. AN Adjacency Table . . . . . . . . . . . . . . . . . 10
5.2. Neighbor discovery . . . . . . . . . . . . . . . . . . . 10 5.2. Neighbor discovery . . . . . . . . . . . . . . . . . . . 11
5.2.1. L2 topology considerations . . . . . . . . . . . . . 10 5.2.1. L2 topology considerations . . . . . . . . . . . . . 11
5.2.2. CDP/LLDP/mDNS considerations . . . . . . . . . . . . 11 5.2.2. CDP/LLDP/mDNS considerations . . . . . . . . . . . . 12
5.2.3. Discovery with GRASP . . . . . . . . . . . . . . . . 11 5.2.3. Discovery with GRASP . . . . . . . . . . . . . . . . 12
5.2.4. Discovery and BRSKY . . . . . . . . . . . . . . . . . 12 5.2.4. Discovery and BRSKY . . . . . . . . . . . . . . . . . 13
5.3. Candidate ACP Neighbor Selection . . . . . . . . . . . . 12 5.3. Candidate ACP Neighbor Selection . . . . . . . . . . . . 13
5.4. Channel Selection . . . . . . . . . . . . . . . . . . . . 13 5.4. Channel Selection . . . . . . . . . . . . . . . . . . . . 14
5.5. Security Association protocols . . . . . . . . . . . . . 14 5.5. Security Association protocols . . . . . . . . . . . . . 15
5.5.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 15 5.5.1. ACP via IPsec . . . . . . . . . . . . . . . . . . . . 15
5.5.2. ACP via GRE/IPsec . . . . . . . . . . . . . . . . . . 15 5.5.2. ACP via GRE/IPsec . . . . . . . . . . . . . . . . . . 16
5.5.3. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 15 5.5.3. ACP via dTLS . . . . . . . . . . . . . . . . . . . . 16
5.5.4. GRASP/TLS negotiation . . . . . . . . . . . . . . . . 15 5.5.4. GRASP/TLS negotiation . . . . . . . . . . . . . . . . 16
5.5.5. ACP Security Profiles . . . . . . . . . . . . . . . . 16 5.5.5. ACP Security Profiles . . . . . . . . . . . . . . . . 17
5.6. GRASP instance details . . . . . . . . . . . . . . . . . 16 5.6. GRASP instance details . . . . . . . . . . . . . . . . . 17
5.7. Context Separation . . . . . . . . . . . . . . . . . . . 16 5.7. Context Separation . . . . . . . . . . . . . . . . . . . 18
5.8. Addressing inside the ACP . . . . . . . . . . . . . . . . 17 5.8. Addressing inside the ACP . . . . . . . . . . . . . . . . 18
5.8.1. Fundamental Concepts of Autonomic Addressing . . . . 17 5.8.1. Fundamental Concepts of Autonomic Addressing . . . . 18
5.8.2. The ACP Addressing Base Scheme . . . . . . . . . . . 18 5.8.2. The ACP Addressing Base Scheme . . . . . . . . . . . 19
5.8.3. ACP Addressing Sub-Scheme . . . . . . . . . . . . . . 19 5.8.3. ACP Addressing Sub-Scheme . . . . . . . . . . . . . . 20
5.8.4. Usage of the Zone Field . . . . . . . . . . . . . . . 20 5.8.4. Usage of the Zone Field . . . . . . . . . . . . . . . 21
5.8.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 21 5.8.5. Other ACP Addressing Sub-Schemes . . . . . . . . . . 22
5.9. Routing in the ACP . . . . . . . . . . . . . . . . . . . 21 5.9. Routing in the ACP . . . . . . . . . . . . . . . . . . . 22
5.10. General ACP Considerations . . . . . . . . . . . . . . . 21 5.9.1. RPL Profile for the ACP . . . . . . . . . . . . . . . 23
6. Workarounds for Non-Autonomic Nodes . . . . . . . . . . . . . 22 5.10. General ACP Considerations . . . . . . . . . . . . . . . 24
6.1. Connecting a Non-Autonomic Controller / NMS system . . . 22 6. Workarounds for Non-Autonomic Nodes . . . . . . . . . . . . . 24
6.2. ACP through Non-Autonomic L3 Clouds . . . . . . . . . . . 23 6.1. Connecting a Non-Autonomic Controller / NMS system . . . 24
7. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 23 6.2. ACP through Non-Autonomic L3 Clouds . . . . . . . . . . . 25
8. Self-Protection Properties . . . . . . . . . . . . . . . . . 24 7. Self-Healing Properties . . . . . . . . . . . . . . . . . . . 25
9. The Administrator View . . . . . . . . . . . . . . . . . . . 25 8. Self-Protection Properties . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. The Administrator View . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Initial version . . . . . . . . . . . . . . . . . . . . 27 13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 29
13.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 27 13.1. Initial version . . . . . . . . . . . . . . . . . . . . 29
13.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 27 13.2. draft-behringer-anima-autonomic-control-plane-00 . . . . 29
13.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 27 13.3. draft-behringer-anima-autonomic-control-plane-01 . . . . 29
13.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 27 13.4. draft-behringer-anima-autonomic-control-plane-02 . . . . 30
13.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 28 13.5. draft-behringer-anima-autonomic-control-plane-03 . . . . 30
13.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 28 13.6. draft-ietf-anima-autonomic-control-plane-00 . . . . . . 30
13.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 29 13.7. draft-ietf-anima-autonomic-control-plane-01 . . . . . . 30
13.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 29 13.8. draft-ietf-anima-autonomic-control-plane-02 . . . . . . 31
13.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 29 13.9. draft-ietf-anima-autonomic-control-plane-03 . . . . . . 31
13.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 30 13.10. draft-ietf-anima-autonomic-control-plane-04 . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 13.11. draft-ietf-anima-autonomic-control-plane-05 . . . . . . 32
Appendix A. Background on the choice of routing protocol . . . . 32 13.12. draft-ietf-anima-autonomic-control-plane-06 . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Background on the choice of routing protocol . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 9, line 10 skipping to change at page 9, line 10
specific Unique Device Identifier (UDI) or IDevID certificate. 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, 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: Example:
anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.com anima.acp+FD99:B02D:8EC3: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
several reasons:
o We want to permit the reuse of the ANIMA LDevID in other uses
beside the ACP as appropriate, eg: there are a wide number of pre-
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
will not cause incompatibilities with any pre-existing ASN.1 code
potentially in use in those other pre-existing SW systems.
o subjectAltname / rfc822Name is a pre-existing element that must be
supported by all existing ASN.1 parsers for LDevID.
o We also want to make sure that the ACP information will not be
misinterpreted by any such pre-existing code interpreting the
LDevID, or if it is misinterpreted, that the impact is benign.
o Using an IP address format encoding could result in non-benign
misinterpretation of the ACP information.
o At minimum, we need to encode both the AN domain name and the non-
domain name derived part of the ACP, so there are not many
alternatives with pre-existing fields where those two elements
could be encoded.
o rfc822Name encoding allows to be quite flexible. We choose to
encode the full ACP address AND the domain name, so that it is
easier to examine/use.
o The format of the rfc822Name is choosen so that an operator can
set up a mailbox called anima.acp@<domain> that would receive
emails sent towards the rfc822Name of any AN device inside a
domain. This is possible because components behind a plus symbol
are considered part of a single mailbox.
o In result, if any unexpected use of the ACP addressing information
in a certificate happens, it is benign and detectable: it would be
mail to that mailbox.
The bootstrap process defined in The bootstrap process defined in
[I-D.ietf-anima-bootstrapping-keyinfra] MUST in an ANIMA network pass [I-D.ietf-anima-bootstrapping-keyinfra] MUST in an ANIMA network pass
on ACP address and domain to a new node, such that the new node can on ACP address and domain to a new node, such that the new node can
add this to its enrolment request. add this to its enrolment request.
The Certificate Authority in an ANIMA network MUST honor these The Certificate Authority in an ANIMA network MUST honor these
parameters, and create the respective subjectAltName / rfc822Name in parameters, and create the respective subjectAltName / rfc822Name in
the certificate. the certificate.
ANIMA nodes can therefore find ACP address and domain using this ANIMA nodes can therefore find ACP address and domain using this
skipping to change at page 15, line 13 skipping to change at page 16, line 5
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. encryption.
In terms of IKEv2, this means the initiator will offer to support
IPsec transport mode with next protocol equal 41 (IPv6).
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 In terms of IKEv2 negotiation, this means the initiator must offer to
method is incompatible to direct ACP via IPsec, so it must only be support IPsec transport mode with next protocol equal to GRE (47),
used as an option during negotiation. followed by 41 (IPv6) (because native IPsec is required to be
supported, see below).
If IKEv2 initiator and responder support GRE, it will be selected.
The version of GRE to be used must the according to [RFC7676].
5.5.3. ACP via dTLS 5.5.3. ACP via dTLS
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
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] 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. use AES256 encryption.
There is no additional session setup or other security association
other than dTLS. As soon as the dTLS session is functional, the ACP
peers will exchange ACP IPv6 packets as the payload of the dTLS
transport connecetion. Any dTLS defined security association
mechanisms such as re-keying are used as they would be for any
transport application relying solely on dTLS.
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
over a TLS connection using the GRASP_LISTEN_PORT and the devices and 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 peers link-local IPv6 address is used. When Alice and Bob support
GRASP negotiation, they do prefer it over any other non-explicitly GRASP negotiation, they do prefer it over any other non-explicitly
negotiated security association protocol and should wait trying any negotiated security association protocol and should wait trying any
non-negotiated ACP channel protocol until after it is clear that non-negotiated ACP channel protocol until after it is clear that
GRASP/TLS will not work to the peer. GRASP/TLS will not work to the peer.
skipping to change at page 16, line 11 skipping to change at page 17, line 22
After agreeing on a channel mechanism, Alice and Bob start the After agreeing on a channel mechanism, Alice and Bob start the
selected Channel protocol. The GRASP/TLS connection can be kept selected Channel protocol. The GRASP/TLS connection can be kept
alive or timed out as long as the seelected channel protocol has a alive or timed out as long as the seelected channel protocol has a
secure association between Alice and Bob. When it terminates, it secure association between Alice and Bob. When it terminates, it
needs to be re-negotiated via GRASP/TLS. needs to be re-negotiated via GRASP/TLS.
Negotiation of a channel type may require IANA assignments of code Negotiation of a channel type may require IANA assignments of code
points. See IANA Considerations (Section 11) for the formal points. See IANA Considerations (Section 11) for the formal
definition of those code points. definition of those code points.
TBD: The exact negotiation steps in GRASP to achieve this outcome. The exact negotiation steps in GRASP to achieve this outcome.
5.5.5. ACP Security Profiles 5.5.5. ACP Security Profiles
A baseline autonomic device MUST support IPsec and SHOULD support A baseline autonomic device MUST support IPsec and SHOULD support
GRASP/TLS and dTLS. A constrained autonomic device MUST support GRASP/TLS and dTLS. A constrained autonomic device MUST support
dTLS. dTLS.
The MTU for ACP secure channels must be derived locally from the
underlying link MTU minus the security encapsulation overhead. Given
how ACP channels are built across layer2 connections only, the
probability for MTU mismatch is low. For additional reliability,
applications to be runa cross the ACP should only assume to have
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.6. 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
skipping to change at page 21, line 37 skipping to change at page 23, line 9
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, and channels of the autonomic control plane are by default secured, and
this routing runs only inside the ACP. this routing runs only inside the ACP.
The routing protocol inside the ACP is RPL [RFC6550]. See Appendix A The routing protocol inside the ACP is RPL ([RFC6550]) with the
for more details on the choice of RPL. following profile. See Appendix A for more details on the choice of
RPL.
[EDNOTE: Need to decide: storing / non-storing mode; mcr suggests 5.9.1. RPL Profile for the ACP
storing mode. Need to define more parameters in detail.]
o RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations
with multicast support". Implementations should support also
other modes. Note: Root indicates mode in DIO flow.
o Objective Function (OF): Use OF0 [RFC6552]. No use of metric
containers, Default RPLInstanceID = 0.
* stretch_rank: none provided ("not stretched").
* rank_factor: Derived from link speed: <= 100Mbps:
LOW_SPEED_FACTOR(5), else HIGH_SPEED_FACTOR(1)
o Trickle: Not used; Data Path Validation: Not used.
o Proactive, aggressive DAO state maintenance:
* Use K-flag in unsolicited DAO indicating change from previous
information (to require DAO-ACK).
* Retry such DAO DAO-RETRIES(3) times with DAO-
ACK_TIME_OUT(256ms) in between.
o Administrative Preference ([RFC6552], 3.2.6 - to become root):
Indicated in DODAGPreference field of DIO message.
* Explicit configured "root": 0b100
* Registrar (Default): 0b011
* AN-connect (non registrar): 0b010
* Default: 0b001.
The RPL root can create additional RPL instances with other OF and
metrics as desired, eg: via intent.
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 24, line 27 skipping to change at page 26, line 38
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.8).
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
not feasible, then it might instead be possible to request explicit
operator override upon administrative actions that would
administratively bring down an interface across whicht the ACP is
running. Especially if bringing down the ACP is known to disconnect
the operator from the device. For example any such down
administrative action could perform a dependency check to see if the
transport connection across which this action is performed is
affected by the down action (with default RPL routing used, packet
forwarding will be symmetric, so this is actually possible to check).
8. Self-Protection Properties 8. Self-Protection Properties
As explained in Section 5, the ACP is based on secure channels built As explained in Section 5, the ACP is based on secure channels built
between devices that have mutually authenticated each other with between devices that have mutually authenticated each other with
their domain certificates. The channels themselves are protected their domain certificates. The channels themselves are protected
using standard encryption technologies like DTLS or IPsec which using standard encryption technologies like DTLS or IPsec which
provide additional authentication during channel establishment, data provide additional authentication during channel establishment, data
integrity and data confidentiality protection of data inside the ACP integrity and data confidentiality protection of data inside the ACP
and in addition, provide replay protection. and in addition, provide replay protection.
skipping to change at page 26, line 49 skipping to change at page 29, line 30
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
recommendations of the RPL profile to use in the ACP
Further input and suggestions were received from: Rene Struik, Brian Further input and suggestions were received from: Rene Struik, Brian
Carpenter, Benoit Claise. Carpenter, Benoit Claise.
13. Change log [RFC Editor: Please remove] 13. Change log [RFC Editor: Please remove]
13.1. Initial version 13.1. Initial version
First version of this document: draft-behringer-autonomic-control- First version of this document: draft-behringer-autonomic-control-
plane plane
skipping to change at page 30, line 38 skipping to change at page 33, line 19
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.5.
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
o Added proposed RPL profile.
o detailed dTLS profile - dTLS with any additional negotiation/
signaling channel.
o Fixed up text for ACP/GRE encap. Removed text claiming its
incompatible with non-GRE IPsec and detailled it.
o Added text to suggest admin down interfaces should still run ACP.
14. References 14. References
[I-D.carpenter-anima-ani-objectives] [I-D.carpenter-anima-ani-objectives]
Carpenter, B. and B. Liu, "Technical Objectives for the Carpenter, B. and B. Liu, "Technical Objective Formats for
Autonomic Network Infrastructure", draft-carpenter-anima- the Autonomic Network Infrastructure", draft-carpenter-
ani-objectives-00 (work in progress), November 2016. anima-ani-objectives-01 (work in progress), February 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-04 (work in progress), October 2016. keyinfra-05 (work in progress), March 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-09 (work in progress), December 2016. grasp-10 (work in progress), March 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-02 (work in progress), July 2016. anima-reference-model-03 (work in progress), March 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-01 (work in progress), July anima-stable-connectivity-02 (work in progress), February
2016. 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
(work in progress), October 2016. (work in progress), October 2016.
[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>.
skipping to change at page 32, line 21 skipping to change at page 35, line 16
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <http://www.rfc-editor.org/info/rfc6550>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012,
<http://www.rfc-editor.org/info/rfc6552>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>. <http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404, Addressing inside an IPv6 Network", RFC 7404,
skipping to change at page 32, line 45 skipping to change at page 35, line 45
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<http://www.rfc-editor.org/info/rfc7575>. <http://www.rfc-editor.org/info/rfc7575>.
[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap
Analysis for Autonomic Networking", RFC 7576, Analysis for Autonomic Networking", RFC 7576,
DOI 10.17487/RFC7576, June 2015, DOI 10.17487/RFC7576, June 2015,
<http://www.rfc-editor.org/info/rfc7576>. <http://www.rfc-editor.org/info/rfc7576>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015,
<http://www.rfc-editor.org/info/rfc7676>.
Appendix A. Background on the choice of routing protocol Appendix A. Background on the choice of routing protocol
In a pre-standard implementation, the "IPv6 Routing Protocol for Low- In a pre-standard implementation, the "IPv6 Routing Protocol for Low-
Power and Lossy Networks (RPL, [RFC6550] was chosen. This Power and Lossy Networks (RPL, [RFC6550] was chosen. This
Appendix explains the reasoning behind that decision. Appendix explains the reasoning behind that decision.
Requirements for routing in the ACP are: Requirements for routing in the ACP are:
o Self-management: The ACP must build automatically, without human o Self-management: The ACP must build automatically, without human
intervention. Therefore routing protocol must also work intervention. Therefore routing protocol must also work
skipping to change at page 34, line 29 skipping to change at page 37, line 37
Michael H. Behringer (editor) Michael H. Behringer (editor)
Cisco Systems Cisco Systems
Building D, 45 Allee des Ormes Building D, 45 Allee des Ormes
Mougins 06250 Mougins 06250
France France
Email: mbehring@cisco.com Email: mbehring@cisco.com
Toerless Eckert Toerless Eckert
Futurewei Technologies Inc.
2330 Central Expy
Santa Clara 95050
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. 28 change blocks. 
70 lines changed or deleted 214 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/